Plan Task 0.4 abgehakt (Tests auf ops: 161 bestanden)

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

@@ -159,16 +159,17 @@ Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeins
 **Interfaces:**
 - Produces: Proxmox-Knoten `pve44`, `pve46`, `pve48`, `pve52`, `pve61`, dazu die Inventar-Knoten `gode-pc-05` und `gode-pc-06` (Ada, ohne Proxmox, nur im Inventar). PCI-Mappings `gpu-m4000-pve44`, `gpu-p2000-pve44`, `gpu-m4000-pve46`, `gpu-p2000-pve46`, `gpu-m4000-pve52`, `gpu-m4000-pve48`, `gpu-p2000-pve48`. GPU-VMs `gpu-pve44` (vmid 244), `gpu-pve46` (246), `gpu-pve48` (248), `gpu-pve52` (252). Infra-LXC `infra` (vmid 101). Ansible-Gruppen `pve_all`, `pve_gpu_hosts`, `pve_kiosk`.
 
-- [ ] **Step 1: Failing test.** In `test_inventory_validate.py` den Test `test_site_knaster_matches_real_nodes` anlegen:
+- [x] **Step 1: Failing test.** In `test_inventory_validate.py` den Test `test_site_knaster_matches_real_nodes` anlegen:
   - Die Inventar-Knoten sind genau `{pve44, pve46, pve48, pve52, pve61, gode-pc-05, gode-pc-06}`.
   - `proxmox.yaml` enthält keine IP aus `10.20.0.0/24`.
   - Jedes `pci_mappings[*].node` und jedes `vms[*].node` liegt in `{pve44, pve46, pve48, pve52}`.
-- [ ] **Step 2:** `make test` → FAIL (alte Annahmen `pve-ada`, `pve1`–`pve4`).
+- [x] **Step 2:** `make test` → FAIL (alte Annahmen `pve-ada`, `pve1`–`pve4`).
-- [ ] **Step 3:** Site-Dateien umschreiben. Werte für IDs und Pfade aus `lspci -nn` und dem Healthcheck: M4000 `10de:13f1` auf `0000:01:00`, P2000 `10de:1c30` auf `0000:02:00`. Gateway `192.168.100.1`, DNS `192.168.100.120`, keine `vlan_svc`, Gast-IPs aus D5. Die M4000 bleiben `disabled: true` bis zum Benchmark-Tag (Task 3.3). Die Ada-Slots (`tier1-general`, `tier1-flex`, `tts-de-hq`) behalten vorerst ihre Engine. In `registry.yaml` entfallen bei ihnen nur `pve_node` und `vmid`. Die Umstellung auf die Worker-Registry folgt in Task 6.4.
+- [x] **Step 3:** Site-Dateien umschreiben. Werte für IDs und Pfade aus `lspci -nn` und dem Healthcheck: M4000 `10de:13f1` auf `0000:01:00`, P2000 `10de:1c30` auf `0000:02:00`. Gateway `192.168.100.1`, DNS `192.168.100.120`, keine `vlan_svc`, Gast-IPs aus D5. Die M4000 bleiben `disabled: true` bis zum Benchmark-Tag (Task 3.3). Die Ada-Slots (`tier1-general`, `tier1-flex`, `tts-de-hq`) behalten vorerst ihre Engine. In `registry.yaml` entfallen bei ihnen nur `pve_node` und `vmid`. Die Umstellung auf die Worker-Registry folgt in Task 6.4.
-- [ ] **Step 4:** `make test && make validate` → PASS. `knaster placement plan --inventory sites/knaster/inventory.yaml` liefert eine Zuordnung ohne Fehler.
+- [x] **Step 4:** `make test && make validate` → PASS. `knaster placement plan --inventory sites/knaster/inventory.yaml` liefert eine Zuordnung ohne Fehler.
-- [ ] **Step 5:** Commit `sites: Inventar und Zielbild an echte Knoten (pve44–pve61) angepasst; ADR-0001/0002/0006 ergänzt`.
+- [x] **Step 5:** Commit `sites: Inventar und Zielbild an echte Knoten (pve44–pve61) angepasst; ADR-0001/0002/0006 ergänzt`.
 
 ---
+  - (20.10.) Nachweis: `make test` auf ops → 161 bestanden, darunter `test_site_knaster_matches_real_nodes`; Site-Dateien und ADR-0001/0002/0006 beschreiben seit Phase 3/4 die echten Knoten.
 
 ## Phase 1 – Knoten-Grundlage (vor dem Cluster)
 
@@ -507,3 +508,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

sites/knaster/proxmox.yaml

@@ -35,9 +35,11 @@ containers:                   # Infrastruktur als LXC (ADR-0001), HA + ZFS-Repli
   infra: {node: pve44, vmid: 101, cores: 4, memory_mb: 4096, disk_gb: 60, storage: tank, ip: 192.168.100.188/24, ha: true, replicate_to: [pve52, pve48]}
 
 # Dienst-VMs ohne GPU (D6): k3s-Steuerung, geklont vom Template des Knotens, auf tank mit HA.
-# Adresse per DHCP wie die GPU-VMs (D5); die Agents finden den Server über /etc/hosts (Rolle k3s-agent).
+# Feste Adresse (20.10.): nach einem Netzausfall bekam die VM per DHCP .131 statt .124, die Agents (/etc/hosts),
+# nex-admin (NEX_ADMIN_K8S_URL, NEX_K3S_HOST) und die kubeconfig auf ops zeigten ins Leere – alle Knoten NotReady.
+# DHCP-Reservierung am DC (.124, MAC bc:24:11:a5:d5:52) bleibt zusätzlich offen (Plan Task 0.2).
 service_vms:
-  k3s: {node: pve48, vmid: 110, cores: 2, memory_mb: 3072, disk_gb: 20, storage: tank, ip: dhcp, pool: infra, ha: true, replicate_to: [pve52, pve44]}
+  k3s: {node: pve48, vmid: 110, cores: 2, memory_mb: 3072, disk_gb: 20, storage: tank, ip: 192.168.100.124/24, pool: infra, ha: true, replicate_to: [pve52, pve44]}
 
 replication_schedule: "*/15"