51bf300474
Some checks failed
Phase 2d of cluster dual-stack. This is the file that makes a NEW node correct by construction: it already owns /etc/rancher/k3s/config.yaml for every node, so once it emits dual values, a joining node is dual-stack with nothing else to do. Before this there was nowhere for a node's IPv6 to come from -- K3sConfig had no v6 field and generateAgentConfig() took no arguments at all. The property that matters most is the negative one: with no ipv6 and no CIDRs, addressFamilyLines() returns "" and the output is BYTE-IDENTICAL to what the five existing nodes already have. Verified by diffing the generator's output for worker0's parameters against worker0's live config.yaml -- identical. So this change is inert until dual-stack config is supplied, rather than a flag day that rewrites five healthy nodes and restarts the cluster to tell it what it knew. node-ip is written only once there is a second family to name. k3s auto-detects a sensible IPv4 by itself, and emitting it unconditionally would be that same pointless rewrite. IPv4 stays first: the supported single-to-dual-stack conversion preserves the primary family, which is what lets existing Services keep their ClusterIP. Agents get their own node-ip and no CIDRs. An agent without one joins a dual-stack cluster as IPv4-only, gets no IPv6 pod CIDR, and fails later as pods unreachable over v6 while the node itself reads Ready. The IPv6 address is also added as a TLS SAN. Without it anything reaching the apiserver over v6 -- a peer server joining, kubectl against the v6 address -- fails verification with an error naming the certificate rather than the missing SAN. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DMVzWZgiKW2wquf5z8S1yH