kubectl: Grundlagen und erste Befehle
Autor: Redaktion Domeny.ForSale Veröffentlicht
Kurz erklärt: kubectl ist ein Kommandozeilenwerkzeug zur Bedienung von Kubernetes — einem System, das Anwendungen verwaltet, die in Containern laufen. Damit kannst du den Zustand von Anwendungen prüfen, Änderungen bereitstellen, Logs lesen und Cluster-Ressourcen verwalten. Das Werkzeug ist nicht selbst Kubernetes und richtet auch nicht automatisch eine Umgebung zum Ausführen von Anwendungen ein: Es benötigt Zugriff auf einen bestehenden Cluster.
Wie kubectl mit Kubernetes zusammenarbeitet
Ein Cluster von Kubernetes ist eine Umgebung aus Rechnern, den sogenannten Knoten, und Komponenten, die das Ausführen von Anwendungen verwalten. Ein Container bündelt eine Anwendung mit ihren Abhängigkeiten. Kubernetes führt Container in Einheiten aus, die Pods heißen; ein Pod kann einen oder mehrere zusammenarbeitende Container enthalten.
kubectl läuft auf dem Rechner eines Administrators oder Entwicklers oder in einem System zur Automatisierung von Deployments. Es sendet Anfragen an den API-Server von Kubernetes, die Schnittstelle zum Lesen und Ändern von Cluster-Ressourcen. Es steuert nicht jeden Container direkt — die Komponenten von Kubernetes führen die Aktionen aus, die zum Erreichen des vorgegebenen Zustands nötig sind.
Wenn du beispielsweise vorgibst, dass drei Kopien einer Anwendung laufen sollen, übermittelt kubectl diese Konfiguration an die API. Kubernetes versucht anschließend, die gewünschte Anzahl an Kopien am Laufen zu halten. Du kannst das Terminal schließen: Der Betrieb der Anwendung hängt nicht davon ab, dass der Prozess von kubectl weiterläuft.
Was du für den Einstieg brauchst
Die Installation von kubectl allein reicht nicht aus. Du brauchst einen Cluster und die Berechtigung, ihn zu nutzen. Das kann eine lokale Testumgebung sein, etwa mit kind oder minikube erstellt, oder ein Cluster, den dein Unternehmen oder ein Cloud-Anbieter bereitstellt.
Die Verbindungsdaten stehen normalerweise in einer kubeconfig-Datei. Sie enthält Cluster-Adressen, Einstellungen zur Authentifizierung oder Verweise auf Anmeldeverfahren sowie Kontexte. Ein Kontext legt fest, mit welchem Cluster und als welcher Benutzer du arbeitest; er kann auch den standardmäßig verwendeten Namensraum festlegen. Ein Namensraum, auch Namespace genannt, gruppiert Ressourcen innerhalb eines Clusters.
Der Standardpfad für die Konfiguration ist $HOME/.kube/config, du kannst aber auch eine andere Datei angeben. Prüfe vor der Arbeit den Client und die aktive Verbindung:
kubectl version --client
kubectl config current-context
kubectl cluster-info
Der erste Befehl prüft die Version des lokalen Werkzeugs, bestätigt aber nicht den Zugriff auf den Cluster. Der zweite zeigt den ausgewählten Kontext, und der dritte versucht, Informationen zum Cluster abzurufen. Fehler können durch eine fehlende Konfiguration, Netzwerkprobleme, eine abgelaufene Anmeldung oder unzureichende Berechtigungen entstehen.
Informationen zur Installation und zu den unterstützten Versionsunterschieden zwischen Client und Server findest du in der offiziellen Dokumentation von Kubernetes. Beachte in einer Unternehmensumgebung auch die Anmeldeanweisungen des Administrators.
Grundlegende Befehle zum Prüfen von Anwendungen
Befehle haben meist die Form kubectl verb ressourcentyp name. Mit Optionen kannst du unter anderem den Namensraum und das Ausgabeformat auswählen. Für den Einstieg sind vor allem lesende Operationen hilfreich:
| Befehl | Verwendung |
|---|---|
kubectl get pods -n test | Liste der Pods im Namensraum test und ihr grundlegender Status. |
kubectl describe pod NAME -n test | Details zum Pod sowie Ereignisse, die bei der Diagnose helfen. |
kubectl logs NAME -n test | Logs des Containers im angegebenen Pod. |
kubectl get deployments -n test | Status der Ressourcen, die Kopien der Anwendung verwalten. |
Ersetze NAME durch den tatsächlichen Namen des Pods. Enthält der Pod mehrere Container, kann beim Lesen der Logs die Option -c CONTAINER_NAME nötig sein.
Angenommen, die Anwendung antwortet nach einem Deployment nicht. Beginne mit get pods, um zu prüfen, ob ihre Pods laufen. Verwende anschließend describe und suche nach Ereignissen, die beispielsweise das Herunterladen des Images oder den Start des Containers betreffen. Lies danach die Logs der Anwendung. Der Status des Pods allein reicht nicht immer aus, um die Ursache des Problems zu ermitteln.
Änderungen mit einer YAML-Datei bereitstellen
kubectl kann Ressourcen mit einzelnen Befehlen erstellen. Häufig wird die Anwendungskonfiguration jedoch in einem Manifest gespeichert — einer Datei, die den gewünschten Zustand der Ressourcen beschreibt. Meist wird dafür das Format YAML verwendet. Eine solche Datei lässt sich in einem Repository ablegen, sodass du ihre Änderungen vor dem Deployment prüfen kannst.
Das folgende Manifest erstellt ein Deployment, also eine Ressource, die eine festgelegte Anzahl von Anwendungskopien aufrechterhält und deren Aktualisierung verwaltet:
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo
spec:
replicas: 1
selector:
matchLabels:
app: demo
template:
metadata:
labels:
app: demo
spec:
containers:
- name: nginx
image: nginx:stable
Speichere es als deployment.yaml. In einem Testcluster kannst du die Konfiguration anwenden und den Fortschritt prüfen:
kubectl apply -f deployment.yaml
kubectl rollout status deployment/demo
kubectl get pods -l app=demo
Das Beispiel startet einen nginx-Server, macht ihn aber nicht automatisch im Internet erreichbar. Für den Netzwerkzugriff ist zusätzliche Konfiguration nötig, häufig eine Service-Ressource, die den Datenverkehr an die Pods weiterleitet. Ob sich das Beispiel ausführen lässt, hängt außerdem davon ab, ob das Image heruntergeladen werden kann und genügend Cluster-Ressourcen verfügbar sind.
Änderungen in der falschen Umgebung vermeiden
kubectl kann sowohl Test- als auch Produktionsumgebungen bedienen. Prüfe vor jeder Operation, die Ressourcen verändert, den Kontext und den Namensraum. Du kannst beide mit den Optionen --context und -n ausdrücklich angeben, statt dich auf die Standardeinstellungen zu verlassen.
Vor dem Anwenden eines Manifests helfen kubectl diff -f deployment.yaml, das die Unterschiede zu den bestehenden Ressourcen anzeigt, und kubectl apply --dry-run=server -f deployment.yaml, das eine Testanfrage sendet, ohne die Änderung zu speichern. Beide garantieren jedoch nicht, dass die Anwendung nach dem Deployment korrekt funktioniert.
Der Befehl delete löscht Ressourcen und kann den Betrieb der Anwendung unterbrechen. Behandle die kubeconfig-Datei als vertraulich: Veröffentliche sie nicht in einem Repository und verwende keine Konfiguration aus einer nicht vertrauenswürdigen Quelle. Führe deine ersten Übungen in einem Testcluster durch und beginne damit, den Kontext zu prüfen und den Status der Pods abzurufen.
Siehe auch: Was ist FTP?
Lesen Sie auch
