jakman85andClaude Opus 5
d0db63911a
A merged Cilium config change did nothing, and everything reported success. The Hubble flow exporter (#50, merged 2026-10-04) never took effect: HelmRelease cilium Ready=True, "Helm upgrade succeeded ... cilium.v6" cilium-config hubble-export-file-path: stdout + the allowlist, PRESENT cilium agent pods all three still PRE-MERGE, startTime 2026-10-04T07:11Z exported flow lines 0, 0, 0 Flux every Kustomization Ready=True Cause: the chart's rollOutCiliumPods defaults to false, so Helm rewrites the ConfigMap and leaves the DaemonSet's pod template untouched -- and cilium-agent reads that ConfigMap only at STARTUP. Merged, believed delivered, green everywhere, doing nothing. The same class of failure this repo already guards against elsewhere: a green signal over something that never ran. Confirmed by contrast rather than reasoned: the cgroup fix (#42) DID apply -- both the DaemonSet and the running pod mount /sys/fs/cgroup -- because it changed the POD TEMPLATE, which rolls the DaemonSet on its own. That also explains why the agents are dated 2026-10-04T07:11Z: that was #42's rollout, and nothing has rolled them since. The inertness is specific to ConfigMap-only changes. Set in all three value files to hold the [parity] contract. Cost, and it is the point: every future Cilium config change now rolls the agents instead of waiting for a manual restart. Strictly more honest -- it applies when merged or fails visibly -- but config edits become disruptive by default. maxUnavailable: 1 bounds it to one node at a time. The lease-holding node briefly loses the Gateway, PiHole-DNS and Plex VIPs as it cycles, so merge at a quiet moment. Merging this IS one rollout (the ConfigMap checksum annotation changes the pod template) -- which is what finally activates the Hubble exporter. UNVERIFIED: unreconciled; `filePath: stdout` still unproven and only answerable after the agents restart (check for flow lines immediately); and the rollout's actual impact on LAN DNS is unmeasured. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
platform/cilium
Cilium — CNI, kube-proxy replacement, Gateway API ingress, Egress Gateway, and Hubble.
- Governing ADR: ADR-0002 — CNI, network policy & ingress: Cilium + Gateway API
- Spec: docs/03 — Networking, docs/09 — DNS & Ingress
- Serves: R-NET-01..07, R-DNS-01, R-SEC-02
- Owner: WS-NET (bootstrap shared with WS-INFRA)
What this stub is
A Flux HelmRelease + HelmRepository stub with placeholder values. No cluster exists (Phase 0);
this does not reconcile. Cilium replaces k3s' bundled flannel + kube-proxy + Traefik
(ADR-0001/0002).
Bootstrap vs. GitOps (important)
Per docs/02, Cilium's initial
install is done by the Ansible k3s bootstrap (Phase 1, WS-INFRA), because a cluster needs a CNI
before Flux can run. This HelmRelease manages Cilium configuration thereafter. The Helm values
here MUST stay consistent with the Ansible bootstrap values (kubeProxyReplacement, k8sServiceHost,
k8sServicePort) — otherwise Flux and the bootstrap fight. Coordinate this contract with WS-INFRA.
TODO (later phases — not Phase 0)
- Phase 1 (WS-INFRA/WS-NET): align Helm values with the Ansible bootstrap; pin chart version.
- Phase 2 (WS-NET): default-deny network baseline; Egress Gateway policies; L2 announcement IP
pool +
CiliumL2AnnouncementPolicyfor the ingress VIP; Hubble metrics → kube-prometheus-stack. - Phase 3 (WS-NET): egress-class routing integration with the VPN gateway (ADR-0013).