eho/register-referentie
1
0
Fork 0
Code Issues 10 Pull Requests 1 Actions Packages Projects Releases 1 Wiki Activity

docs(k8s): split the taint fix from the registry patch (refs #175)

Browse Source 
Talos 1.14 rejects a `patch mc` that sets `cluster.allowSchedulingOnControlPlanes`
— the field left the v1alpha1 schema, the way `machine.install` did — and the
rejection discards the rest of the patch with it, so the registry mirror never
lands and the failure moves from Pending pods to ImagePullBackOff without ever
saying so. Document the two as separate steps, and correct the claim that the
taint has to be patched away: `kubectl taint` is what §1 prescribes and it holds
until the node re-registers.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
not
2026-09-18 16:06:24 +02:00
co-authored by Claude Opus 5
parent d17e79959b
commit de6db7d35b
1 changed files with 16 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/runbooks/kubernetes-talos.md
+16 -12
View File
@@ -368,29 +368,33 @@ merge gate, so the workflow deploys without re-running the checks.
**Prerequisite: the VM must have been installed with the §1 patch.** A stock Talos config **Prerequisite: the VM must have been installed with the §1 patch.** A stock Talos config
gives you a node that still carries the control-plane taint and knows nothing about the gives you a node that still carries the control-plane taint and knows nothing about the
plain-HTTP registry, which the deploy hits in that order: the `registry` pod sits `Pending` plain-HTTP registry, and the deploy hits those in that order: the `registry` pod sits
until `rollout status` times out, and once that's fixed every repo image fails to pull. Both `Pending` until `rollout status` times out, and once that is fixed every repo image fails to
are one patch, applied live — no reboot: pull. Two separate fixes:
```bash ```bash
# on the Fedora host # on the Fedora host — 1. let workloads onto the only node (§1)
cat > /tmp/talos-patch.yaml <<'YAML' export KUBECONFIG=~/talos-kubeconfig-local
cluster: kubectl taint node --all node-role.kubernetes.io/control-plane-
allowSchedulingOnControlPlanes: true
# 2. trust the in-cluster registry over plain HTTP (§2)
cat > /tmp/registry-patch.yaml <<'YAML'
machine: machine:
certSANs:
- <TALOS_VM_IP>
registries: registries:
mirrors: mirrors:
"<TALOS_VM_IP>:30500": "<TALOS_VM_IP>:30500":
endpoints: endpoints:
- http://<TALOS_VM_IP>:30500 - http://<TALOS_VM_IP>:30500
YAML YAML
talosctl -n <TALOS_VM_IP> -e <TALOS_VM_IP> patch mc --patch @/tmp/talos-patch.yaml talosctl -n <TALOS_VM_IP> -e <TALOS_VM_IP> patch mc --patch @/tmp/registry-patch.yaml
``` ```
`allowSchedulingOnControlPlanes` rather than `kubectl taint node --all …-` because the Keep those two apart. On Talos 1.14 a patch that also sets
controller puts the taint back; the patch is what makes it stick across a reboot. `cluster.allowSchedulingOnControlPlanes` is rejected with *".cluster.allowSchedulingOnControlPlanes
is already set in v1alpha1 config"* — the field moved out of the v1alpha1 schema, the same way
`machine.install` did (§1) — and the rejection takes the whole patch with it, so the mirror
silently doesn't land either. `kubectl taint` is the documented way (§1); it is undone if the
node ever re-registers, which is a reboot, not a deploy.
The cluster's API and registry are not exposed publicly, so the job forwards them over the The cluster's API and registry are not exposed publicly, so the job forwards them over the
same SSH hop the Gitea-runner pipeline uses: same SSH hop the Gitea-runner pipeline uses: