fix(kubernetes): render the talos-reconcile Job for the default md0 group - #3535

What this PR does

Fixes #3504.

The chart has two loops over worker node groups and they read different sources. templates/cluster.yaml iterates the effective set through the kubernetes.nodeGroups helper, whose else-branch supplies the built-in md0 group when the user declares none — that is how #2936 made md0 removable without a Helm values merge re-adding it. templates/talos/talos-reconcile-job.yaml iterated the raw .Values.nodeGroups map instead, which is empty in exactly that case.

The consequence is a dangling reference. The chart cannot render the TalosConfigTemplate itself — it needs the apiserver Service ClusterIP, the Talos CA and the Kubernetes CA, none of which exist while Helm is executing the template — so cluster.yaml deliberately stopped rendering it and the Job became its only producer, while the MachineDeployment still names it in spec.template.spec.bootstrap.configRef. On a cluster with the default nodeGroups, MachineDeployment/<release>-md0 renders and zero Jobs render, so TalosConfigTemplate/<release>-md0 is never created and CAPI blocks every Machine that ever joins the group. The same Job also patches KamajiControlPlane.spec.network.certSANs with the live Service ClusterIP, so that is skipped too.

Nothing fails at install time, because the built-in group carries minReplicas: 0. The failure waits for the first scale-up, which is the documented path rather than a corner: values.yaml tells operators that enabling the ingress-nginx addon on a cluster with default nodeGroups means waiting for the cluster-autoscaler to bring md0 up in response to the controller Pods becoming Pending, and the autoscaler is deployed unconditionally whenever the tenant has an etcd DataStore.

The fix is to range over the helper so the Job set tracks the MachineDeployment set exactly. A cluster that declares its own groups renders byte-identically — which is why the pinned content-hash fixtures in tests/talos_templates_test.yaml are untouched — and md0 stays removable, because the fix defers to the helper rather than merging md0 in unconditionally. On upgrade it is additive: the Job appears where there was none, applies the TalosConfigTemplate the MachineDeployment already expects, and the content-hash name suffix means Helm creates a fresh Job rather than attempting to patch an immutable one.

How this survived

Every helm-unittest fixture and every e2e suite declares md0 explicitly. tests/nodegroups_default_test.yaml does render the empty-nodeGroups case, but lists only templates/cluster.yaml, so it never looked at a Job. The two OIDC chainsaw lanes do install with an empty map, but assert that the HelmRelease exists rather than that it becomes Ready, so a worker that never boots is invisible to them. Offline helm template cannot reach this path at all: cluster.yaml's instanceType validator needs a live lookup for u1.medium.

tests/talos_reconcile_nodegroups_test.yaml closes the gap and pins both halves of the helper contract — an empty map yields exactly one md0 Job carrying GROUP_NAME=md0, and a two-group map yields exactly two Jobs with no md0 among them, so a future fix that merges md0 in unconditionally fails here. Reverting the template change fails the first case on the document count, so it guards the behaviour rather than restating it.

Screenshots

Not a UI change.

Downstream repositories

Walked the trigger map in docs/agents/contributing.md against the diff: it is one Helm template loop and one new helm-unittest suite inside packages/apps/kubernetes. No package is added, renamed or removed; no values.yaml, values.schema.json, ApplicationDefinition, version enum or default changes; nothing under hack/, no namespace, variant, label, annotation or metric renamed. The behaviour now matches what values.yaml already documents, so no reference page drifts.

• No downstream repository is affected by this change
• cozystack/website - follow-up:
• cozystack/terraform-provider-cozystack - follow-up:
• cozystack/ansible-cozystack - follow-up:
• cozystack/ccp - follow-up:
• cozystack/talm - follow-up:
• cozystack/cozyhr - follow-up:
• cozystack/cozy-proxy - follow-up:
• cozystack/cozystack-telemetry-server - follow-up:
• cozystack/external-apps-example - follow-up:
• cozystack/examples - follow-up:

Release note

fix(kubernetes): a tenant Kubernetes cluster created without an explicit `nodeGroups` map now gets a talos-reconcile Job for the built-in `md0` node group. Previously that Job rendered only for explicitly declared groups, so the default `md0` MachineDeployment referenced a TalosConfigTemplate nothing ever created: every worker the cluster-autoscaler added to `md0` stayed stuck waiting for its bootstrap config, and the KamajiControlPlane certSANs patch the same Job performs never ran. Clusters that declare their own node groups were unaffected.

Summary by CodeRabbit

• Bug Fixes

  • Ensured the built-in md0 node group receives its Talos reconciliation Job when no node groups are configured.
  • Prevented duplicate reconciliation Jobs when custom node groups are specified.
  • Preserved correct group-specific settings and control-plane configuration in generated Jobs.

• Tests

  • Added regression coverage for default and custom node-group scenarios.