rorapp/cluster-knaster
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Plan 6.6: Namespace nex mit Pod Security, Sprachdienste nach nex-speech
ci / test (push) Failing after 25s
Details

Browse Source 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Robert Rapp
2026-10-19 18:00:57 +02:00
co-authored by Claude Opus 5.5
parent f9036934c3
commit 039f57a435
1 changed files with 5 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md
+5
View File
@@ -400,6 +400,11 @@ Ersetzt PLAN §8 „1 Data Plane“.
- [x] (19.10.) Alerts `K3sNodeNotReady`, `K3sPodCrashLooping` (> 10 min), `K3sDeploymentUnavailable` (> 15 min), `K3sContainerMemoryNearLimit` (> 90 %, 10 min); Healer-Regeln nur `notify`. - [x] (19.10.) Alerts `K3sNodeNotReady`, `K3sPodCrashLooping` (> 10 min), `K3sDeploymentUnavailable` (> 15 min), `K3sContainerMemoryNearLimit` (> 90 %, 10 min); Healer-Regeln nur `notify`.
- 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. - 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.
- [x] (19.10.) Prüfung bestanden: alle 11 k3s-Ziele `up`; Speicher je Pod in `nex` gleich `kubectl top` (344/354/122 MiB); ~2000 neue Reihen; Dashboard im Ordner `knaster`. Test-Deployment `knaster-crashtest` (busybox, `exit 1`): `K3sDeploymentUnavailable` feuert nach 15 min; `K3sPodCrashLooping` flackerte zwischen den Neustarts und blieb pending, seit `max_over_time(…[5m])` feuert er nach ~14 min. Test-Deployment gelöscht. - [x] (19.10.) Prüfung bestanden: alle 11 k3s-Ziele `up`; Speicher je Pod in `nex` gleich `kubectl top` (344/354/122 MiB); ~2000 neue Reihen; Dashboard im Ordner `knaster`. Test-Deployment `knaster-crashtest` (busybox, `exit 1`): `K3sDeploymentUnavailable` feuert nach 15 min; `K3sPodCrashLooping` flackerte zwischen den Neustarts und blieb pending, seit `max_over_time(…[5m])` feuert er nach ~14 min. Test-Deployment gelöscht.
- [ ] **6.6 Namespace nex absichern (Pod Security)** · vom Nutzer am 19.10. gewünscht · **Files:** `deploy/k8s/nex-speech/` (Namespace `nex-speech`), `deploy/k8s/nex/` (Label), `playbooks/nex-speech-k3s.yml`, Rolle `nex-speech-k3s`, BETRIEB §14
Anlass: nex-admin darf in `nex` Pods anlegen, und ohne Pod-Security-Regel auch mit `privileged`, `hostPath`, `hostNetwork`; ein abgeflossenes Token hieße damit Root auf einer GPU-VM. „baseline“ für `nex` geht erst, wenn die Sprachdienste (Host-Netz, hostPath) dort nicht mehr laufen.
- [ ] `nex-stt` und `nex-tts` in einen eigenen Namespace `nex-speech` umziehen (gleiche Host-Ports 8178/8179 auf gpu-pve52, kurze Unterbrechung, vorher mit dem NEX-Team abstimmen).
- [ ] Namespace `nex`: `pod-security.kubernetes.io/enforce: baseline` (zuerst `warn`/`audit` und prüfen, ob nex-admin-Agenten und SearXNG passen).
- [ ] Prüfung: Als nex-admin wird ein Pod mit `hostPath` oder `privileged` in `nex` abgelehnt; Agenten, SearXNG und die Sprachdienste laufen; Rundlauf TTS→STT von appsrv08.
--- ---