Troubleshooting
Diese Seite fasst häufige Probleme mit centron Kubernetes zusammen und zeigt, wie Sie die Ursache eingrenzen – von der Verbindung zum Cluster über nicht startende Pods bis zu Netzwerk, Storage und fehlerhaften Nodes. Für Fragen zu Funktionsumfang und Abrechnung siehe FAQ.
Voraussetzungen
- Ein Kubernetes Cluster im Status Running und eine geprüfte Verbindung per
kubectl
Allgemeines Vorgehen
Die meisten Ursachen lassen sich mit drei Befehlen eingrenzen:
# Zustand der Ressource und deren Events
kubectl describe <ressourcentyp> <name>
# Logs der Anwendung
kubectl logs <pod-name>
# Ereignisse im Cluster, zeitlich sortiert
kubectl get events --sort-by=.metadata.creationTimestamp
Der Abschnitt Events in der Ausgabe von describe benennt in aller Regel die konkrete Ursache.
Verbindung zum Cluster
| Meldung | Ursache und Abhilfe |
|---|---|
The connection to the server ... was refused | Das Cluster wird noch bereitgestellt. Prüfen Sie den Status in der Übersicht Kubernetes. |
error: You must be logged in to the server (Unauthorized) | Die Konfigurationsdatei ist veraltet. Laden Sie sie im Tab Overview über Download Config File erneut herunter. |
Unable to connect to the server: ... i/o timeout | Der Zugriff auf den API-Endpunkt wird blockiert – prüfen Sie Ihre Netzwerk- und Firewall-Konfiguration. |
error: no configuration has been provided | KUBECONFIG ist nicht gesetzt oder verweist auf einen falschen Pfad. |
Siehe Mit dem Cluster verbinden.
Pods starten nicht
Verschaffen Sie sich zunächst einen Überblick:
kubectl get pods --all-namespaces
Pending
Der Pod kann keinem Node zugewiesen werden.
kubectl describe pod <pod-name>
| Hinweis in den Events | Ursache |
|---|---|
Insufficient cpu / Insufficient memory | Die Nodes haben keine freie Kapazität. Node Pool vergrößern oder Autoscaling aktivieren. |
node(s) didn't match Pod's node affinity | nodeSelector oder Affinity-Regeln passen zu keinem Node. Prüfen Sie kubectl get nodes --show-labels. |
pod has unbound immediate PersistentVolumeClaims | Der PVC wurde noch nicht gebunden, siehe unten. |
Der Scheduler entscheidet anhand der angeforderten requests, nicht anhand der tatsächlichen Auslastung. Zu hoch angesetzte requests blockieren Kapazität, die real nicht genutzt wird.
ImagePullBackOff / ErrImagePull
Das Container-Image kann nicht geladen werden. Häufige Ursachen:
- Falscher Image-Name oder nicht existierender Tag
- Private Registry ohne hinterlegte Zugangsdaten
- Das Secret liegt in einem anderen Namespace als der Pod
Siehe Container Registry anbinden.
CrashLoopBackOff
Der Container startet, beendet sich aber wiederholt. Die Ursache liegt fast immer in der Anwendung:
# Logs des aktuellen Versuchs
kubectl logs <pod-name>
# Logs der vorherigen, abgestürzten Instanz
kubectl logs <pod-name> --previous
Typische Ursachen sind fehlende Umgebungsvariablen, nicht erreichbare Abhängigkeiten oder fehlerhafte Konfiguration.
OOMKilled
Der Container hat sein Speicherlimit überschritten und wurde beendet. Erhöhen Sie resources.limits.memory oder senken Sie den Speicherbedarf der Anwendung.
kubectl describe pod <pod-name> | grep -A5 "Last State"
Anwendung nicht erreichbar
EXTERNAL-IP bleibt <pending>
Services vom Typ LoadBalancer erhalten in diesem Cluster keine externe Adresse – es ist kein Cloud Controller Manager eingerichtet. Der Zustand <pending> bleibt dauerhaft bestehen.
Verwenden Sie stattdessen NodePort, siehe Erstes Image deployen.
Verbindung wird abgewiesen
Prüfen Sie, ob der Service überhaupt Pods erfasst:
kubectl get endpoints <service-name>
Sind keine Adressen aufgeführt, stimmen die Labels im selector des Service nicht mit den Labels der Pods überein – die häufigste Ursache überhaupt.
503 über den Ingress
Der referenzierte Service oder dessen Pods sind nicht bereit. Prüfen Sie die Readiness Probes und kubectl get endpoints.
Siehe Ingress Controller installieren.
Storage
PVC bleibt auf Pending
Persistente Volumes (CSI/PVC) sind verfügbar. Bleibt ein PVC dennoch auf Pending, prüfen Sie zunächst, welche Storage-Klassen im Cluster bereitstehen:
kubectl get storageclass
Prüfen Sie anschließend, ob der PVC eine vorhandene storageClassName anfordert und ob die angeforderte Größe innerhalb der Grenzen liegt. Details zu den Ereignissen liefert kubectl describe pvc <name>. Siehe Storage Features.
Nodes
Node im Status NotReady
kubectl describe node <node-name>
Der Abschnitt Conditions zeigt Hinweise wie MemoryPressure oder DiskPressure. Bleibt der Node dauerhaft fehlerhaft, setzen Sie ihn über Recycle neu auf, siehe Node Remediation.
Anhaltend hohe Auslastung
Prüfen Sie den Tab Analytics sowie:
kubectl top nodes
kubectl top pods --all-namespaces --sort-by=cpu
Siehe Metriken ansehen und Plan auswählen.
Support kontaktieren
Lässt sich ein Problem nicht eingrenzen, halten Sie folgende Angaben bereit:
- Cluster-Name und Region
- Zeitpunkt des Auftretens
- Betroffene Namespaces, Pods oder Nodes
- Ausgabe von
kubectl describeundkubectl logsder betroffenen Ressource
Was der Support abdeckt, beschreibt Scope of Support.