Funktionsprüfung eines Kubernetes-Clusters mit kubectl Statusanalyse und Zustand von Containern prüfen

Anbieter zum Thema

Vertiv GmbH

Data Center Group – Büro Köln

EPS Rechenzentrum Infrastruktur GmbH

Nach der erfolgreichen Einrichtung eines Kubernetes-Clusters mit Kubeadm ist die Überprüfung der Funktionsfähigkeit der nächste logische Schritt. Das wichtigste Werkzeug hierfür ist kubectl, das direkte Anfragen an die API der Control Plane sendet und die Zustände aller Clusterressourcen auswertet.

Ziel der Prüfung ist sicherzustellen, dass alle Komponenten des Clusters korrekt laufen, dass die Netzwerkverbindungen zwischen den Nodes funktionieren und dass Workloads planmäßig ausgeführt werden können. Die Basisprüfung beginnt mit einem Überblick über die aktiven Knoten. Der Befehl

kubectl get nodes -o wide

zeigt, ob die Control Plane und alle Worker-Nodes im Status Ready sind. In der erweiterten Ausgabe erscheinen zusätzlich interne IP-Adressen, Kernelversionen, Kubernetes-Versionen und das verwendete Container-Runtime-Interface. Wenn ein Node als NotReady gekennzeichnet ist, deutet das auf fehlende Netzwerkkonnektivität oder fehlerhafte Pods im System-Namespace hin.

Prüfen der System-Komponenten im Cluster

Anschließend sollten Sie den Zustand der zentralen Systemkomponenten prüfen. Diese befinden sich im Namespace kube-system und lassen sich mit

kubectl get pods -n kube-system

anzeigen. Alle Pods müssen den Status Running oder Completed haben. Kritisch sind hier die Pods kube-apiserver, kube-controller-manager, kube-scheduler, etcd sowie die Netzwerk-Plugin-Pods, etwa von Calico. Um deren Zustand genauer zu untersuchen, kann der Befehl

kubectl describe pod <podname> -n kube-system

verwendet werden. Er liefert detaillierte Informationen über Container-Logs, Events und Ressourcenverbrauch.

Cluster-Netzwerk überprüfen

Ein funktionierendes Netzwerk ist die Grundvoraussetzung für einen stabilen Cluster. Überprüfen Sie die Calico-Komponenten mit

kubectl get pods -n calico-system

und achten Sie auf die Pods calico-node, calico-kube-controllers und calico-typha. Falls ein Pod fehlschlägt, liefern die Logs wichtige Hinweise:

kubectl logs -n calico-system <podname>

Damit lässt sich nachvollziehen, ob Verbindungsprobleme zwischen den Nodes, falsche CIDR-Einstellungen oder Policy-Fehler vorliegen. Mit

kubectl get ippools.crd.projectcalico.org -A

kann überprüft werden, ob Calico den richtigen Pod-Adressbereich (z. B. 10.0.0.0/16) verwendet.

Zur Prüfung der Namensauflösung sollte CoreDNS analysiert werden.

kubectl get pods -n kube-system -l k8s-app=kube-dns

zeigt, ob die DNS-Server im Cluster laufen. Anschließend lässt sich mit einem temporären Pod die Namensauflösung testen:

kubectl run dns-test --image=busybox:1.28 -it --rm --restart=Never -- nslookup kubernetes.default

Die erfolgreiche Ausgabe einer Cluster-IP bestätigt die interne DNS-Funktion.

Für den Gesamtzustand aller Ressourcen ist

kubectl get all -A

hilfreich. Damit sehen Sie Deployments, ReplicaSets, DaemonSets und Services in sämtlichen Namespaces. Abweichungen vom erwarteten Status oder wiederholte Restarts weisen auf Konfigurationsfehler hin. Ergänzend zeigt

kubectl top nodes

und

kubectl top pods -A

den aktuellen Ressourcenverbrauch, vorausgesetzt der Metrics Server ist installiert.

Abschließend sollte die Clusterkommunikation praktisch überprüft werden. Erstellen Sie dazu ein einfaches Test-Deployment:

kubectl create deployment web --image=nginx

kubectl expose deployment web --type=NodePort --port=80

kubectl get svc web

Ein Aufruf der ausgegebenen IP und Portnummer im Browser bestätigt, dass Scheduling, Networking und Service-Routing korrekt funktionieren.

Diese Befehle bilden zusammen ein vollständiges Diagnoseraster für Administratoren. Sie prüfen Control Plane, Netzwerk, Speicher, DNS und Ressourcenverbrauch in einem einheitlichen Ablauf. Wenn alle Komponenten in den Zuständen Running, Ready oder Healthy erscheinen und das Testdeployment erreichbar ist, gilt der Cluster als betriebsbereit. Jede Abweichung von diesem Idealzustand sollte durch eine gezielte Analyse mit kubectl describe oder kubectl logs untersucht werden, um Konfigurationsfehler oder Netzwerkprobleme frühzeitig zu erkennen.

(ID:50609034)