Assistent · openDesk
openDesk-Fehlerdiagnose
Wähle, was du beobachtest — der Assistent zeigt, was du in welcher Reihenfolge prüfst, welcher Befehl das zeigt und wie du das Ergebnis liest. Die Ursachen sind Hypothesen: Welche zutrifft, entscheidet erst die Prüfung in deinem Cluster. Ausgeführt wird nichts. Stand der Fakten: openDesk 1.19.1.
Pods bleiben im Status Pending
kubectl zeigt Pods dauerhaft als Pending — sie werden keinem Node zugeteilt.
Prüfe in dieser Reihenfolge
01Welche Pods hängen?
kubectl get pods -n opendesk --field-selector=status.phase=PendingListet nur die Pods, die noch auf einen Node oder ein Volume warten.
- Viele Pods gleichzeitig → eher Cluster-Ressourcen oder Storage als ein einzelnes Chart.
- Nur ein Pod → dessen Events lesen (nächste Prüfung).
02Was sagt der Scheduler?
kubectl describe pod -n opendesk <pod>Der Abschnitt Events am Ende nennt den Grund, warum der Pod nicht starten kann.
- „Insufficient cpu“ oder „Insufficient memory“ → zu wenig freie Ressourcen auf den Nodes.
- „unbound immediate PersistentVolumeClaims“ → weiter im Fall „Speicherprobleme: PVC bleibt Pending“.
- „node(s) had untolerated taint“ → Taints der Nodes passen nicht zum Pod.
03Wie viel ist auf den Nodes noch frei?
kubectl describe nodesZeigt je Node unter „Allocated resources“, wie viel CPU und RAM schon reserviert sind.
- Requests nahe 100 % → Nodes ergänzen oder größer dimensionieren.
- Die offizielle Untergrenze für eine Evaluierung sind 12 Kerne x86/x64 und 32 GB RAM — darunter sind Pending-Pods erwartbar.
Mögliche Ursachen
Hypothesen, keine Diagnose — welche zutrifft, zeigen erst die Prüfungen oben.
- Der Cluster hat weniger CPU oder RAM als die Summe der Requests — die offiziellen Mindestwerte gelten nur für eine Evaluierung.
- Ein PersistentVolumeClaim findet keine passende StorageClass oder kein Volume.
- Nodes mit ARM-Architektur: openDesk unterstützt nur x86/x64.
- Taints oder Node-Selektoren schließen alle Nodes aus.
Häufige Fragen
Verändern die Befehle meinen Cluster?
Nein. Alle Befehle lesen nur: get, describe, logs, helm list, helmfile diff und DNS- bzw. TLS-Abfragen. Ändernde Schritte wie ein erneutes helmfile apply stehen im Guide zur Fehlerbehebung — dort mit Erklärung, was sie bewirken. Der Assistent führt selbst nichts aus.
Warum steht überall -n opendesk?
openDesk wird in einen eigenen Namespace installiert. Im Beispiel heißt er opendesk — ersetze den Namen durch deinen. Platzhalter in spitzen Klammern wie <pod> oder <domain> ersetzt du ebenfalls durch eigene Werte.
Einige Befehle zeigen Passwörter an — ist das gewollt?
Zwei Prüfungen lesen Secrets (Administrator-Passwort) bzw. Release-Werte, die Zugangsdaten enthalten können. Das ist für die Diagnose nötig, die Ausgabe gehört aber nicht in Tickets, Chats oder Screenshots.
Für welche openDesk-Version gilt das?
Die Fakten — Ports, Timeouts, Secret-Namen, Werkzeugversionen — sind gegen openDesk 1.19.1 geprüft. openDesk erscheint monatlich in einer neuen Minor-Version; bei Abweichungen gelten die Release Notes deiner Version.
Passende Tools
openDesk Readiness Check →
Kubernetes-Cluster, Helm, Helmfile, DNS, Ingress, TLS, Storage, Secrets und Backups für openDesk prüfen — mit lesenden Prüfbefehlen und Urteil, das Selbstauskunft und geprüfte Punkte trennt.
openDesk-Deployment-Konfigurator →
openDesk-Konfiguration erzeugen: Umgebung, Domain, Ingress, TLS, Storage, Apps und externe Datenbanken — nur dokumentierte Schlüssel, keine Passwörter, dazu Schritte und DNS-Einträge.