docs(kubernetes): re-home talos-reconcile comments after split

Three template comments in the control-plane chart still described the
talos-reconcile Job as living here, but the worker split moved it to
the kubernetes-nodes chart (one run per pool release):

- talos-pki.yaml pointed at "the routing note in
  talos-reconcile-job.yaml", a file this chart no longer contains.
- cluster.yaml said "the talos-reconcile main-phase Job re-patches
  certSANs" as if this chart still runs it; it now also states the
  consequence the kubernetes-nodes side already documents -- the
  ClusterIP SAN arrives only through a pool and a pool-less cluster
  keeps DNS SANs only, a best-effort extra that nothing depends on.
- cilium.yaml credited the /etc/hosts seeding to the same Job without
  naming its new home; it also now notes why the entry is always
  present wherever Cilium runs (workers only exist through pools).

Comments only ({{/* */}} blocks, stripped at render time); no manifest
output changes, pinned by the chart's unittest suite staying green.

Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Timofei Larkin <lllamnyp@gmail.com>
This commit is contained in:
Timofei Larkin committed 2026-07-25 02:40:10 +03:00
1 parent 730d006ce8
commit af2b40be9f
3 files changed
+19 -12

No files matched your search

@@ -286,9 +286,14 @@ spec:
protocol: TCP
{{- /* Initial render lists only the DNS SANs because the apiserver
Service ClusterIP is not yet allocated when Helm executes the
template. The talos-reconcile main-phase Job re-patches certSANs
with the live ClusterIP once Kamaji emits the Service, and
Kamaji then re-issues the apiserver TLS cert to cover it. */}}
template. Since the worker split, the talos-reconcile Job that
re-patches certSANs with the live ClusterIP (after which Kamaji
re-issues the apiserver TLS cert) runs in each kubernetes-nodes
pool release, not in this chart: a cluster with at least one pool
gains the ClusterIP SAN once Kamaji emits the Service, while a
pool-less cluster keeps DNS SANs only. That is a best-effort
extra, not a dependency -- workers dial the apiserver by DNS name
via extraHostEntries, so nothing requires the IP SAN. */}}
certSANs:
- {{ printf "%s.%s.svc" .Release.Name .Release.Namespace }}
- {{ printf "%s.%s.svc.%s" .Release.Name .Release.Namespace (include "kubernetes.tenantClusterDomain" .) }}
@@ -1,12 +1,13 @@
{{- define "cozystack.defaultCiliumValues" -}}
{{- /* Cilium runs hostNetwork on the Talos worker nodes and resolves the
apiserver via the worker's /etc/hosts, which the talos-reconcile
main-phase Job seeds with the Kamaji Service ClusterIP under
<release>.<ns>.svc through machine.network.extraHostEntries. So a
plain DNS host works here without a lookup-and-reuse race: the
cert covers the same DNS name from chart render time, and the
hosts entry is set well before kubelet (and therefore Cilium)
comes up on the node. */}}
apiserver via the worker's /etc/hosts, which the kubernetes-nodes
chart's talos-reconcile Job seeds with the Kamaji Service ClusterIP
under <release>.<ns>.svc through machine.network.extraHostEntries
(workers only exist through pools, so every node Cilium runs on has
the entry). So a plain DNS host works here without a
lookup-and-reuse race: the cert covers the same DNS name from chart
render time, and the hosts entry is set well before kubelet (and
therefore Cilium) comes up on the node. */}}
cilium:
k8sServiceHost: {{ printf "%s.%s.svc" .Release.Name .Release.Namespace }}
k8sServicePort: 6443
@@ -76,8 +76,9 @@ spec:
Workers reach trustd via the Service DNS name (the worker's
machine.network.extraHostEntries injects the ClusterIP into
/etc/hosts), so the cert never needs an IP SAN patched in after the
ClusterIP becomes known — see the routing note in
talos-reconcile-job.yaml. */}}
ClusterIP becomes known — see the routing note in the kubernetes-nodes
chart's talos-reconcile-job.yaml, where the Job lives since the worker
split. */}}
issuerRef:
name: {{ .Release.Name }}-talos-ca
kind: Issuer