labsim-dualstack-convert.sh rolls the single->dual-stack conversion the way
production Phase 4 will: each server's config.yaml re-rendered by the PRODUCTION
generator with both families, node-ip v6 added first, k3s restarted ONE server
at a time, snapshotting between. Findings (evidence: dualstack-evidence/):
1. QUORUM HELD through every rolling restart -- each server came back k3s=active
with restarts=0, apiserver stayed responsive, 3 nodes registered throughout.
No quorum loss converting a 3-member etcd cluster one node at a time.
2. ServiceCIDR goes dual on the FIRST server's restart, NOT when all three
agree. After converting only server 1: kubernetes SC = [10.43.0.0/16
fd00:43::/112], and it stayed dual through servers 2 and 3. The primary
(IPv4) family is preserved -- existing ClusterIPs keep their v4.
3. The MIXED control plane is safe: server 1 dual while 2/3 were still v4-only,
cluster stayed healthy. Servers disagreeing on service-cidr does NOT
crash-loop them -- k3s validates each server's own cluster/service pair
together, but the ServiceCIDR object is cluster-wide etcd state and the first
to declare it dual wins.
4. A PreferDualStack Service now gets BOTH ClusterIPs (10.43.142.199 +
fd00:43::3933) -- dual service networking works end to end.
5. Node podCIDRs stayed IPv4-only after conversion. This is the key confirmation
for Phase 3: under k3s's built-in IPAM, node.spec.podCIDRs is written once at
join and never revised, so existing nodes CANNOT gain a v6 pod range this
way. That is exactly why Cilium must move to cluster-pool -- proven live, not
argued from docs.
So the k3s/ServiceCIDR half of the production conversion is de-risked: roll
config.yaml one server at a time, quorum holds, ServiceCIDR goes dual on the
first restart. The pod-CIDR half needs the Cilium cluster-pool switch (Phase 3),
which the single-node dualstack-lab.sh already covered.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DMVzWZgiKW2wquf5z8S1yH
