Compare commits

...
Author SHA1 Message Date
issue-fix-bot 10cfcbba0c fix: [alert] NetbirdVpsBackupStale (netbird-backup) (#714)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
2026-08-29 03:45:07 +00:00
security-bot bcb5110758 chore(image-automation): bump ghcr.io/music-assistant/server:2.10.1
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-08-29 01:20:58 +00:00
k.renner 5c6d59b0b4 Merge pull request 'feat(bootstrap): revive the talos phase, rename the mirror patch' (#710) from cilium-flux-only into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Reviewed-on: k.renner/homelab#710
2026-08-28 14:41:12 +00:00
claude-bot c92aff9e75 docs(talos): rename registry-mirror.yaml to what it actually does
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The name says the bootstrap depends on a registry mirror. Reading the patch list
in the runbook, that is the obvious conclusion — and it would be a serious
problem, because a cold rebuild has no mirror: an in-cluster one cannot exist
before the cluster does.

The file configures no mirror. It writes one containerd setting,
discard_unpacked_layers = false, so that pulled layers stay in the content store
and Spegel can advertise them to peers later. Spegel writes the per-registry
hosts.toml itself at runtime; the file's own comment says a
machine.registries.mirrors block is not needed, and there is none anywhere in
talos/patches. Image pulls at bootstrap go straight to the real registries.

So the alarm the name raises is false, but it is the name doing it, and the cost
of that is someone deciding a rebuild is blocked when it is not.
containerd-layer-retention.yaml describes the single thing inside.

Renamed with git mv and the three references updated. Verified `talosctl gen
config` still produces a config with the renamed patch in the list.
2026-08-28 16:34:05 +02:00
claude-bot cfba60afd0 feat(bootstrap): revive the talos phase and let it install the CNI
The Cilium install had become a block of shell in a runbook for a human to
paste. That is the same rot as a pinned version — nobody runs it between
rebuilds, so nothing tells you when it stopped working. It belongs in the script
that already drives the rest of the bootstrap.

The talos phase was unusable since #581: it passed cilium-cni.yaml whole, and
that file's `$patch: delete` document fails against a config with no
inlineManifests. The file is gone, so the failure is gone with it — reviving the
phase was mostly deleting two lines that referenced it.

It now installs Cilium between `talosctl bootstrap` and the node-Ready wait,
which is the only place it can go: with `cni: none` the kubelet stays NotReady
until a CNI exists, so the wait below would otherwise time out against a cluster
that was never going to converge.

Chart repo, version constraint and values are read out of helmrelease.yaml at
run time, so the script cannot install something different from what Flux
reconciles minutes later. helm takes the semver range verbatim. There is a guard
on the extracted values — the HelmRelease is a two-document file and selecting
the wrong one yields an empty values set that helm silently renders as chart
defaults, which is a failure mode worth catching loudly rather than discovering
in a datapath.

`--wait` because the next step needs a working network, and `upgrade --install`
so a re-run after a partial bootstrap converges instead of erroring.

Verified as far as it can be without wiping a cluster: `talosctl gen config`
with exactly the patch list the script now passes produces a config carrying
cni: none and proxy: disabled, no Cilium manifests, and it validates for metal
mode. The apply-and-bootstrap half is untested since the rewrite, and the
runbook says so — it keeps the manual procedure as the thing to read first and
to fall back on.
2026-08-28 16:31:52 +02:00
k.renner ecb19e5085 Merge pull request 'refactor(cilium): Flux is the only owner' (#709) from cilium-flux-only into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
Reviewed-on: k.renner/homelab#709
2026-08-28 14:30:06 +00:00
claude-bot 17d4c55485 docs(cilium): derive the bootstrap install from the HelmRelease
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The install command in Step 2b hardcoded --version 1.20.1 and the chart repo
URL. That is a copy of the HelmRelease in a text file nobody runs between
rebuilds, so it would have gone stale unnoticed and the next rebuild would have
installed something Flux immediately fought — the same failure the deleted
bootstrap seed produced, in a new place.

Everything now comes out of helmrelease.yaml at the moment the command runs:
the repo URL from the HelmRepository, the values from .spec.values, and
--version from .spec.chart.spec.version verbatim. Helm accepts the semver range
and resolves it exactly as Flux does, so the two cannot pick different releases.

Verified by running the block as written:

    --version ">=1.20.0 <1.21.0"  ->  cilium:v1.20.1, operator-generic:v1.20.1
    enable-bgp-control-plane: "true"    bpf-lb-sock: "true"
    bpf-policy-map-max: "65536"         ipv4-native-routing-cidr: 10.0.0.0/8
    ServiceMonitor objects: 0

which is the config the cluster is running.

The only literal left is --set prometheus.serviceMonitor.enabled=false, and it
is a bootstrap constraint rather than a value: the CRD arrives with the
monitoring stack long afterwards. Because nothing else is overridden,
helm-controller adopts this release instead of replacing it.

This does not make the step unnecessary. Flux's controllers are pods and cannot
reconcile a CNI they need in order to run; something has to seed it. What it
does mean is that the step has nothing left in it to maintain.
2026-08-28 16:29:33 +02:00
claude-bot 1f18599b4c fix(talos): move cni: none and proxy: disabled into cluster.yaml
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Both blocking findings from the review on #709, and both were real.

The deleted cilium-cni.yaml was the only place in the repo that set
cluster.network.cni.name: none and cluster.proxy.disabled: true. They sat in its
second document next to the inline manifest, so removing the file removed them
too — a fresh `talosctl gen config` from this repo's patches would have produced
a config with Talos's default CNI and kube-proxy running, against a Cilium
release configured with kubeProxyReplacement: true. Two runbooks meanwhile
asserted that cluster.yaml supplied both, which it did not.

RUNBOOK-baremetal-conversion.md also still passed `@<cilium additive half>` in
its gen-config example, three lines above prose saying there is no CNI patch any
more. The equivalent block in the cold-rebuild runbook had been fixed; this one
was missed.

Verified the way it should have been in the first place — by running the
runbook's own command rather than inspecting the live cluster:

    talosctl gen config homelab https://k8s.renner.uno:6443 \
      --output-types controlplane \
      --config-patch @talos/patches/cluster.yaml \
      --config-patch @talos/patches/registry-mirror.yaml \
      --config-patch @talos/patches/k8s-1.yaml

    -> cni=none  proxy.disabled=true
    -> 0 cilium manifests

The live cluster could never have caught this. It has carried both settings
since it was built, and the node configs were patched by hand rather than
regenerated, so nothing in the verification touched the path a rebuild actually
uses.
2026-08-28 16:21:18 +02:00
claude-bot bce155b852 refactor(cilium): Flux is the only owner
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Final step of PROPOSAL-cilium-single-owner.md. Talos no longer carries Cilium in
any form, and the HelmRelease is the only place it is configured.

The cluster side is already done and verified:

  - the cilium inline manifest is gone from all three machine configs, applied
    node by node with no reboot and no effect on the running CNI
  - Kubernetes went 1.35.2 -> 1.36.3 in the same operation, with
    --manifests-no-prune so the 22 objects Talos claimed were not deleted
  - Talos's bootstrap-manifest inventory went from 41 entries to 13, and the 28
    cilium/hubble entries are gone. A prune-enabled `upgrade-k8s --dry-run`
    reported 28 deletions before and reports 0 now

That last number is the point of the whole exercise. A bare `upgrade-k8s` used
to destroy the CNI and now does nothing to it.

The inventory entries had to be removed by hand. --manifests-no-prune skips the
prune AND the inventory rewrite, so the run that saved the objects also left
Talos still claiming them — the mine was deferred, not cleared. Talos offers no
way to drop a stale claim without the prune that deletes, so the ConfigMap was
edited directly. It is derived bookkeeping, not configuration, and the result is
verifiable in both directions, which is why this was acceptable where hand-
editing configuration would not be.

Repo side, this commit:

  - deletes talos/patches/cilium-cni.yaml and talos/cilium.yaml
  - adds Step 2b to RUNBOOK-cold-rebuild.md: install Cilium from the HelmRelease
    values with helm, after bootstrap and before Flux. The nodes stay NotReady
    until then, which the runbook now says out loud rather than leaving someone
    to wonder
  - drops the "keep in lockstep" and "THREE COPIES" comments, which described a
    duplication that no longer exists, and replaces them with one note saying
    where Cilium is configured
  - corrects RUNBOOK-baremetal-conversion.md, which told the reader to extract
    half of a file that is gone

bootstrap.sh is left alone. Its talos phase was already dead and is now dead for
a second reason; the runbook says so.

The cost, stated plainly: the cluster no longer forms itself from the machine
config. A cold rebuild needs one documented helm install that it did not need
before. That is the price of Cilium existing in exactly one place.
2026-08-28 16:13:26 +02:00
k.renner 6d543194af Merge pull request 'feat(cilium): track the BGP switch and native-routing CIDRs' (#708) from cilium-track-untracked-settings into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
Reviewed-on: k.renner/homelab#708
2026-08-28 13:47:54 +00:00
claude-bot 96e20146a7 feat(cilium): track the BGP switch and native-routing CIDRs
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Step 1 of the ownership transition in PROPOSAL-cilium-single-owner.md. Nothing
about ownership changes yet — this only moves three live settings out of nowhere
and into git.

enable-bgp-control-plane and both native-routing CIDRs existed in no file at
all. They were applied by hand and are held by the `kubectl-patch` field manager
on cilium-config; server-side apply left them alone, so nothing broke and
nothing reported them. The peering itself was always in git as CRDs in
post-crds/cilium-bgp.yaml, which is what made the gap invisible: BGP looked
configured because its policy was version-controlled, while the switch that
starts the control plane was not. A cold rebuild installs only what git
describes, so it would have come up with two established-looking peers
configured and no BGP at all.

The CIDRs go with it because they are the same decision. They are a masquerading
exception, not a routing statement: pod traffic to 10.0.0.0/8 and fd00::/8
leaves unmasqueraded so LAN services see real pod IPs, and that only works
because BGP advertises the pod CIDRs and gives the UDM a route back. Tracking
one without the other would leave a half-decision in git.

This is not purely a change of ownership, which is why it is its own step and
not folded into a later one. Enabling bgpControlPlane through the chart emits
five companion keys the hand-patch never set, so Cilium has been running on its
own internal defaults for router-id allocation among others. They should agree
with the chart's; if they do not, the sessions re-establish. Verify the peers
after Flux reconciles before moving to step 2.
2026-08-28 15:39:28 +02:00
k.renner c0ed09754d Merge pull request 'docs(cilium): decide the ownership question before changing anything' (#707) from proposal-cilium-single-owner into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Reviewed-on: k.renner/homelab#707
2026-08-28 13:38:20 +00:00
claude-bot 78904a2d62 docs(cilium): VXLAN and BGP are not two layers doing one job
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The proposal called the tunnel redundant because the underlay already has
routes to the pod CIDRs. That reads the two as alternatives, and they are not:
VXLAN carries pod-to-pod directly between nodes, while the BGP-advertised pod
CIDRs exist so traffic from the LAN can reach pods at all, which necessarily
goes through the UDM.

Removing the encapsulation would therefore not remove a layer. It would move
inter-node pod traffic off a direct node-to-node path and onto the underlay,
through the router.

The observation worth keeping is narrower: routingMode is set nowhere, so the
current behaviour is an unexamined chart default rather than a recorded
decision. It happens to be the right default.
2026-08-28 15:36:15 +02:00
claude-bot fd7e4a6acd docs(cilium): decide the ownership question before changing anything
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Cilium is currently owned twice. The 22 objects that make up the whole
installation — both DaemonSets, the operator, both ConfigMaps, the RBAC, the
cilium-secrets namespace — are listed in Talos's bootstrap-manifest inventory
and simultaneously carry Helm's release annotations. cilium-config has three
field managers.

That is not a tidiness problem. It produced a bootstrap seed twelve days behind
the chart, where a Kubernetes upgrade would have downgraded the CNI and switched
off socket load balancing, and it left the BGP control-plane switch and both
native-routing CIDRs existing in no file at all, so a cold rebuild would have
come up without BGP while the peering CRDs in git said otherwise.

This records the decision — Flux owns Cilium, Talos provides only cni: none and
proxy: disabled — and the ordered transition, including why the order matters:
Talos prunes what its inventory used to list and no longer does, so removing the
manifest naively deletes the CNI.

Two claims in it are verified rather than assumed. An OS upgrade does not
reconcile bootstrap manifests: Talos went to 1.13.9 four days ago and Cilium
stayed at 1.20.1 despite the seed saying 1.19.2. And the prune can be tested
before it is run, because NoPrune is honoured by the dry run as well as the
apply.

No code changes here. PR #706 stays WIP until this is agreed.
2026-08-28 15:31:24 +02:00
k.renner e205f58b87 Merge pull request 'feat(woodpecker): liveness probe on the agent healthcheck' (#705) from woodpecker-agent-probe into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Reviewed-on: k.renner/homelab#705
2026-08-28 12:33:21 +00:00
k.renner 7a278da1df Merge pull request 'feat: give the remaining unprobed workloads a health check' (#704) from add-missing-probes into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/e2e Pipeline was successful
ci/woodpecker/cron/security-scan Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Reviewed-on: k.renner/homelab#704
2026-08-28 11:26:20 +00:00
k.renner b0df454fe4 Merge pull request 'fix(paperless): probe a real Django view instead of a TCP connect' (#703) from paperless-http-probes into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
Reviewed-on: k.renner/homelab#703
2026-08-28 11:03:00 +00:00
k.renner 09c10e3fa6 Merge pull request 'fix(gatus): harden the deployment, probe ical-proxy and Loki, add Paperless' (#702) from gatus-hardening into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
Reviewed-on: k.renner/homelab#702
2026-08-28 10:45:50 +00:00
k.renner f1445a2217 Merge pull request 'fix(gatus): drop the file.renner.uno check left behind by #696' (#701) from gatus-drop-file-check into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Reviewed-on: k.renner/homelab#701
2026-08-28 09:55:25 +00:00
k.renner 64462f540a Merge pull request 'fix(gatus): reload the pod when its config changes' (#700) from gatus-config-reload into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
Reviewed-on: k.renner/homelab#700
2026-08-28 09:45:15 +00:00
11 changed files with 273 additions and 3950 deletions
@@ -14,5 +14,10 @@
set -eu
tmp=$(mktemp -d)
trap 'rm -rf "$tmp"' EXIT
sqlite3 /opt/netbird/management/store.db ".backup '$tmp/store.db'"
# sqlite3's busy timeout defaults to 0 ms, so the online-backup API gives
# up the instant it cannot take its read lock on store.db — which is what
# a live netbird-management write does. Wait the writer out instead of
# failing the nightly job; 60 s fits well inside the puller's
# activeDeadlineSeconds: 600 against a normal runtime of ~15-19 s.
sqlite3 -cmd '.timeout 60000' /opt/netbird/management/store.db ".backup '$tmp/store.db'"
tar -C "$tmp" -czf - store.db
+111
View File
@@ -0,0 +1,111 @@
# Cilium: one owner
## The rule
Cilium is owned by **Flux**, through `infrastructure/cilium/helmrelease.yaml`.
Talos provides the conditions for a CNI and nothing else. Never both.
Talos-only would also be a valid answer — it is the simpler one, and it keeps a
cold rebuild self-forming. It is rejected here only because it costs Flux's
reconciliation, image automation and value ergonomics for the one component
most likely to need a careful, reviewed change.
## Where we are
Both own it, which is the state this document exists to end.
- 22 Cilium objects are listed in the `talos-bootstrap-manifests-inventory`
ConfigMap: both DaemonSets, the operator Deployment, both ConfigMaps, the
ServiceAccounts, the ClusterRoles/Bindings and the `cilium-secrets`
namespace. That is the whole installation, not a fragment.
- The same objects carry `meta.helm.sh/release-name: cilium`.
- `cilium-config` has three field managers: `helm-controller`, `talos` and
`kubectl-patch`.
The consequences are not theoretical. The seed sat at Cilium 1.19.2 for twelve
days while the chart was on 1.20.1, and `upgrade-k8s --dry-run` shows that a
Kubernetes upgrade in that state downgrades the CNI and switches off socket
load balancing. Separately, `enable-bgp-control-plane` and the two
native-routing CIDRs exist in no file at all — applied by hand, so a cold
rebuild would have come up with BGP off while the peering CRDs in git made it
look configured.
Nothing fails when these drift. That is the whole problem.
## Target state
**Talos** keeps exactly this, in `talos/patches/cluster.yaml`, and gains nothing
else:
```yaml
cluster:
network:
cni:
name: none
proxy:
disabled: true
```
No `inlineManifests` entry for cilium. `talos/patches/cilium-cni.yaml` is
deleted.
**Flux** owns everything else. `helmrelease.yaml` is the single source for
every Cilium setting, including the three that were hand-patched.
**A cold rebuild** installs Cilium once, by hand, between `talosctl bootstrap`
and the Flux phase, from the same HelmRelease values. This is the cost of the
decision and it is deliberate: the cluster no longer forms itself from the
machine config alone. Given `bootstrap.sh talos` is already dead and Step 2 of
RUNBOOK-cold-rebuild.md is already a manual procedure, the marginal cost is one
documented command.
## Transition
The order matters, because Talos prunes what its inventory used to list and no
longer does — removing the manifest naively deletes the CNI.
1. **Track the untracked settings first.** `bgpControlPlane.enabled`,
`ipv4NativeRoutingCIDR`, `ipv6NativeRoutingCIDR` into the HelmRelease. Note
this is not a pure change of ownership: enabling bgpControlPlane through the
chart also emits five companion keys the hand-patch never set, so Cilium has
been running on its own defaults for router-id allocation. Verify the BGP
sessions after Flux applies it.
2. **Remove cilium from `cluster.inlineManifests`.** This has no immediate
effect. Evidence: Talos was upgraded to 1.13.9 four days ago and Cilium
stayed at 1.20.1 — an OS upgrade does not reconcile bootstrap manifests.
Only `upgrade-k8s` does.
3. **Prove the prune before running it.** `upgrade-k8s --dry-run
--manifests-no-prune` and confirm the 22 objects are not listed for
deletion. `NoPrune` is honoured by the dry run as well as the apply
(`pkg/cluster/kubernetes/talos_managed.go`), so this is a real test and not
a reading of the flag description.
4. **Run `upgrade-k8s --manifests-no-prune`.** The inventory is rewritten
without Cilium and the objects survive. Helm is then sole owner. This is the
same run that takes Kubernetes 1.35.2 → 1.36.3.
5. **Verify** the inventory lists no Cilium, the agents did not restart, and
the BGP sessions are still established.
6. **Delete `talos/patches/cilium-cni.yaml`** and add the install step to
RUNBOOK-cold-rebuild.md.
## Not part of this, and not a defect either
The cluster runs `routingMode: tunnel` (the chart default, set nowhere) while
also advertising pod CIDRs over BGP. That is not one layer too many — the two
carry different directions:
- **VXLAN** carries pod-to-pod between nodes, directly, node to node.
- **BGP** gives the UDM routes into the pod CIDRs so traffic from the LAN can
reach pods. That path goes through the router by definition.
Dropping the encapsulation in favour of native routing would not simplify
anything; it would push inter-node pod traffic onto the underlay path and
through the UDM, replacing a direct node-to-node hop with a router hop.
`routingMode` being unset is still worth knowing — the current behaviour is a
default nobody chose rather than a decision anyone recorded — but the default
is the right one here, and this document is not the place to revisit it.
+6 -5
View File
@@ -198,8 +198,7 @@ talosctl gen secrets --from-controlplane-config cp.yaml -o secrets.yaml
talosctl gen config homelab https://k8s.renner.uno:6443 \
--with-secrets secrets.yaml --output-types controlplane \
--config-patch @talos/patches/cluster.yaml \
--config-patch @<cilium additive half> \
--config-patch @talos/patches/registry-mirror.yaml \
--config-patch @talos/patches/containerd-layer-retention.yaml \
--config-patch @talos/patches/k8s-N.yaml -o install.yaml
```
@@ -208,9 +207,11 @@ Confirm `cluster.id` matches the running cluster before applying.
Strip the generated `HostnameConfig` document — it collides with
`machine.network.hostname` from the per-node patch. `bootstrap.sh` does the same.
`cilium-cni.yaml` cannot be passed whole: its `$patch: delete` document fails
against a base with no `inlineManifests` (issue #581). Use only the additive
second document.
There is no CNI patch to pass any more. Talos supplies only `cni: none` and
`proxy: disabled`; Cilium is installed from its HelmRelease values, which is
Step 2b of RUNBOOK-cold-rebuild.md. A node converted into an existing cluster
gets its CNI from the Cilium DaemonSet already running there, so nothing extra
is needed here.
Validate:
+65 -13
View File
@@ -136,11 +136,18 @@ in `talos/patches/k8s-N.yaml`.
## Step 2 — talos: form the cluster + get kubeconfig
**Do not use `kubernetes/bootstrap.sh talos`.** That phase cannot generate a
config: it passes `talos/patches/cilium-cni.yaml` whole, and that file's
`$patch: delete` document fails against a base with no `inlineManifests`
(#581). Its other phases — `flux`, `wait-apps` — are still used, in Steps 3, 5
and 6; only config generation is broken.
`kubernetes/bootstrap.sh talos` does this, including the CNI install that used
to be a hand-typed step. It was unusable for months because it passed
`cilium-cni.yaml` whole and the file's `$patch: delete` document failed against
a fresh config (#581); that file no longer exists, so the failure is gone with
it.
Verified as far as it can be without wiping a cluster: `talosctl gen config`
with exactly the patches the script passes produces a config carrying
`cni: none` and `proxy: disabled` that passes `talosctl validate --mode metal`.
The apply-and-bootstrap half has not been exercised since the rewrite. Read the
manual procedure below before running the script, so you know what it is doing
and can take over at any step if it stops.
The procedure below is what actually works, and is the same one
`RUNBOOK-baremetal-conversion.md` uses.
@@ -160,17 +167,17 @@ for N in 1 2 3; do
talosctl gen config homelab https://k8s.renner.uno:6443 \
--with-secrets secrets.yaml --output-types controlplane \
--config-patch @talos/patches/cluster.yaml \
--config-patch @<cilium additive half> \
--config-patch @talos/patches/registry-mirror.yaml \
--config-patch @talos/patches/containerd-layer-retention.yaml \
--config-patch @talos/patches/k8s-$N.yaml -o install-k8s-$N.yaml
done
```
Two things the generator gets wrong for this repo, both of which will bite
silently:
There is no CNI patch here any more. Talos supplies `cni: none` and
`proxy: disabled` from `cluster.yaml` and nothing else; Cilium is installed in
Step 2b below. See PROPOSAL-cilium-single-owner.md.
One thing the generator gets wrong for this repo, and it bites silently:
- **`cilium-cni.yaml` cannot be passed whole** — extract only its additive
second document. See issue #581.
- **Strip the generated `HostnameConfig`** — it collides with
`machine.network.hostname` from the per-node patch.
@@ -209,8 +216,53 @@ talosctl -n k8s-1.srv.renner.uno bootstrap
talosctl -n k8s-1.srv.renner.uno kubeconfig .
```
Ends when all three nodes are `Ready`. `scripts/import-cluster-access.sh` is the
supported way to get the kubeconfig into place afterwards.
`scripts/import-cluster-access.sh` is the supported way to get the kubeconfig
into place afterwards.
The nodes will **not** reach `Ready` here. Talos is configured with `cni: none`,
so there is no pod network until Step 2b — expect `NotReady` with
`container runtime network not ready` and carry on.
## Step 2b — cilium: install the CNI
Nothing schedules without it, Flux included, so this comes before Step 3. Talos
no longer carries a rendered copy of Cilium; `helmrelease.yaml` is the only
place it is configured, and this installs from those same values so the cluster
comes up on what git describes rather than on a second, drifting copy. See
PROPOSAL-cilium-single-owner.md for why it works this way.
`bootstrap.sh talos` already did this. What follows is the same thing by hand,
for when the script stopped partway or you are not using it.
Every input is read out of `helmrelease.yaml`. Nothing here is a version or a
URL you have to keep in step with anything — copy the block as it stands:
```sh
HR=kubernetes/infrastructure/cilium/helmrelease.yaml
helm repo add cilium "$(yq -r 'select(.kind == "HelmRepository") | .spec.url' "$HR")"
helm repo update cilium
yq 'select(.kind == "HelmRelease") | .spec.values' "$HR" > /tmp/cilium-values.yaml
helm install cilium cilium/cilium \
--version "$(yq -r 'select(.kind == "HelmRelease") | .spec.chart.spec.version' "$HR")" \
--namespace kube-system \
-f /tmp/cilium-values.yaml \
--set prometheus.serviceMonitor.enabled=false
```
`--version` takes the HelmRelease's range verbatim; helm resolves it to the same
release Flux would pick, so the two cannot diverge. That is the point of writing
it this way — a pinned version in a runbook is a copy nobody maintains, and the
next rebuild installs something the HelmRelease will immediately fight.
The one literal is `serviceMonitor`, disabled for this install only: its CRD
arrives with the monitoring stack much later and the object would fail to apply.
Flux adds the real one once it owns the release. Nothing else is overridden,
which is what lets helm-controller adopt this release rather than replace it.
Ends when all three nodes are `Ready`.
## Step 3 — flux: bootstrap GitOps **from the GitHub mirror** (break-glass)
@@ -55,7 +55,7 @@ spec:
# stdlib only; Flux keeps the tag in lockstep via the shared image
# policy) — no extra dependency.
- name: reconcile-publish-ip
image: ghcr.io/music-assistant/server:2.10.0 # {"$imagepolicy": "flux-system:music-assistant"}
image: ghcr.io/music-assistant/server:2.10.1 # {"$imagepolicy": "flux-system:music-assistant"}
command: ["/app/venv/bin/python", "/scripts/reconcile.py"]
volumeMounts:
- name: data
@@ -65,7 +65,7 @@ spec:
readOnly: true
containers:
- name: music-assistant
image: ghcr.io/music-assistant/server:2.10.0 # {"$imagepolicy": "flux-system:music-assistant"}
image: ghcr.io/music-assistant/server:2.10.1 # {"$imagepolicy": "flux-system:music-assistant"}
env:
- name: LOG_LEVEL
value: info
+41 -4
View File
@@ -21,6 +21,13 @@ set -euo pipefail
TALOS_DIR="$(cd "$(dirname "$0")/talos" && pwd)"
REPO_ROOT="$(cd "$(dirname "$0")/.." && pwd)"
# Cilium's single source of truth. Talos ships `cni: none` (talos/patches/
# cluster.yaml) and nothing else, so the CNI has to be installed here, between
# `talosctl bootstrap` and Flux — Flux's own controllers are pods and cannot
# reconcile the network they need in order to start. Everything the install
# needs is read out of this file at run time so there is no second copy of a
# version or a value to keep in step. See PROPOSAL-cilium-single-owner.md.
CILIUM_HR="$REPO_ROOT/kubernetes/infrastructure/cilium/helmrelease.yaml"
ACCESS_STAGING="$REPO_ROOT/kubernetes/access-staging"
NODES=(k8s-1 k8s-2 k8s-3)
# No dedicated workers since the k8s-edge VM was retired (2026-07-02) —
@@ -82,9 +89,11 @@ if phase_runs talos; then
echo -e "${YELLOW}=== Phase: Talos bootstrap ===${NC}"
command -v talosctl >/dev/null || fail "talosctl not found"
command -v kubectl >/dev/null || fail "kubectl not found"
command -v helm >/dev/null || fail "helm not found (needed to install the CNI)"
command -v yq >/dev/null || fail "yq not found (needed to read the Cilium HelmRelease)"
[[ -f "$TALOS_DIR/patches/cluster.yaml" ]] || fail "cluster.yaml patch not found"
[[ -f "$TALOS_DIR/patches/cilium-cni.yaml" ]] || fail "cilium-cni.yaml patch not found"
[[ -f "$TALOS_DIR/patches/registry-mirror.yaml" ]] || fail "registry-mirror.yaml patch not found"
[[ -f "$TALOS_DIR/patches/containerd-layer-retention.yaml" ]] || fail "containerd-layer-retention.yaml patch not found"
[[ -f "$CILIUM_HR" ]] || fail "cilium helmrelease not found at $CILIUM_HR"
step 0 "Generating Talos configs..."
TALOS_GEN_DIR=$(mktemp -d)
@@ -123,8 +132,7 @@ if phase_runs talos; then
if err=$(talosctl apply-config --insecure -n "$node_ip" \
--file "$base_config" \
--config-patch "@$TALOS_DIR/patches/cluster.yaml" \
--config-patch "@$TALOS_DIR/patches/cilium-cni.yaml" \
--config-patch "@$TALOS_DIR/patches/registry-mirror.yaml" \
--config-patch "@$TALOS_DIR/patches/containerd-layer-retention.yaml" \
--config-patch "@$TALOS_DIR/patches/${node}.yaml" 2>&1); then
echo " applied via $node_ip ${GREEN}(OK)${NC}"
return 0
@@ -174,6 +182,35 @@ if phase_runs talos; then
done
ok
step 0 "Installing Cilium (CNI)..."
# Must run before the node-Ready wait below: with `cni: none` the kubelet
# reports NotReady until a CNI is present, so that loop would time out.
#
# Chart repo, version constraint and values all come out of the HelmRelease
# so this cannot drift from what Flux will reconcile minutes later. helm
# accepts the semver range verbatim and resolves it the same way Flux does.
#
# serviceMonitor is the one override, and it is a bootstrap constraint
# rather than a value: its CRD arrives with the monitoring stack much
# later, and the object would fail to apply. Nothing else is overridden,
# which is what lets helm-controller adopt this release instead of
# replacing it.
CILIUM_VALUES=$(mktemp)
yq 'select(.kind == "HelmRelease") | .spec.values' "$CILIUM_HR" > "$CILIUM_VALUES"
grep -q 'policyMapMax' "$CILIUM_VALUES" \
|| fail "extracted Cilium values look wrong (no policyMapMax) — check $CILIUM_HR"
helm repo add cilium "$(yq -r 'select(.kind == "HelmRepository") | .spec.url' "$CILIUM_HR")" >/dev/null
helm repo update cilium >/dev/null
helm upgrade --install cilium cilium/cilium \
--version "$(yq -r 'select(.kind == "HelmRelease") | .spec.chart.spec.version' "$CILIUM_HR")" \
--namespace kube-system \
-f "$CILIUM_VALUES" \
--set prometheus.serviceMonitor.enabled=false \
--wait --timeout 10m
rm -f "$CILIUM_VALUES"
ok
step 0 "Waiting for K8s nodes..."
expected=${#ALL_NODES[@]}
for i in $(seq 1 60); do
@@ -33,6 +33,13 @@ spec:
remediation:
retries: 3
values:
# THIS IS THE ONLY PLACE CILIUM IS CONFIGURED. Talos used to carry a
# rendered copy as a bootstrap inline manifest, so every setting existed
# two or three times and nothing enforced agreement — see
# PROPOSAL-cilium-single-owner.md for what that cost. Talos now provides
# only `cni: none` and `proxy: disabled`; a cold rebuild installs Cilium
# from these values with helm before Flux takes over.
#
# Rolls the agent DaemonSet when cilium-config changes. Cilium reads
# datapath options once at agent start and the chart puts no config
# checksum on the pod template, so without this a changed ConfigMap leaves
@@ -50,8 +57,6 @@ spec:
# and every identity costs one entry per allowed (direction, proto, port)
# in every endpoint's policy map, cluster-wide. Nothing selects on these
# labels in policy, so they buy identity churn and nothing else.
# Keep in lockstep with kubernetes/talos/patches/cilium-cni.yaml and
# kubernetes/talos/cilium.yaml.
labels: '!woodpecker-ci\.org/.* !step$'
ipv6:
enabled: true
@@ -76,10 +81,6 @@ spec:
# cilium_bpf_map_pressure. Sized at map creation, so it takes an agent
# restart.
#
# THREE COPIES of this key exist — here, talos/patches/cilium-cni.yaml
# and talos/cilium.yaml. The latter two are what a cold rebuild installs
# from. Nothing enforces agreement; grep bpf-policy-map-max before
# changing it.
policyMapMax: 65536
# VLAN ids the eBPF datapath is allowed to pass. Without this it drops
# VLAN-tagged frames, accounted as "VLAN traffic disallowed by VLAN
@@ -140,3 +141,28 @@ spec:
enabled: true
externalIPs:
enabled: true
# BGP to the UDM. The peering itself has always been in git as CRDs in
# post-crds/cilium-bgp.yaml — but the switch that starts the control plane
# was not, and neither were the CIDRs below. They were applied by hand and
# held by the `kubectl-patch` field manager on cilium-config. Server-side
# apply left them alone, so nothing broke and nothing noticed; a cold
# rebuild would have come up with BGP off while the CRDs said otherwise.
#
# This is not a free change of ownership. Enabling bgpControlPlane through
# the chart also emits companion keys the hand-patch never set —
# bgp-secrets-namespace, bgp-router-id-allocation-mode and -ip-pool,
# enable-bgp-control-plane-status-report, enable-bgp-legacy-origin-attribute
# — so Cilium has been running on its own defaults for those. Router-id
# allocation is the one to watch: if the chart's default disagrees with
# Cilium's, the sessions re-establish.
bgpControlPlane:
enabled: true
# Masquerading exception, not a routing statement: pod traffic to these
# ranges leaves unmasqueraded, so LAN services see real pod IPs. That only
# works because BGP advertises the pod CIDRs, which is what gives the UDM a
# route back. The two settings are one decision and have to move together.
#
# Pod CIDRs are 10.244.0.0/16 and fd10:244::/48 (talos/patches/cluster.yaml);
# the supernets here cover the LAN as well, which is the point.
ipv4NativeRoutingCIDR: 10.0.0.0/8
ipv6NativeRoutingCIDR: fd00::/8
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
+10
View File
@@ -75,4 +75,14 @@ cluster:
serviceSubnets:
- 10.96.0.0/12
- fd10:96::/112
# Talos ships no CNI and no kube-proxy; Cilium provides both. These two
# keys used to live in the deleted cilium-cni.yaml alongside the rendered
# manifest, which is why they moved here when Cilium became Flux-only —
# without them a freshly generated config comes up on Talos's default CNI
# with kube-proxy running, which collides with the chart's
# kubeProxyReplacement: true. See PROPOSAL-cilium-single-owner.md.
cni:
name: none
proxy:
disabled: true
allowSchedulingOnControlPlanes: true