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