claude-botandClaude Opus 5
26ae750219
Gitea runs inside the cluster, so during a cold rebuild every image that only exists at gitea.renner.uno is unpullable — a rehearsal died with the cni-plugins installer in ImagePullBackOff, no macvlan binary, no ceph-san attachment, CephCluster stuck at "Configuring Ceph Mons", OpenBao waiting forever on a PVC. The failure surfaced four layers from its cause. The CI images move to konairius/, published by the build pipeline to Gitea AND ghcr.io with one digest. The manifests keep pointing at Gitea; the node-level fallback (machine.registries.mirrors, written by bootstrap.sh at install time) tries Gitea first and ghcr second, and containerd keeps the repository path when it falls through — so the same path resolves on both. Steady state never leaves the network. The Multus, whereabouts and cni-plugins-installer DaemonSets also gain priorityClassName system-node-critical. Upstream ships them at priority 0: on a rebuild two nodes sat at 99% memory requests when the DaemonSet rolled, both multus pods stayed Pending, and every pod needing a secondary attachment waited on an annotation that could never come — with nothing reporting why. Rollout effect on the live cluster: the three CNI DaemonSets restart once (existing pods keep their networking; only new attachments wait), and the three init containers pull the new tag on their next pod restart. The ghcr side is proven by the Hetzner throwaway runs, which pull through the fallback; eyeball gitea.renner.uno/konairius packages before merging. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>