cluster-knaster/known-issues.md

Bekannte Probleme und Fallen

Stand 19.10.2026. Je Eintrag: was passiert, Auswirkung, Umgang, wo es weitergeht. Behobene Einträge nicht löschen, sondern unter „Erledigt“ verschieben (mit Datum), damit die Lehre erhalten bleibt. Siehe auch AGENTS.md, project-map.md.

Offen

Netz und Zugang

• DHCP-Reservierungen unvollständig. Reserviert sind pve44, pve52, gpu-pve52 und der Laptop. Für infra, pve46 und pve48 geht laut DC keine Reservierung (alle drei sind statisch konfiguriert, Risiko: doppelt vergebene Adresse). Ohne Rückmeldung: ops, k3s-VM (.124), gpu-pve44/46/48, pve61, Gäste-Block .220–.239 (am 19.10. erneut angefragt). Auswirkung: Ändert sich die Adresse der k3s-VM, brechen Portainer CE (nginx-Ziel), NEX_K3S_HOST und die geplante RustDesk-Umstellung. Ändern sich GPU-VM-Adressen: refresh-vm-access.sh, dann playbooks/monitoring-targets.yml. → Aufbauplan Task 0.2.
• Firewall sperrt bei Adresswechsel aus. Die Proxmox-Firewall lässt nur Adressen aus firewall.management an 22/8006. Rückweg über ops oder Konsole (BETRIEB §10).
• Namespace nex ohne Pod Security. nex-admin darf dort Pods mit privileged/hostPath/hostNetwork anlegen; ein abgeflossenes Token wäre damit Root auf einer GPU-VM. → Task 6.6 (Sprachdienste nach nex-speech, dann „baseline“).

Monitoring und Healer

• SlotEndpointDown feuert seit 15.10. für tier1-flex, tier1-general (Ada-Rechner noch nicht angebunden, 6.4), tts-de, tts-de-hq, embed-default, verifier-small, signature-extractor (Canaries laufen über LiteLLM, das kommt mit 6.3). Erwartet, kein Handlungsbedarf bis 6.3/6.4.
• vLLM-Ziele gpu-main/gpu-flex down (DNS-Namen ohne Auflösung, Ada-Rechner nicht angebunden). → Task 6.4.
• Healer kennt nur Docker-Container. Registry und Healer-Regeln führen docker_host/container; llama.cpp und die Sprachdienste laufen inzwischen in k3s. restart_container würde ins Leere greifen. Heute folgenlos (Dry-Run, enabled_actions: []); vor dem Scharfschalten auf Pod-Neustart umstellen. → Task 6.1 (offen), Phase 9.
• n8n-Receiver im Alertmanager nur vorbereitet (auskommentiert, Format passt nicht). Alerts gehen nur an den Router. → Task 5.2.
• Prometheus-Neustart setzt Alert-Zustände zurück (alles wieder „pending“). Nach einem Neustart des Stacks die for:-Dauer abwarten, bevor man auf fehlende Alerts schließt.
• Speicher von Prometheus auf infra beobachten (4 GB RAM, seit 19.10. ~2000 Reihen mehr durch k3s). → Task 6.5.
• K3sPodCrashLooping bleibt bis zu 5 min länger stehen, nachdem ein Pod behoben oder gelöscht wurde (max_over_time[5m], nötig gegen Flackern).

GPU und Modelle

• Embedding auf der P2000 nur mit -ub 4096. Mit 8192 braucht llama.cpp (Stand b6000) allein 5 GB Rechenpuffer (ub × Vokabular), Flash-Attention hilft nicht. Belegung mit Rerank: 4,4–4,6 von 5 GB, wenig Reserve.
• nvidia.com/gpu vergibt nur die M4000 (Device Plugin sieht nur Index 0). Wer einen GPU-Pod anlegt, bekommt eine M4000; die P2000 gehört llama.cpp. Annahme: Index 0 ist in jeder GPU-VM die M4000 – das Playbook gpu-llamacpp-k3s.yml prüft das vor jeder Änderung.
• LiteLLM-Port auf appsrv08 nicht im LAN veröffentlicht. Blockiert Task 6.3 (lokale Slots in LiteLLM) und damit grüne Canaries. → Nutzer, Task 6.3.

Knoten und Speicher

• ZFS-Seiten-Cache nach HA-Umzug. Nach zfs receive liefert ein Knoten für früher gemappte Dateien veralteten Inhalt; Docker brach am 12.10. mit invalid freelist page ab. Abgefangen im LXC infra durch knaster-drop-stale-cache.service; jeder neue replizierte LXC mit mmap-Nutzern braucht denselben Schutz (BETRIEB §7).
• pve44: EFI-Partition nicht eingehängt (sda2 fehlt in /etc/fstab); GRUB-Updates erreichen sie nicht. → Aufbauplan Task 1.1, Nebenbefund.
• pve61: Neustart nach dem Kernel-Update offen. → Aufbauplan Task 1.1, Step 4.
• Kein Backup. Proxmox Backup Server und Ziel-Speicher stehen aus. → Task 5.1 (Entscheidung Nutzer).

Übergänge (alt und neu laufen parallel)

• Portainer: EE auf appsrv08 läuft weiter, portainer.mygodel.de zeigt noch dorthin; CE im Cluster ist bereit. Umstellung braucht Admin-Login und feste Adresse der k3s-VM (BETRIEB §14).
• RustDesk: Server läuft zusätzlich in k3s, Clients zeigen weiter auf .29.
• SearXNG: läuft in k3s und auf appsrv08; Umstellung der Agenten über SEARXNG_URL im nex-Admin.

Arbeitsumgebung

• Windows-Arbeitskopie mit CRLF: yamllint meldet „wrong new line character“ für geänderte Dateien. Den Stand aus Git prüfen (git show HEAD:<datei> | yamllint -), siehe AGENTS.md.
• test_tts_server scheitert unter Windows (kein Piper-Programm). Unter Linux grün.
• Kein Python-venv auf ops: make test/make lint laufen auf dem Laptop; auf ops nur Ansible-Syntaxprüfung.
• Ansible-Ad-hoc mit Go-Templates (docker ps --format '{{.Names}}') scheitert, weil Ansible {{ }} auswertet. Skript per -m script verwenden.
• Mehrere Agenten-Sitzungen im selben Repo: Eine Sitzung kann fremde, noch nicht committete Änderungen mit committen. Nur eigene Dateien stagen, vor dem Push git pull --rebase.

Erledigt

• 19.10.: Embedding/Rerank auf gpu-pve44/46 liefen nicht (Prometheus-Ziele 8081/8082 down) – seit Task 6.1 in k3s.
• 19.10.: Laptop wurde bei Lease-Wechsel von der Firewall ausgesperrt (14.10. passiert) – WLAN und Dock reserviert.