feat(talos): move the node IP and etcd to pod0 (#576)

Pod east-west has to leave the management VLAN, and the node IP is the
only thing that controls where it goes. Three tests established that,
rather than argument:

  - --ipv4-node / --ipv6-node, applied via CiliumNodeConfig: the agent
    logged receiving both and still published its mgmt0 address.
  - directRoutingDevice=pod0: the agent logged "Direct routing device
    detected direct-routing-device=pod0" and still installed
    10.244.2.0/24 via 10.2.40.138 dev mgmt0.
  - Both routing modes, both address families, always keyed to the
    peer's Kubernetes InternalIP.

etcd is pinned to the same segment. Left unset it advertises "the first
routable address of the node", which is not deterministic once the node
is re-addressed, so it has to be stated either way. pod0 is a closed 10G
L2 between the three nodes; the management VLAN is about to become a
single 1G NIC shared with everything else management does, which is the
wrong link for quorum traffic. listenSubnets defaults to this, so peer
and client listeners move together.

This does move the etcd peer URLs off 10.2.40.x, so unlike the node IP
it is not a no-op: one node at a time, waiting for a healthy quorum
between each.

The API VIP stays on mgmt0; it is a Layer2VIPConfig and does not follow
the node IP.

Apply one node at a time. Each node re-IPs, so per the note in
k8s-1.yaml (#635) kube-apiserver keeps advertising the old address until
its static pod restarts: after each node, check that
`kubectl get endpoints kubernetes -n default` agrees with
`kubectl get nodes -o wide` and reboot the node if it does not. The
cilium agent reads the node IP only at startup, so it needs recreating
on each node as well.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

kubernetes/infrastructure/post-crds/cilium-bgp.yaml

@@ -25,13 +25,13 @@ spec:
       stop: "fd99::ff"
 ---
 # Cilium BGPv2 control-plane config peering each node with the UDM over the
-# management LAN — never over v30iot, which is the untrusted IoT segment.
+# ingress VLAN 47 — never over v30iot, which is the untrusted IoT segment.
 # The source address comes from the kernel routing decision, so no explicit
 # localAddress override is needed.
 #
 # Two parallel sessions, one per address family:
-#   - v4 session: peer 10.2.40.1, family IPv4 unicast only
-#   - v6 session: peer fd40::1, family IPv6 unicast only
+#   - v4 session: peer 10.2.47.1, family IPv4 unicast only
+#   - v6 session: peer fd02:47::1, family IPv6 unicast only
 # This avoids the "v6 NLRIs over v4 transport" path, which requires
 # bilateral extended-nexthop capability negotiation (RFC 5549/8950).
 # Cilium 1.19 BGPv2 advertises the capability only for the IPv4 Unicast
@@ -74,14 +74,14 @@ spec:
       peers:
         - name: udm-v6
           peerASN: 64512
-          # ULA — stable across ISP renumber events. UDM's br40 has
-          # fd40::1/64; nodes get fd40::<eui-64> via SLAAC on eth0.
-          peerAddress: fd40::1
+          # ULA — stable across ISP renumber events. UDM's br47 has
+          # fd02:47::1/64; nodes get fd02:47::<eui-64> via SLAAC on ingress0.
+          peerAddress: fd02:47::1
           peerConfigRef:
             name: bgp-peer-udm-v6
         - name: udm-v4
           peerASN: 64512
-          peerAddress: 10.2.40.1
+          peerAddress: 10.2.47.1
           peerConfigRef:
             name: bgp-peer-udm-v4
 ---

kubernetes/talos/patches/k8s-1.yaml

@@ -17,9 +17,19 @@ machine:
     # pod0 is a closed L2 fabric between the three nodes: statically
     # addressed, no gateway, nothing to learn from an RA.
     net.ipv6.conf.pod0.accept_ra: "0"
-    # ingress0 takes its prefix from the RA but not the default route — that
-    # stays on mgmt0 until the split flips it, and two default routes at the
-    # same metric tie.
+    # ingress0 keeps RAs, at the default accept_ra of 2: an IPv6 default
+    # router is a link-local address learned only from the RA, and with
+    # net.ipv6.conf.all.forwarding=1 — which Cilium sets — Linux ignores RAs
+    # entirely below 2. That is how mgmt0 has its IPv6 default today.
+    #
+    # The prefix is announced correctly, so SLAAC addresses this link the same
+    # way mgmt0 gets its fd40:: address: derived from the MAC, stable across
+    # reboots, nothing to allocate. Only IPv4 is declared here, and only
+    # because a second DHCP client is what broke the node's DNS record.
+    #
+    # Just the default route is suppressed, because mgmt0 owns it until the
+    # split flips it and two defaults at one metric tie. Dropping this line is
+    # what hands the IPv6 default over.
     net.ipv6.conf.ingress0.accept_ra_defrtr: "0"
     # That network also carries the mgmt VLAN's ARP. Answer ARP only on the
     # link that owns the address, or the UDM learns the node IP against
@@ -164,21 +174,27 @@ addresses:
 # Ingress network, VLAN 47. World-to-pod: the BGP session, the next hop for
 # every advertised LoadBalancer VIP, and the masquerade source for pod egress.
 # Publicly routed, which is what separates it from pod0.
+#
+# Statically addressed, not leased. A second DHCP client on the node announced
+# the same hostname as mgmt0's and the UDM registered the node against this
+# segment instead, so mgmt0's `srv.renner.uno` record disappeared and the
+# lease's resolver displaced the management one. The UDM cannot register a
+# network's clients selectively, so the client goes rather than the record.
+# DHCP is off on VLAN 47 for the same reason.
+#
+# The metric loses to mgmt0's default 1024 deliberately: this pass only adds
+# the segment. The default route moves here in the change that flips it.
 apiVersion: v1alpha1
 kind: VLANConfig
 name: ingress0
 vlanID: 47
 parent: uplink
 up: true
----
-# Metric loses to mgmt0's default 1024 deliberately: this pass only adds the
-# segment. The default route moves here in the change that flips it, which
-# needs no reboot and is provable with `--mode=try`. DHCPv4Config cannot
-# suppress a default route, only deprioritise it.
-apiVersion: v1alpha1
-kind: DHCPv4Config
-name: ingress0
-routeMetric: 2048
+addresses:
+  - address: 10.2.47.11/24
+routes:
+  - gateway: 10.2.47.1
+    metric: 2048
 ---
 # Dedicated Ceph cluster network on X710 port 1, VLAN 49, untagged on the
 # wire. OSD-to-OSD replication and nothing else. The udev rule in the machine

kubernetes/talos/patches/k8s-2.yaml

@@ -12,8 +12,9 @@ machine:
     # cluster IPv6 egress.
     net.ipv6.conf.uplink.disable_ipv6: "1"
     net.ipv6.conf.mgmt.disable_ipv6: "1"
-    # pod0 is statically addressed with no gateway; ingress0 takes its prefix
-    # but not the RA default route — see k8s-1.yaml.
+    # pod0 is a closed segment with no router, so it ignores RAs outright.
+    # ingress0 keeps RAs: it learns its IPv6 router and its address from them,
+    # and only the default route is held back — see k8s-1.yaml.
     net.ipv6.conf.pod0.accept_ra: "0"
     net.ipv6.conf.ingress0.accept_ra_defrtr: "0"
     # Answer ARP only on the link that owns the address — see k8s-1.yaml (#793).
@@ -117,18 +118,19 @@ addresses:
   - address: 10.2.48.12/24
   - address: fd02:48::12/64
 ---
-# Ingress network, VLAN 47. World-to-pod, publicly routed — see k8s-1.yaml.
+# Ingress network, VLAN 47. World-to-pod, publicly routed, statically
+# addressed — see k8s-1.yaml for why it is not leased.
 apiVersion: v1alpha1
 kind: VLANConfig
 name: ingress0
 vlanID: 47
 parent: uplink
 up: true
----
-apiVersion: v1alpha1
-kind: DHCPv4Config
-name: ingress0
-routeMetric: 2048
+addresses:
+  - address: 10.2.47.12/24
+routes:
+  - gateway: 10.2.47.1
+    metric: 2048
 ---
 # Dedicated Ceph cluster network on X710 port 1, VLAN 49, untagged on the
 # wire. OSD-to-OSD replication only, not routed off its own segment.

kubernetes/talos/patches/k8s-3.yaml

@@ -8,8 +8,9 @@ machine:
     # k8s-1.yaml.
     net.ipv6.conf.uplink.disable_ipv6: "1"
     net.ipv6.conf.mgmt.disable_ipv6: "1"
-    # pod0 is statically addressed with no gateway; ingress0 takes its prefix
-    # but not the RA default route — see k8s-1.yaml.
+    # pod0 is a closed segment with no router, so it ignores RAs outright.
+    # ingress0 keeps RAs: it learns its IPv6 router and its address from them,
+    # and only the default route is held back — see k8s-1.yaml.
     net.ipv6.conf.pod0.accept_ra: "0"
     net.ipv6.conf.ingress0.accept_ra_defrtr: "0"
     # Answer ARP only on the link that owns the address — see k8s-1.yaml (#793).
@@ -104,18 +105,19 @@ addresses:
   - address: 10.2.48.13/24
   - address: fd02:48::13/64
 ---
-# Ingress network, VLAN 47. World-to-pod, publicly routed — see k8s-1.yaml.
+# Ingress network, VLAN 47. World-to-pod, publicly routed, statically
+# addressed — see k8s-1.yaml for why it is not leased.
 apiVersion: v1alpha1
 kind: VLANConfig
 name: ingress0
 vlanID: 47
 parent: uplink
 up: true
----
-apiVersion: v1alpha1
-kind: DHCPv4Config
-name: ingress0
-routeMetric: 2048
+addresses:
+  - address: 10.2.47.13/24
+routes:
+  - gateway: 10.2.47.1
+    metric: 2048
 ---
 # Dedicated Ceph cluster network — see k8s-1.yaml. The node holds NO address
 # here on purpose; the link is handed whole to the OSD pod (host-device).

kubernetes/talos/patches/site-homelab.yaml

@@ -7,16 +7,32 @@
 # part of the config that could not be true anywhere but here.
 machine:
   kubelet:
-    # Constrain kubelet's auto-picked node IP to the mgmt LAN. Without this,
-    # kubelet picks the first non-loopback IP, which could land on the v30iot
-    # NIC (ens19, 10.2.30.0/24). Control-plane traffic and hostNetwork pod IPs
-    # must stay on mgmt LAN.
-    # fd40::/64 is the mgmt LAN ULA, and it is listed so the Node object carries
-    # an IPv6 InternalIP at all. Without one, Cilium falls back to detecting the
-    # node's IPv6 from mgmt0 and picks the SLAAC address from the dynamic
-    # provider prefix, which it then probes until the agent restarts (#789).
-    # The GUA is not a control-plane address: BGP peers on fd40::/64 too.
+    # Pins the node IP to pod0 (VLAN 48), which is what carries pod east-west.
+    # Cilium reaches a peer's pods at that peer's Kubernetes InternalIP and
+    # offers no way to point it elsewhere: --ipv4-node/--ipv6-node are accepted
+    # and then overwritten from the Node object, and directRoutingDevice only
+    # selects the NodePort/DSR device. So the node IP is the only control over
+    # which segment east-west uses, in both tunnel and native routing mode.
+    #
+    # Unpinned, kubelet takes the first non-loopback address, which could land
+    # on the v30iot NIC (ens19, 10.2.30.0/24).
+    #
+    # fd02:48::/64 is listed so the Node object carries an IPv6 InternalIP at
+    # all. Without one, Cilium detects the node's IPv6 itself and picks the
+    # SLAAC address from the dynamic provider prefix, then probes it until the
+    # agent restarts (#789).
     nodeIP:
       validSubnets:
-        - 10.2.40.0/24
-        - fd40::/64
+        - 10.2.48.0/24
+        - fd02:48::/64
+cluster:
+  etcd:
+    # Pins etcd to pod0 with the node IP. Unset, etcd advertises "the first
+    # routable address of the node", which is not deterministic across a
+    # re-address. listenSubnets defaults to this.
+    #
+    # pod0 is a closed 10G L2 between the three nodes. The management VLAN is
+    # about to become a single 1G NIC shared with everything else management
+    # does, which is the wrong link for quorum traffic.
+    advertisedSubnets:
+      - 10.2.48.0/24

unifi/bgp.conf

@@ -28,10 +28,19 @@ router bgp 64512
  ! advertise extended-nexthop for the IPv6 Unicast SAFI when v6 routes
  ! are carried over a v4 transport, so we run a native v6 session that
  ! carries v6 routes with v6 next-hops and skip the capability dance
- ! entirely. Dynamic neighbors — k8s nodes are SLAAC-addressed on mgmt
- ! LAN; the listen ranges cover the SLAAC suffix space.
+ ! entirely. Dynamic neighbors — nodes are SLAAC-addressed, so the listen
+ ! ranges cover the SLAAC suffix space rather than naming each peer.
+ !
+ ! Both segments are listed while the ingress split lands (#576). The
+ ! cluster peers from mgmt (40) today and moves to ingress (47), and a
+ ! listen range only accepts a session, it does not open one — so having
+ ! both costs nothing and means the move never has a window where the UDM
+ ! is not listening where the nodes are calling from. Drop the 40 ranges
+ ! once every session is established on 47.
  bgp listen range 10.2.40.0/24 peer-group K8S
  bgp listen range fd40::/64 peer-group K8S
+ bgp listen range 10.2.47.0/24 peer-group K8S
+ bgp listen range fd02:47::/64 peer-group K8S
  !
  address-family ipv4 unicast
   neighbor K8S activate