feat(cluster): day-2 sync for hcloud instance types and control-plane replicas

[ashish1099]

Closes the "Day-2 cluster sync for cloud instance-type changes" item in docs/TODO.md, for hcloud.

Why

Editing machineType or controlPlane.hcloud.replicas in general.yaml had no effect on a running cluster. Only bootstrap re-renders values-capi-cluster.yaml; cluster sync refused every non-bare-metal provider, and cluster upgrade only patched .global.kubernetes.version plus the machine image.

The design changed: rotation, not delete+recreate

The TODO's plan was to delete the immutable MachineTemplate and recreate it with the new instanceType. That does not work, and fails silently.

ClusterAPI decides a Machine is up to date by comparing the name of the template it was cloned from against the name its owner references — never the template's contents (filters.go:143 for KCP, mdutil/util.go:408 for MachineDeployments, cluster-api v1.11.10). Recreating under the old name leaves clonedFromName matching: nothing rolls, and the new instance type applies only to machines created later.

The chart now names templates after a hash of their spec (Obmondo/KubeAid#TBD), so:

• replicas 1 → 3 — spec untouched → name untouched → KCP scales out. New members join etcd; nothing is replaced.
• machineType change — name rotates → KCP rolls, surge then remove.

Pure GitOps. No client-go surgery, no window where the template is missing.

What's here

• cluster.machineTemplateRotation → global.machineTemplateRotation in the rendered values.
• cluster sync handles Hetzner: re-render → inline unified diff → confirm → PR → sync the capi-cluster ArgoCD app → WaitForControlPlaneRolloutComplete.
• cluster upgrade skips UpdateMachineTemplate on rotation-enabled clusters (the fixed-name object doesn't exist there) and syncs the whole app instead.

Gates

Nothing in kubeaid-cli ever selects a kubeconfig context — every client uses clientcmd.BuildConfigFromFlags("", path) and silently follows whatever current-context the kubeconfig carries. So cluster sync and cluster upgrade now resolve that context and make the operator confirm it: cluster name from general.yaml, context, API server, kubeconfig path, and a loud MISMATCH line when they disagree. Declining, a missing kubeconfig, or no TTY all abort.

planCapiValuesSync refuses two changes outright, because both fail silently:

1. a rotating change while machineTemplateRotation is false — nothing would roll;
2. a rotating change combined with a replicas change — asks CAPI to both add and replace control-plane members, walking etcd through membership changes with no quorum to lose.

…and warns when a rolling change would run against fewer than 3 replicas.

Applying to netbird-obmondo-com (1 × cpx32 → 3 × cpx22)

The refusals force the correct order, in two syncs:

1. Scale out. replicas: 3, still cpx32, rotation off. Template name unchanged → two new control-plane members join etcd, nothing replaced.
2. Re-type. machineTemplateRotation: true + machineType: cpx22. Template rotates → the three machines roll one at a time, quorum held.

Doing both at once is refused. (cpx22 is a downsize — worth confirming it's big enough for etcd before phase 2.)

Full write-up: docs/specs/2026-07-09-machinetemplate-rotation-day2-sync.md.

Testing

go build, go vet, golangci-lint run ./pkg/core/... (0 issues), and the full suite pass. New table-driven tests cover the refusal/warning matrix and the netbird two-phase sequence, plus kubeconfig-context resolution and the rendered flag.

pkg/cloud/hetzner has a pre-existing failure on main (TestCreateNetwork/network_already_exists nil-deref panic), untouched by this change.

Depends on

Obmondo/KubeAid feat/machinetemplate-rotation — without it, machineTemplateRotation: true renders a value the chart ignores, and cluster sync correctly refuses every instance-type change.

🤖 Generated with Claude Code