Brücke nex-know: Host-Port 14200 auf appsrv08

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

docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md

@@ -78,7 +78,7 @@ Außerhalb des Clusters:
 
 ## Was hängt woran (Stand 12.10.)
 
-Die Speicherfreigabe (D1) liegt seit 12.10. vor, `tank` steht auf pve44, pve48 und pve52; die rechte Spalte ist damit freigeschaltet. D2 ist entschieden (12.10.). D5 ist zurückgestellt: Gäste starten mit DHCP; feste IPs müssen vor Phase 6 stehen, weil STT und die LiteLLM-Slots IP-Literale nutzen.
+Die Speicherfreigabe (D1) liegt seit 12.10. vor, `tank` steht auf pve44, pve48 und pve52; die rechte Spalte ist damit freigeschaltet. D2 ist entschieden (12.10.). D5 ist zurückgestellt: Gäste starten mit DHCP; feste IPs müssen vor Phase 6 stehen, weil STT und die LiteLLM-Slots IP-Literale nutzen. 19.10.: Reservierungen für pve44, pve52, gpu-pve52 und den Laptop bestätigt, Rest siehe Task 0.2.
 
 | Sofort möglich | Braucht D2 (entschieden) | Braucht die Speicherfreigabe |
 |---|---|---|
@@ -131,8 +131,11 @@ Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeins
 
 - [x] (14.10.) ops und infra auf feste Adressen .173/.188 umgestellt (BETRIEB §10), damit hängt der Steuerrechner nicht mehr am Lease. Laptop kam am 14.10. per Dock mit .181, als zweite Adresse in `firewall.management` aufgenommen.
 - [ ] Reservierungen beim DC-Support anfordern (15.10. angefragt; MAC-Liste vom 14.10.: Knoten, ops bc:24:11:c1:d9:c8, infra bc:24:11:6d:e5:c0, gpu-pve52 bc:24:11:92:4b:eb, **nachreichen: k3s-VM bc:24:11:a5:d5:52 → .124**, Laptop WLAN 34:fd:70:65:06:6c und Dock 84:ba:59:fb:e0:36) plus Ausschluss `.220–.239`. Nötig ist dafür nur die Gruppe „DHCP-Administratoren“ auf dem DC .120, kein Domänen-Admin.
+  - [x] (19.10., Bestätigung an den Nutzer) Feste Adressen per Reservierung: pve44 (.210), pve52 (.207), gpu-pve52 (.174, `node.json` auf infra) und der Laptop über WLAN (.151, gemessen) und LAN im Dock (.181 erwartet, beim nächsten Andocken mit `ipconfig` prüfen). Damit ist die Laptop-Sperre aus BETRIEB §10 behoben.
+  - [ ] Laut DC derzeit **nicht konfigurierbar**: infra (.188), pve46 (.209), pve48 (.212). Alle drei sind im Gast bzw. in `/etc/network/interfaces` statisch eingestellt (19.10. geprüft), hängen also an keinem Lease. Restrisiko: Der DHCP-Server vergibt die Adresse an ein anderes Gerät, dann gibt es einen Konflikt. Ob das droht, zeigt erst „DHCP-Bereich auslesen“ (liegen die Adressen im Bereich?). Liegen sie darin, als Alternative einen Ausschluss der Einzeladressen erfragen.
+  - [ ] Ohne Rückmeldung: ops (.173, statisch), k3s-VM (.124), gpu-pve44/46/48, pve61 (.214), Ausschluss `.220–.239`.
 - [ ] Später (Phase 9): eigenes Verwaltungs-/Dienstnetz als VLAN, Vorbedingung: Switch kann VLAN, Routing beim Netzverantwortlichen geklärt. Bis dahin bleibt die Adressliste in der Proxmox-Firewall der Schutz.
-- [ ] DHCP-Bereich auslesen. **Seit 13.10. dringender:** Die Firewall (4.4) lässt nur .151 (Laptop), .173 (ops) und .188 (infra) an die Verwaltungsports; ein Lease-Wechsel sperrt die Quelle aus (BETRIEB §10). Für .207, .209, .210, .212 und .214 Reservierungen auf die MACs der Knoten anlegen (MACs stehen im Healthcheck). Ebenso eine Reservierung für den Admin-Laptop (heute .151 per WLAN). Die Firewall in 4.4 lässt nur diese Adresse zu, ein Lease-Wechsel würde sonst aussperren.
+- [ ] DHCP-Bereich auslesen. **Seit 13.10. dringender:** Die Firewall (4.4) lässt nur .151 (Laptop), .173 (ops) und .188 (infra) an die Verwaltungsports; ein Lease-Wechsel sperrt die Quelle aus (BETRIEB §10). Für .207, .209, .210, .212 und .214 Reservierungen auf die MACs der Knoten anlegen (MACs stehen im Healthcheck). Ebenso eine Reservierung für den Admin-Laptop (heute .151 per WLAN). Die Firewall in 4.4 lässt nur diese Adresse zu, ein Lease-Wechsel würde sonst aussperren. 19.10.: Laptop, pve44 und pve52 reserviert; der Bereich selbst ist noch nicht ausgelesen und entscheidet über das Restrisiko für infra, pve46, pve48.
 - [ ] Gäste-Block festlegen (Vorschlag `.220–.239`) und als Ausschluss im DHCP eintragen.
   Prüfung: `ping` auf jede Adresse des Blocks → keine Antwort. DHCP-Ausschluss sichtbar.
 
@@ -143,7 +146,7 @@ Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeins
 - [x] D1 entschieden (12.10.): **Variante B**, keine Neuinstallation. Alle alten Windows-Platten werden für den Cluster vollständig gelöscht.
 - [x] D1-Freigabe zum Löschen (12.10., „festplatten alle platt machen“): pve44 sdb NTFS, pve52 sdb BitLocker „GODEL55“, pve48 sdb und sdc. Alle vier gelöscht (Task 1.2).
 - [x] D2 entschieden (12.10.): eine GPU-VM pro Knoten. Vorteil, der schon heute greift: Das anstehende Kernel-Update 7.0.2 → 7.0.14 berührt keinen NVIDIA-Treiber.
-- [ ] D5 zurückgestellt (12.10., „Schritt zwei“): Gäste vorerst per DHCP. Für feste IPs braucht es keinen DNS-Eintrag, sondern einen Ausschluss bzw. Reservierungen im DHCP-Server. Den verwaltet nicht der Nutzer. Dabei auch die Knoten-IPs .207–.214 reservieren lassen (Corosync bindet an sie).
+- [ ] D5 zurückgestellt (12.10., „Schritt zwei“): Gäste vorerst per DHCP. Für feste IPs braucht es keinen DNS-Eintrag, sondern einen Ausschluss bzw. Reservierungen im DHCP-Server. Den verwaltet nicht der Nutzer. Dabei auch die Knoten-IPs .207–.214 reservieren lassen (Corosync bindet an sie). Stand 19.10. in Task 0.2.
 - [ ] D3 und D4 bestätigen. Ergebnis als Abschnitt „Entscheidungen 2026-10“ in `docs/PLAN.md` §9 eintragen.
 
 ### Task 0.4: Site-Dateien, Ansible-Inventar und ADRs an die echte Hardware anpassen
@@ -283,7 +286,7 @@ Ersetzt GPU-Knoten 3 (Teil Cluster). Mit 5 Stimmen ist **kein QDevice** nötig.
 - [x] (12.10.) `tofu plan` und dann `tofu apply` für `gpu-pve44`, `gpu-pve46`, `gpu-pve48` und `gpu-pve52`: alle Karten des Knotens, 12 GB RAM, 4 Kerne, Systemplatte 40 GB und Modellplatte 60 GB auf `local-lvm` (Variante B) bzw. `local-zfs` (Variante A), IPs aus D5.
 - [x] `ansible-playbook … --limit gpu_vms` (Rollen `docker-host` und `gpu-node`, `driver_generation: legacy` = R580 → `580.178.04`, DKMS), 12.10.
   Ergebnis 12.10., auch nach Neustart aller VMs: `gpu-pve44/46/48` sehen M4000 + P2000, `gpu-pve52` die M4000, `docker run --gpus all …` sieht alle Karten, Modellplatte 60 GB unter `/srv/models`.
-  **Befund DHCP:** Nach dem ersten Neustart hatten zwei VMs ihre Adressen getauscht (DUID als Client-ID); die strenge Hostschlüssel-Prüfung hat gestoppt. Jetzt `dhcp-identifier: mac` (netplan), Zugang nach jedem Neustart mit `scripts/refresh-vm-access.sh` auffrischen. Dauerhaft löst das nur D5 (Reservierungen auf die MACs: gpu-pve44 `bc:24:11:6a:67:15`, gpu-pve46 `bc:24:11:75:ad:33`, gpu-pve48 `bc:24:11:f5:da:73`, gpu-pve52 `bc:24:11:92:4b:eb`).
+  **Befund DHCP:** Nach dem ersten Neustart hatten zwei VMs ihre Adressen getauscht (DUID als Client-ID); die strenge Hostschlüssel-Prüfung hat gestoppt. Jetzt `dhcp-identifier: mac` (netplan), Zugang nach jedem Neustart mit `scripts/refresh-vm-access.sh` auffrischen. Dauerhaft löst das nur D5 (Reservierungen auf die MACs: gpu-pve44 `bc:24:11:6a:67:15`, gpu-pve46 `bc:24:11:75:ad:33`, gpu-pve48 `bc:24:11:f5:da:73`, gpu-pve52 `bc:24:11:92:4b:eb`). 19.10.: gpu-pve52 reserviert (.174), die übrigen drei offen.
   Prüfung in jeder VM: `nvidia-smi -L` → beide Karten. `docker run --rm --gpus all nvidia/cuda:12.6.3-base-ubuntu24.04 nvidia-smi` → beide Karten.
 
 ### Task 3.3: Benchmark-Tag (fasst drei Pläne zusammen)
@@ -361,12 +364,13 @@ Ersetzt PLAN §8 „1 Data Plane“.
   - [x] (15.10.) Zuteilung angehoben, weil der Cluster nur die Hälfte der Hosts zeigte: GPU-VMs 4→8 vCPU, 12→20 GB; infra 8→4 GB; ZFS-ARC 4→2 GB (neu in Rolle pve-host, `cluster.zfs_arc_max_mb`); tofu `reboot_after_update=false`, VMs einzeln per `qm reboot` (je ~30 s bis Ready). k3s: 34 vCPU, 83 GB. Nutzer-Idee pve61 als Cache: geht nicht, ARC ist Host-lokal; pve61 (8 GB, kein tank) bleibt Quorum/Kiosk, könnte später CPU-Agent werden.
   - [x] (15.10.) Umzug 3: RustDesk-Server (Stack `rustdesk` auf appsrv08) als Deployment + Service LoadBalancer in k3s (`playbooks/rustdesk-k3s.yml`), gleiches Schlüsselpaar, Ports auf allen Knoten erreichbar. Clients zeigen weiter auf .29; Umstellung erst mit fester Adresse/DNS-Name (Nutzer), dann Installer-Name im Stack `rustdesk-updater` und Stack `rustdesk` auf appsrv08 abschalten.
   - [x] (15.10.) Umzugstest 2 aus Portainer-Umgebung appsrv08: SearXNG (`nex-searxng`) als Deployment + NodePort 30880 in k3s, Suche liefert Treffer. Cutover: Nutzer hat 15.10. Weg 2 gewählt (SEARXNG_URL im nex-Admin als Stack-Variable konfigurierbar machen, nex-Repo), Rollout nach DHCP-Reservierung der k3s-VM.
-  - [ ] Offen: Umgebung in Portainer (appsrv08) anlegen (Nutzer, 15.10. laut Nutzer erledigt), DHCP-Reservierung für VM 110 (`bc:24:11:a5:d5:52`), llama.cpp (6.1) direkt als k3s-Manifeste statt Compose, Monitoring der Pods (kube-state-metrics / Prometheus-Scrape über k3s), Exporter-Stacks umziehen, Docker danach aus den VMs entfernen.
+  - [ ] Offen: Umgebung in Portainer (appsrv08) anlegen (Nutzer, 15.10. laut Nutzer erledigt), DHCP-Reservierung für VM 110 (`bc:24:11:a5:d5:52`), llama.cpp (6.1) direkt als k3s-Manifeste statt Compose, Monitoring der Pods (Task 6.5), Exporter-Stacks umziehen, Docker danach aus den VMs entfernen.
 - [ ] **6.1 GPU-Rollen:** ab 15.10. als k3s-Manifeste (D6) statt Compose: `deploy/compose/gpu-llamacpp` in den GPU-VMs nach der Zuordnung aus Task 3.3, also Embedding und Rerank redundant auf zwei Knoten, Chat für verifier und signature. Prüfung: Canary-Checks grün (`knaster` Canary-Prober).
 - [ ] **6.2 STT und TTS für NEX** – Auftrag vom 12.10. mit Abgleich: `docs/auftraege/2026-10-12-sprachmodelle-nex.md` (Erkennung whisper.cpp auf einer M4000, naheliegend `gpu-pve52`; Ausgabe Piper auf CPU, Port 8179; Abnahme und Rückmeldeformat dort). Läuft nach Task 3.2, gern als Subagent. **Blockiert für die Abnahme:** feste IP (D5). Bisheriger Text (nex-STT-Plan Tasks 2–4): `whisper-server` als zusätzlicher Dienst in der GPU-VM des in Task 3.3 gewählten Knotens. Neuer Slot `stt-de` im Katalog. Port 8178 nur von `192.168.100.29` (Firewall der VM bzw. des Gasts). Prüfung: Von appsrv08 liefert `curl -F file=@probe.wav http://<IP>:8178/v1/audio/transcriptions` deutschen Text, von einem anderen Rechner wird der Zugriff abgelehnt.
   - [x] (12.10.) Umgesetzt in `gpu-pve52`: `nex-stt` (whisper.cpp v1.9.4, CUDA 12.6, sm_52/61, `large-v3-turbo`, Port 8178) und `nex-tts` (Piper 1.8.0, `de_DE-thorsten-high` + `de_DE-kerstin-low`, Port 8179) als `deploy/compose/nex-speech`, Rolle/Playbook `nex-speech`. ufw in der VM (8178/8179 nur von `.29`, SSH aus dem LAN), Proxmox-Firewall bewusst aus.
   - [x] (12.10.) Tests in der VM und von ops (temporäre Regel, danach entfernt): 10 s → 2,94 s, 60 s → 8,63 s (Median), TTS-TTFB 0,64–0,91 s (mp3/pcm/opus), Autostart nach `qm reboot 252` geprüft, keine Texte in Logs. Rückmeldung im Auftrag.
-  - [ ] Offen: feste IP (D5, heute DHCP `192.168.100.174`), Abnahme von appsrv08 durch das NEX-Team, Slot `stt-de` (Core kennt kein `kind: stt`), `tts-de` später nach `infra`.
+  - [x] (19.10.) Feste IP: `192.168.100.174` per DHCP-Reservierung bestätigt (D5, Task 0.2).
+  - [ ] Offen: Abnahme von appsrv08 durch das NEX-Team, Slot `stt-de` (Core kennt kein `kind: stt`), `tts-de` später nach `infra`.
 - [ ] **6.3 Lokale Slots in LiteLLM (D4):** `embed-default`, `rerank-default`, `verifier-small` und `signature-extractor` als Modelle im LiteLLM auf appsrv08 eintragen (IP-Literale). Prüfung: `curl http://192.168.100.29:<port>/v1/models` listet die Slots, ein Aufruf je Slot antwortet.
 - [ ] **6.4 Ada-Worker (D3)** · **Planner:** „LLM-Worker: direkte Inferenz-Schnittstelle für LiteLLM (zusätzlich zum Job-Poll), Tunnel, Registry, Fallback-Kette“
   - Offene Schritte der Worker-Registry v2 im Repo `mygodel/nex` abschließen.
@@ -377,6 +381,16 @@ Ersetzt PLAN §8 „1 Data Plane“.
     - `test_worker_registry_slot_falls_back_to_tier0_when_list_empty`
     - `test_worker_registry_slot_falls_back_when_list_unreachable`
   - Prüfung: `make test` PASS. Live tagsüber geht eine tier1-Anfrage an tier0, nachts an GODE-PC-05.
+- [ ] **6.5 Pod-Monitoring (k3s in Grafana)** · **Planner:** „Proxmox: Grafana-Dashboard für den Cluster“ · **Files:** Create `deploy/k8s/kube-state-metrics/`, `platform/proxmox/ansible/playbooks/kube-state-metrics-k3s.yml`, `deploy/grafana/dashboards/k3s-pods.json`; Modify `deploy/prometheus/prometheus.yml`, `platform/proxmox/scripts/monitoring-targets.py`, Rolle `infra-stack` (Token), `core/tests/test_artifacts.py`, BETRIEB §7/§14
+  Ausgangslage 19.10.: Grafana 12.4 und Prometheus laufen auf infra mit Dashboards für Proxmox, Knoten, GPU und knaster; für k3s gibt es kein Ziel. Zustand und Speicher der Pods zeigt bisher nur nex-admin über die Metrics-API (metrics-server, nur Momentwerte, keine Grafana-Datenquelle).
+  - [ ] kube-state-metrics als Deployment im Namespace `kube-system` (Image gepinnt), Service als NodePort. Liefert Zustand: Bereitschaft, Neustarts, Requests/Limits, Deployments.
+  - [ ] ServiceAccount `prometheus-infra` mit ClusterRole nur zum Lesen (`nodes`, `nodes/metrics`, `nodes/proxy`), langlebiges Token als Secret. Das Token liegt wie beim pve-exporter nur im LXC unter `/opt/knaster/infra/secrets/k3s-prometheus.token`, kopiert von der Rolle `infra-stack`; die k3s-CA dazu (`/var/lib/rancher/k3s/server/tls/server-ca.crt`), damit kein `insecure_skip_verify` nötig ist. Kubelet-Zertifikate der Agents gegen diese CA prüfen, sonst bewusst entscheiden.
+  - [ ] Ziele per file_sd statt fester Adressen, weil die k3s-VM (.124) und gpu-pve44/46/48 noch keine Reservierung haben: `monitoring-targets.py` schreibt zusätzlich `kubelet.json` (alle fünf k3s-Knoten, Port 10250, Pfade `/metrics/cadvisor` und `/metrics`) und `kube-state-metrics.json` (NodePort auf jedem Knoten, Prometheus nimmt den ersten erreichbaren bzw. dedupliziert per `instance`).
+  - [ ] Prometheus-Jobs `kubelet`, `cadvisor`, `kube-state-metrics` in `deploy/prometheus/prometheus.yml`. infra hat nur 4 GB: für cAdvisor `metric_relabel_configs`, die nur `container_cpu_usage_seconds_total`, `container_memory_working_set_bytes`, `container_memory_rss` und Netzwerk behalten und `container=""`/Pause-Container verwerfen. Danach Speicher von Prometheus eine Woche beobachten.
+  - [ ] ufw in den GPU-VMs (gpu-pve52 lässt heute nur 8178/8179 von .29 zu): 10250 und den NodePort nur von `.188` freigeben (Rolle `k3s-agent` bzw. `gpu-exporters`).
+  - [ ] Dashboard „k3s – Pods“ (Grundlage Community-Dashboard, z. B. grafana.com 15661/15760, angepasst auf die vorhandenen Metriken) mit Namespace-Auswahl, Vorgabe `nex`: Pods je Knoten, Neustarts, CPU/Speicher gegen Requests/Limits. In die Kiosk-Playlist (5.3) aufnehmen.
+  - [ ] Alerts in `deploy/prometheus/alerts.yml`: Pod in CrashLoopBackOff > 10 min, Deployment nicht verfügbar, Speicher > 90 % des Limits. Nur melden, kein Healer-Eingriff (der heilt nur VMs).
+  - Prüfung: `make test` PASS (Struktur von prometheus.yml/alerts.yml). Auf infra zeigt `api/v1/targets` die Jobs `kubelet`, `cadvisor`, `kube-state-metrics` mit allen fünf Knoten `up`. Grafana zeigt für `nex` dieselben Pods und ungefähr denselben Speicher wie `kubectl top pods -n nex`. Ein absichtlich kaputtes Test-Deployment löst den CrashLoop-Alert aus.
 
 ---