Files
cluster-knaster/known-issues.md

5.9 KiB
Raw Permalink Blame History

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.
  • test_ontology.py::test_cli_check_with_snapshot scheitert unter Windows (liest ohne UTF-8, cp1252). Mit PYTHONUTF8=1 grün; unter Linux grün.
  • main und plan/aufbau-2026-10-12 laufen auseinander, wenn auf main direkt gearbeitet wird (13.10. passiert, 19.10. zusammengeführt). Gitea zeigt main, ops arbeitet mit dem Plan-Branch. Nur auf dem Plan-Branch arbeiten oder sofort zusammenführen.
  • 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.