claude-botandClaude Opus 5.5
d6a9575fcd
What differs between sites moves out of cluster-wide config into the Talos site patches (site-homelab.yaml, site-qemu.yaml), and the consumers read it from there: - nodeIP.validSubnets lists IPv4 first, as the live nodes run. Talos keeps the order (siderolabs/net FilterIPs) and the first entry becomes the primary node IP; with fd02:46::/64 first, kube-apiserver exits with 'service IP family "10.96.0.0/12" must match public address family'. - etcd.advertisedSubnets (VLAN 46, a fact of the home network) moves unchanged from cluster.yaml to site-homelab.yaml; the rendered production config is byte-identical. - Pod routing (routingMode, autoDirectNodeRoutes, directRoutingDevice) and the native-routing CIDRs are a cilium-site ConfigMap per site patch, read by the Cilium HelmRelease via valuesFrom. bootstrap.sh merges it the same way: site values first, HelmRelease values on top. Production renders unchanged (helm template, TLS secrets excluded). - Each site patch states its node resolver list (ResolverConfig: k8s-gateway first, then the site's resolver) and k8s-gateway's upstream as a k8s-gateway-site ConfigMap, read by the k8s-gateway HelmRelease via valuesFrom. bootstrap.sh installs k8s-gateway right after the nodes are Ready, from the HelmRelease under the site values, and Flux adopts it: until k8s-gateway answers, every lookup waits out the node's 2 s read timeout and pods resolve nothing, Flux included. - bootstrap.sh creates Cilium's cni.confPath subdirectory with a hostNetwork pod per node (/etc/cni is read-only to the kubelet on Talos) and applies Multus right after Cilium; without it the kubelet reports "cni plugin not initialized" and nothing schedules on a cold cluster. - site-homelab.yaml labels its nodes net.renner.uno/pod-table=47 (table 47 exists only where the site routes pod traffic into it); k8s-1..3 label hardware.renner.uno/intel-gpu and net.renner.uno/iot-vlan, the hardware each machine has. The workloads select on these labels in later changes. Rollout order for production: the cilium-site and k8s-gateway-site ConfigMaps must exist before the HelmReleases reconcile (valuesFrom is not optional). Talos creates inline manifests on a config change but never updates them; changes go through talosctl upgrade-k8s. The node labels go on with talosctl patch, no reboot. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
homelab
GitOps source for the Renner homelab cluster. Flux applies master to
production, so every merge is a production change. Changes go in by pull
request only; see CONTRIBUTING.md for YAML conventions.
Change rules that protect Home Assistant
Owner decision (REN-240, REN-243). Home Assistant runs the house, so it gets two rules on top of normal review.
1. Disruptive work runs only 02:00–05:00 Europe/Berlin
Planned work that can restart Home Assistant or disrupt the cluster is merged and applied only between 02:00 and 05:00 Europe/Berlin. That covers:
- node drain, node reboot, Talos upgrade
- CNI (Cilium, Multus) and cluster-wide network policy
- storage (Rook/Ceph, CSI, snapshot controller, CNPG operator)
- Flux core (
kubernetes/clusters/*/flux-system/, Flux controllers) - Authentik
- OpenBao, including secret rotation that restarts consumers
- anything in
kubernetes/apps/home-assistant/
A PR in this list states in its description that it waits for the window. Flux applies on merge, so "wait for the window" means merge in the window, not just apply. If unsure whether a change is disruptive, treat it as disruptive.
Not covered: Home Assistant image bumps by Flux image automation. They stay fully automatic by owner decision. If one breaks Home Assistant, roll it back with RUNBOOK-home-assistant-image-rollback.md. An incident rollback is not planned work; the owner decides its timing.
2. HA-impact review before merge
Every PR that touches kubernetes/apps/home-assistant/, or makes a
cluster-wide disruptive change from the list above, needs an HA-impact
review before merge: a named reviewer states in the PR what Home
Assistant will notice (restart, lost integration, lost history, none) and
approves.
- Reviewer: Hestia, the Home Assistant maintainer.
- Until Hestia exists: the owner does the HA-impact review.
This is in addition to the normal review and merge by Argus. Argus does not merge such a PR without the HA-impact approval.