From 1f3b12d099bd776d9231ce72973af8962079bfd9 Mon Sep 17 00:00:00 2001 From: Robert Rapp Date: Tue, 20 Oct 2026 16:31:56 +0200 Subject: [PATCH] =?UTF-8?q?k3s-agent:=20cloud-init=20verwaltet=20/etc/host?= =?UTF-8?q?s=20nicht=20mehr;=20Befund=20Netzausfall=2020.10.=20(BETRIEB=20?= =?UTF-8?q?=C2=A714.x)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Fable 5.1 --- docs/BETRIEB.md | 11 +++++++++++ .../plans/2026-10-12-aufbau-cluster-knaster.md | 4 ++++ .../proxmox/ansible/roles/k3s-agent/tasks/main.yml | 11 +++++++++++ 3 files changed, 26 insertions(+) diff --git a/docs/BETRIEB.md b/docs/BETRIEB.md index a0950bd..85130e5 100644 --- a/docs/BETRIEB.md +++ b/docs/BETRIEB.md @@ -241,6 +241,17 @@ Die GPU-VMs bilden mit der Dienst-VM `k3s` einen k3s-Cluster (v1.36.5+k3s1). Ste - **Aktualisieren:** `k3s_version` in `roles/k3s-server/defaults` und `roles/k3s-agent/defaults` anheben, `playbooks/k3s.yml`; erst Server, dann Agents (so läuft das Playbook). Kubernetes-Versionen immer nur eine Minor-Stufe je Schritt. - **Stromausfall:** VM 110 startet automatisch (onboot, HA). Agents verbinden sich neu, Pods starten mit den Knoten. Sollte `k3s` auf einen anderen Knoten umziehen, bleibt die Adresse (gleiche MAC), sobald die DHCP-Reservierung am DC steht. +### 14.x Serveradresse und /etc/hosts der Agents (Befund 20.10.2026) + +Die k3s-VM hat seit 20.10. die feste Adresse 192.168.100.124 (Site `service_vms.k3s.ip`, Cloud-Init per tofu; davor +DHCP, nach einem Netzausfall kam .131 und alle Knoten waren NotReady). DHCP-Reservierung am DC für .124 +(MAC bc:24:11:a5:d5:52) bleibt sinnvoll. Die Agents erreichen den Server als `k3s.knaster` über /etc/hosts; cloud-init +darf die Datei nicht mehr verwalten (Rolle k3s-agent schreibt `/etc/cloud/cloud.cfg.d/99-knaster-hosts.cfg`). +Symptom bei Verlust: `journalctl -u k3s-agent` zeigt „dial tcp :6443: no route to host“, die Datei +`/var/lib/rancher/k3s/agent/etc/k3s-agent-load-balancer.json` hält die alte Adresse. Abhilfe: Eintrag in /etc/hosts +setzen, alte Adresse in der JSON-Datei ersetzen, `systemctl restart k3s-agent` (dauert, Pods laufen weiter). +nex-admin auf appsrv08 verweist mit NEX_ADMIN_K8S_URL und NEX_K3S_HOST ebenfalls auf .124. + ## 15. Verwaltung übergeben oder teilen (seit 19.10.2026, „Weg 1“) Die Verwaltung hängt an Personen, nicht an einem Gerät. Einstieg für jede Person ist **ops** (Bastion): eigener diff --git a/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md b/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md index 92d8794..35aca7a 100644 --- a/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md +++ b/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md @@ -507,3 +507,7 @@ Cluster und GPU-VMs laufen über „GPU-Knoten 3“, der Infra-LXC über „Prox **Zuordnung der knaster-Roadmap (PLAN §8):** 0 Fundament → Phasen 0–5 · 1 Data Plane → Phase 6 · 2 Kernpfad → Phase 7 · 3–6 → Phase 9. **Zuordnung nex-STT-Plan:** Task 0 erledigt · Task 1 → 3.3 · Tasks 2–4 → 6.2 · Tasks 5–8 → Phase 7. + +- [x] 20.10. Netzausfall: k3s-VM bekam per DHCP .131, Agents ohne `k3s.knaster` in /etc/hosts (cloud-init) → alle + Knoten NotReady. Behoben: feste Adresse .124 (Site + tofu, VM-Neustart), Hosts-Eintrag auf allen GPU-VMs, Rolle + k3s-agent setzt `manage_etc_hosts: false`; BETRIEB.md §14.x. Offen: DHCP-Reservierung .124 am DC (Task 0.2). diff --git a/platform/proxmox/ansible/roles/k3s-agent/tasks/main.yml b/platform/proxmox/ansible/roles/k3s-agent/tasks/main.yml index dad47d0..288ff9e 100644 --- a/platform/proxmox/ansible/roles/k3s-agent/tasks/main.yml +++ b/platform/proxmox/ansible/roles/k3s-agent/tasks/main.yml @@ -1,5 +1,16 @@ # k3s-Agent neben Docker: k3s bringt sein eigenes containerd mit und erkennt nvidia-container-runtime # von selbst (Runtime "nvidia"). Docker bleibt für die bestehenden Compose-Stacks, bis sie umgezogen sind. +# cloud-init (Ubuntu-Cloud-Image: manage_etc_hosts template) schreibt /etc/hosts bei jedem Start neu und warf den +# Eintrag k3s.knaster weg (Befund 20.10.: nach VM-Neustart am 15.10. lebten die Agents nur vom gemerkten Serverstand; +# als die k3s-VM per DHCP eine andere Adresse bekam, waren alle Knoten NotReady). +- name: cloud-init verwaltet /etc/hosts nicht mehr + ansible.builtin.copy: + dest: /etc/cloud/cloud.cfg.d/99-knaster-hosts.cfg + content: | + # Rolle k3s-agent: /etc/hosts gehört Ansible (Eintrag k3s.knaster), nicht cloud-init + manage_etc_hosts: false + mode: "0644" + - name: Server-Name in /etc/hosts (Adresse per DHCP, D5) ansible.builtin.lineinfile: path: /etc/hosts