k3s-agent: cloud-init verwaltet /etc/hosts nicht mehr; Befund Netzausfall 20.10. (BETRIEB §14.x)

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

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 <alte IP>: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

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).

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