Einführung
Moderne Anwendungen werden häufig in Containern verpackt. Ein Container bündelt eine Anwendung mit den benötigten Bibliotheken und Einstellungen. Dadurch lässt sie sich zuverlässig und konsistent ausführen. Einen einzelnen Container zu betreiben, ist unkompliziert. Viele Container zuverlässig zu betreiben, ist deutlich anspruchsvoller: Es muss entschieden werden, wo sie ausgeführt werden, ausgefallene Container müssen neu gestartet, Anwendungen miteinander verbunden und Änderungen sicher ausgerollt werden.
Kubernetes ist ein System zur Container-Orchestrierung, das diese Aufgaben auf Cluster-Ebene übernimmt. Sie beschreiben den gewünschten Zustand – zum Beispiel „Führe drei Kopien dieser Webanwendung aus“ – und Kubernetes sorgt fortlaufend dafür, dass der tatsächliche Zustand diesem Ziel entspricht.
Ein Kubernetes-Cluster besteht aus einer oder mehreren Maschinen, den sogenannten Nodes. Die Control Plane verwaltet den Cluster, während Nodes die von Anwendungen benötigten CPU-, Arbeitsspeicher-, Netzwerk- und Container-Runtime-Ressourcen bereitstellen. Anwendungen werden in Kubernetes-Objekten wie Pods, Deployments und Services ausgeführt.
In diesem ersten Lab stellen Sie noch keine Anwendung bereit. Zunächst lernen Sie, sich in einem realen Cluster zurechtzufinden:
- Identifizieren Sie die Werkzeuge, den aktiven Cluster, die Kubernetes-Version und den Zustand der Nodes.
- Finden Sie die Komponenten der Control Plane und der Nodes, die Kubernetes funktionsfähig machen.
- Untersuchen Sie Cluster-Endpunkte und detaillierte Informationen zu Nodes.
- Erkunden Sie Pods, Deployments und Services über mehrere Namespaces hinweg.
Die Umgebung ist bereits vorbereitet, damit Sie sich auf Kubernetes-Konzepte statt auf die Installation konzentrieren können. Sie verwendet Minikube v1.38.1 mit einem Profil namens labex-v135 und führt Kubernetes v1.35.5 aus. Minikube betreibt einen vollständigen Kubernetes-Cluster innerhalb eines Docker-Containers auf der LabEx-VM. Dies ist eine Lernumgebung mit einem einzelnen Node. Die dabei geübten Kubernetes-Befehle und -Konzepte gelten jedoch auch für größere Cluster.
Sie arbeiten vollständig im Terminal. Lesen Sie die Erklärungen, bevor Sie die jeweiligen Befehle ausführen, und vergleichen Sie anschließend die tatsächliche Ausgabe mit den beschriebenen Ergebnissen. Exakte Altersangaben, Neustartzähler und automatisch erzeugte Namen können abweichen. Das ist in einem laufenden System normal.
Den vorkonfigurierten Cluster überprüfen
Start der Umgebung: Dieses Lab startet einen vollständigen Kubernetes-Cluster für Sie. Die Konfiguration der Steuerungsebene, des Knotens und der Netzwerkkomponenten dauert normalerweise 2–3 Minuten. Bitte warten Sie geduldig, bis die Umgebung vollständig geladen ist, bevor Sie beginnen.
In diesem Schritt lernen Sie, wie die Terminalwerkzeuge eine Verbindung zu Kubernetes herstellen, überprüfen die bereitgestellten Softwareversionen und bestätigen, dass der Cluster einsatzbereit ist. Bevor Änderungen an einem Cluster vorgenommen werden, sollte eine Administration immer wissen, welcher Cluster aktiv ist und ob er fehlerfrei arbeitet.
Die Werkzeuge verstehen
Sie verwenden zwei verwandte Befehlszeilenwerkzeuge:
minikubeerstellt und verwaltet lokale Kubernetes-Cluster. Eine benannte Minikube-Umgebung wird als Profil bezeichnet. Dieses Lab verwendet das Profillabex-v135.kubectlist der standardmäßige Kubernetes-Client für die Befehlszeile. Er sendet Anfragen an den Kubernetes-API-Server, um Objekte aufzulisten, zu erstellen, zu aktualisieren und zu löschen.
Der Cluster läuft bereits. Führen Sie nicht minikube start aus: Das ist unnötig und könnte dazu führen, dass Sie warten müssen, während Minikube die vorhandene Umgebung erneut überprüft.
In das Arbeitsverzeichnis wechseln
Wechseln Sie in das Projektverzeichnis. In späteren Labs werden dort Manifeste und andere von Ihnen erstellte Dateien gespeichert:
cd /home/labex/project
Der Befehl cd ändert das aktuelle Verzeichnis der Shell. Bei erfolgreicher Ausführung gibt er normalerweise keine Ausgabe aus.
Die Minikube-Version prüfen
Zeigen Sie die installierte Minikube-Version an. Eine Option, die mit -- beginnt, verändert das Verhalten eines Befehls. Hier fordert --short ausschließlich die Versionsnummer an.
minikube version --short
v1.38.1
Dies ist die Version des Clusterverwaltungswerkzeugs und nicht die Kubernetes-Version. Minikube und Kubernetes sind eigenständige Projekte und besitzen jeweils eigene Versionsnummern.
Client- und Serverversion prüfen
Fordern Sie mit kubectl Versionsinformationen an. Dabei wird der Cluster kontaktiert, sodass sowohl der lokale Client als auch der entfernte API-Server überprüft werden:
kubectl version
Client Version: v1.35.5
Kustomize Version: ...
Server Version: v1.35.5
Client Version bezeichnet die installierte kubectl-Version; Server Version wird vom Kubernetes-API-Server gemeldet. Wenn die Serverzeile angezeigt wird, hat kubectl erfolgreich einen Cluster erreicht. Kustomize ist eine integrierte Funktion zur Anpassung von Manifesten und wird in diesem Lab nicht benötigt.
Den aktiven Kontext bestätigen
Auf einem Computer können Zugriffsdaten für mehrere Cluster in einer kubeconfig-Datei gespeichert werden. Ein kubeconfig-Kontext legt einen Cluster, Anmeldedaten und einen Standard-Namespace fest. Eine Überprüfung verhindert, dass versehentlich im falschen Cluster gearbeitet wird.
kubectl config current-context
labex-v135
Dies entspricht dem vorbereiteten Kubernetes-v1.35-Profil.
Kontexte auflisten und auswählen
Reale kubeconfig-Dateien enthalten häufig mehr als einen Kontext. Listen Sie die Kontexte vor dem Wechsel auf, damit Sie keinen Namen erraten müssen:
kubectl config get-contexts
Die Spalte NAME enthält die Kontextnamen. In der Spalte CURRENT markiert ein * den aktiven Kontext. In den übrigen Spalten werden der zugehörige Cluster, die Authentifizierungsinformationen und der Standard-Namespace angezeigt.
Verwenden Sie use-context, wenn Sie einen dieser Namen auswählen müssen. Die erneute Auswahl von labex-v135 ist sicher, auch wenn dieser Kontext bereits aktiv ist, und ermöglicht es Ihnen, den genauen Ablauf zum Wechseln eines Kontexts zu üben:
kubectl config use-context labex-v135
Switched to context "labex-v135".
current-context beantwortet die Frage „Welcher Kontext ist ausgewählt?“, get-contexts die Frage „Welche Auswahlmöglichkeiten gibt es?“ und use-context NAME ändert die Auswahl. Diese Befehle ändern nur die lokale Auswahl des Clients. Sie starten, stoppen oder verändern keinen Cluster.
Das Minikube-Profil prüfen
Fordern Sie den Status dieses Profils von Minikube an. Die Kurzoption -p steht für Profil und wird vom Profilnamen gefolgt.
minikube status -p labex-v135
labex-v135
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
host bedeutet, dass der Minikube-Node-Container läuft. kubelet ist der Node-Agent. apiserver ist der Kubernetes-API-Endpunkt. kubeconfig: Configured bedeutet, dass die lokale Clientkonfiguration auf diesen Cluster verweist. Alle Komponenten sollten einen gesunden Zustand anzeigen.
Die Nodes auflisten
Die meisten kubectl-Befehle folgen dem Muster kubectl <verb> <resource>. Hier liest get Objekte aus, und nodes bezeichnet den Ressourcentyp:
kubectl get nodes
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35.5
NAME identifiziert den Node. STATUS=Ready bedeutet, dass er Workloads ausführen kann. ROLES zeigt, dass er die Control Plane hostet. AGE kann aufgrund eines wiederhergestellten vorbereiteten Snapshots älter sein als diese Sitzung. VERSION ist die Version des Kubelets.
Dieses Lab verfügt über einen Node, der sowohl Aufgaben der Control Plane als auch Workloads übernimmt. In Produktionsclustern werden diese Aufgaben häufig auf mehrere Maschinen verteilt.
Zwischenstand
Sie haben bestätigt, dass kubectl den vorgesehenen Cluster labex-v135 erreicht und dessen Node unter Kubernetes v1.35.5 den Status Ready besitzt. Diese kurze Orientierung ist eine nützliche Routine, wenn Sie sich in einem unbekannten Cluster anmelden.
Komponenten der Kubernetes-Architektur identifizieren
In diesem Schritt verknüpfen Sie das Architekturmodell von Kubernetes mit den tatsächlich laufenden Komponenten. Begriffe wie API-Server, Scheduler und Kubelet lassen sich leichter einprägen, wenn Sie die zugehörigen Pods sehen.
Den Weg einer Anfrage durch Kubernetes verfolgen
Stellen Sie sich vor, Sie bitten Kubernetes, eine Webanwendung auszuführen. Zunächst sendet kubectl die Anfrage an den kube-apiserver, der sie validiert und den gewünschten Zustand in etcd speichert.
Anschließend wählt der kube-scheduler für jeden neuen Pod einen Node aus. Der kube-controller-manager beobachtet den Cluster und arbeitet fortlaufend daran, den tatsächlichen Zustand an den gewünschten Zustand anzupassen.
Schließlich weist das kubelet auf dem ausgewählten Node die Container-Runtime an, die Container des Pods zu starten. Netzwerkkomponenten ermöglichen die Kommunikation zwischen Pods und Services.
Dieser fortlaufende Vergleich zwischen gewünschtem und tatsächlichem Zustand wird Reconciliation genannt. Fordert ein Deployment beispielsweise drei Pods an, existieren aber nur zwei, erstellt ein Controller den fehlenden Pod.
Pods und System-Namespaces verstehen
Ein Pod ist die kleinste bereitstellbare Einheit in Kubernetes. Er kapselt einen oder mehrere eng miteinander verbundene Container und stellt ihnen einen gemeinsamen Netzwerk- und Speicherkontext bereit.
Ein Namespace bildet einen logischen Gültigkeitsbereich für Objekte, die an einen Namespace gebunden sind. kube-system enthält die Clusterinfrastruktur. Die Option -n kube-system weist kubectl an, dort statt im Standard-Namespace zu suchen. Die längere Entsprechung lautet --namespace=kube-system; beide Formen wählen denselben Gültigkeitsbereich.
Minikube führt Komponenten der Control Plane als statische Pods aus. Das Kubelet erstellt diese direkt aus Dateien auf dem Node. Dadurch kann die Control Plane starten, bevor die normale Pod-Planung verfügbar ist.
Die Control Plane auflisten
Objekte können Labels tragen, also Schlüssel-Wert-Metadaten zur Gruppierung und Auswahl. Mit -l tier=control-plane wählen Sie Pods aus, die dieses Label besitzen:
kubectl get pods -n kube-system -l tier=control-plane
NAME READY STATUS RESTARTS AGE
etcd-labex-v135 1/1 Running ... ...
kube-apiserver-labex-v135 1/1 Running ... ...
kube-controller-manager-labex-v135 1/1 Running ... ...
kube-scheduler-labex-v135 1/1 Running ... ...
Der API-Server ist das Eingangstor von Kubernetes. etcd speichert den Clusterzustand. Der Scheduler entscheidet, auf welchem Node ein Pod ausgeführt wird. Der Controller Manager betreibt die Controller zur fortlaufenden Zustandsangleichung.
READY=1/1 bedeutet, dass der eine Container des Pods bereit ist. Komponenten, die dauerhaft laufen, sollten den Status Running besitzen. RESTARTS kann nach dem Fortsetzen des gespeicherten Clusters ungleich null sein. AGE beschreibt das Alter des Objekts und nicht die Zeit, die Sie in diesem Lab verbracht haben.
Die Labels untersuchen
Zeigen Sie die Labels in einer zusätzlichen Spalte an:
kubectl get pods -n kube-system -l tier=control-plane --show-labels
Achten Sie auf component=kube-apiserver und tier=control-plane. Das erste Label kennzeichnet eine Komponente, das zweite gruppiert alle Pods der Control Plane. Labels identifizieren Objekte, und Selektoren finden passende Objekte.
Netzwerkkomponenten der Nodes untersuchen
Verwenden Sie einen mengenbasierten Selektor. Er bedeutet, dass k8s-app entweder kube-proxy oder calico-node entspricht. Die Anführungszeichen verhindern, dass die Shell die Klammern interpretiert.
kubectl get pods -n kube-system -l 'k8s-app in (kube-proxy,calico-node)'
NAME READY STATUS RESTARTS AGE
calico-node-... 1/1 Running ... ...
kube-proxy-... 1/1 Running ... ...
Calico konfiguriert das Pod-Netzwerk. kube-proxy verwaltet Regeln auf dem Node, die Services dabei unterstützen, Datenverkehr an Pods weiterzuleiten. Das Kubelet erscheint in dieser Liste nicht, da es sich um den Host-Agenten handelt, der für den Betrieb der Pods zuständig ist. Es läuft daher als Host-Dienst und nicht als gewöhnlicher, von sich selbst verwalteter Pod.
Zwischenstand
Der API-Server nimmt Anfragen entgegen, etcd speichert den Zustand, der Scheduler entscheidet über die Platzierung, Controller gleichen den Zustand ab, das Kubelet betreibt den Node, und Calico zusammen mit kube-proxy stellt die Netzwerkfunktionen bereit.
Cluster- und Node-Details untersuchen
In diesem Schritt wechseln Sie von einer einfachen Zustandsprüfung zu einer detaillierten Untersuchung. Kubernetes bietet sowohl kompakte Listenansichten als auch ausführliche Beschreibungen. Zu wissen, wann welche Ansicht sinnvoll ist, gehört zu den wichtigsten Gewohnheiten bei der Fehlersuche.
Cluster-Endpunkte ermitteln
kubectl cluster-info ist ein speziell für die Orientierung vorgesehener Befehl. Im Gegensatz zu kubectl get listet er keinen einzelnen Ressourcentyp auf, sondern fordert vom aktiven Cluster die Adressen wichtiger Dienste wie des API-Servers und von CoreDNS an.
kubectl cluster-info
Kubernetes control plane is running at https://...
CoreDNS is running at https://...
Die URL der Control Plane ist der Endpunkt des API-Servers. CoreDNS stellt die DNS-Diensterkennung bereit. Dadurch können Workloads Services anhand ihres Namens finden, ohne wechselnde IP-Adressen verfolgen zu müssen. Die Adressen können abweichen. Entscheidend ist die Meldung is running, die zeigt, dass der API-Server Informationen zurückgegeben hat. Sie beweist nicht, dass jeder Workload gesund ist.
Die Node-Liste erweitern
Fügen Sie -o wide hinzu, um weitere Spalten anzufordern:
kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP ... OS-IMAGE
labex-v135 Ready control-plane ... v1.35.5 192.168.49.2 ... Debian GNU/Linux 12 (bookworm)
INTERNAL-IP ist die Adresse des Nodes im Cluster-Netzwerk. EXTERNAL-IP=<none> bedeutet, dass ihm keine von Kubernetes verwaltete öffentliche Adresse zugewiesen wurde. OS-IMAGE, KERNEL-VERSION und CONTAINER-RUNTIME beschreiben die Software des Nodes.
Das LabEx-Backend verwendet Ubuntu 22.04, während Minikube den Kubernetes-Node durch einen Debian-basierten Docker-Container darstellt. Die Anzeige von Debian ist daher erwartungsgemäß.
Einen Node beschreiben
Verwenden Sie describe, wenn eine Listenzeile nicht genügend Details enthält. Die Form lautet kubectl describe <resource-type> <name>; hier ist der Ressourcentyp node und der Objektname labex-v135:
kubectl describe node labex-v135
Untersuchen Sie im oberen Bereich die Identität und die Planungseinstellungen:
Name: labex-v135
Roles: control-plane
Taints: <none>
Unschedulable: false
Taints können Pods abweisen, die diese Taints nicht tolerieren. <none> bedeutet, dass dieser Lern-Node keine Taints besitzt. Unschedulable: false bedeutet, dass Kubernetes Workloads auf diesem Node platzieren darf.
Suchen Sie die Tabelle Conditions:
Type Status ... Reason
NetworkUnavailable False ... CalicoIsUp
MemoryPressure False ... KubeletHasSufficientMemory
DiskPressure False ... KubeletHasNoDiskPressure
PIDPressure False ... KubeletHasSufficientPID
Ready True ... KubeletReady
Bei den Bedingungen zu Ressourcenknappheit und Netzwerkausfall ist False gesund, weil das jeweilige Problem nicht vorliegt. Bei Ready ist True der gesunde Wert. Lesen Sie den Namen der Bedingung immer zusammen mit ihrem Wert.
Capacity bezeichnet die insgesamt gemeldeten Ressourcen des Nodes. Allocatable gibt an, welche Ressourcen Kubernetes Pods nach Abzug der Systemreservierungen anbieten kann. System Info enthält Informationen zur Runtime und zum Kubelet. In späteren Abschnitten werden Pods, reservierte Anforderungen und Limits sowie Ereignisse aufgelistet. Exakte Werte und Zeitstempel können abweichen.
Zwischenstand
Verwenden Sie get für eine schnelle Tabelle, get -o wide für zusätzliche Spalten und describe für Bedingungen, Kapazität, Runtime-Details und Ereignisse eines einzelnen Objekts.
Ressourcen über Namespaces hinweg untersuchen
In diesem Schritt erstellen Sie eine erste Übersicht über wichtige Objekte: Namespaces organisieren Ressourcen, Pods führen Container aus, Deployments verwalten Pods, und Services stellen einen stabilen Netzwerkzugriff bereit.
Die Beziehungen zwischen den Objekten verstehen
- Ein Pod ist die kleinste bereitstellbare Einheit und enthält einen oder mehrere Container.
- Ein Deployment legt fest, wie viele Kopien einer zustandslosen Anwendung ausgeführt werden sollen, und verwaltet Pods über ein ReplicaSet.
- Ein Service gibt ausgewählten Pods eine stabile virtuelle IP-Adresse und einen DNS-Namen, da sich die IP-Adressen ersetzbarer Pods ändern können.
- Ein Namespace gruppiert an Namespaces gebundene Objekte und ermöglicht denselben Namen in unterschiedlichen Gültigkeitsbereichen.
Vereinfacht gesagt verwaltet ein Deployment Pods, während ein Service diese Pods auswählt und Clients einen stabilen Endpunkt bereitstellt. Nicht jedes Objekt ist an einen Namespace gebunden; Nodes gehören zum gesamten Cluster.
Pods in allen Namespaces auflisten
Ohne eine Namespace-Option sucht kubectl get pods nur im aktuellen Namespace. -A bedeutet --all-namespaces:
kubectl get pods -A
NAMESPACE bezeichnet den logischen Gültigkeitsbereich. NAME identifiziert den Pod innerhalb dieses Bereichs. READY zeigt die Anzahl bereiter Container im Verhältnis zur Gesamtzahl der Container. STATUS bezeichnet die Lebenszyklusphase. RESTARTS zählt Neustarts, und AGE gibt das Alter des Objekts an.
Dauerhaft laufende Infrastruktur sollte den Status Running besitzen. Einige Pods für Ingress-Admission können den Status Completed mit einer Bereitschaft von 0/1 anzeigen, weil sie einmalige Jobs ausgeführt und anschließend erfolgreich beendet haben. Der Zustand muss immer im Zusammenhang mit dem Zweck des jeweiligen Workloads bewertet werden.
Deployments auflisten
Der Plural deployments fordert Deployment-Objekte an. Behalten Sie -A bei, weil sich System-Deployments außerhalb des aktuellen default-Namespaces befinden:
kubectl get deployments -A
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
ingress-nginx ingress-nginx-controller 1/1 1 1 ...
kube-system calico-kube-controllers 1/1 1 1 ...
kube-system coredns 1/1 1 1 ...
kube-system metrics-server 1/1 1 1 ...
READY zeigt die Anzahl bereiter Replikate im Verhältnis zur gewünschten Anzahl. UP-TO-DATE zählt Replikate, die die aktuelle Pod-Vorlage verwenden. AVAILABLE zählt Replikate, die für ihren vorgesehenen Zweck verfügbar sind. Der zuvor gesehene Pod coredns-... wird vom Deployment coredns verwaltet.
Services auflisten
Pods können ersetzt werden. Clients sollten sich daher nicht auf eine Pod-IP-Adresse verlassen. Listen Sie die stabilen Service-Endpunkte auf:
kubectl get services -A
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default kubernetes ClusterIP 10.96.0.1 <none> 443/TCP ...
kube-system kube-dns ClusterIP 10.96.0.10 <none> ... ...
ingress-nginx ingress-nginx-controller NodePort ... <none> ... ...
TYPE beschreibt die Zugriffsart. ClusterIP ist innerhalb des Clusters erreichbar; NodePort öffnet zusätzlich einen Port auf dem Node. CLUSTER-IP ist die stabile virtuelle Adresse. EXTERNAL-IP=<none> bedeutet, dass keine externe Adresse zugewiesen wurde. PORT(S) listet die freigegebenen Protokolle und Ports auf.
Der Service kubernetes stellt die API innerhalb des Clusters bereit. kube-dns ermöglicht den stabilen Zugriff auf CoreDNS. Ingress-Services unterstützen eingehenden HTTP- und HTTPS-Verkehr.
Eine kombinierte Ansicht erstellen
Wenn Sie noch nicht wissen, welche der üblichen Workload-Arten vorhanden sind, bietet kubectl get all eine kombinierte Übersichtsansicht. Durch Hinzufügen von -A wird der bereits verwendete Gültigkeitsbereich „alle Namespaces“ erneut angewendet:
kubectl get all -A
Dabei werden häufige Ressourcen wie Pods, Services, DaemonSets, Deployments, ReplicaSets und Jobs gruppiert. Eine Komponente kann auf mehreren Ebenen erscheinen: als Deployment, ReplicaSet und Pod.
Trotz seines Namens gibt get all nicht jede Ressource zurück. ConfigMaps, Secrets, NetworkPolicies und viele weitere Ressourcen werden ausgelassen. Verwenden Sie den Befehl zur Orientierung und fordern Sie anschließend den genauen Ressourcentyp an.
Zwischenstand
Namespaces stellen den Gültigkeitsbereich bereit, Pods führen Container aus, Deployments halten die gewünschte Anzahl von Pod-Replikaten aufrecht, und Services ermöglichen einen stabilen Netzwerkzugriff auf wechselnde Pods.
Zusammenfassung
Sie haben Ihre erste geführte Erkundung eines Kubernetes-Clusters abgeschlossen. Sie haben gelernt, dass Kubernetes den gewünschten Zustand über mehrere Nodes hinweg verwaltet und dass kubectl mithilfe des aktiven kubeconfig-Kontexts mit dem API-Server kommuniziert.
Sie haben geübt, wie sich die Versionen von Minikube, Kubernetes und kubectl unterscheiden lassen, wie Kontext und Node-Bereitschaft überprüft werden, wie Komponenten der Control Plane, der Nodes und des Netzwerks identifiziert werden, wie Labels und Selektoren verwendet werden, wann get, get -o wide und describe zum Einsatz kommen, wie Node-Bedingungen und Kapazitäten interpretiert werden und wie Namespaces, Pods, Deployments und Services zusammenhängen.
Die wichtigste Gewohnheit für Einsteiger lautet: Erst untersuchen, dann ändern. Bestätigen Sie den Kontext, prüfen Sie den Zustand der Nodes, ermitteln Sie den relevanten Namespace und Ressourcentyp und lesen Sie den gemeldeten Zustand sorgfältig. Die folgenden Labs bauen auf diesem Modell auf, während Sie eigene Workloads erstellen.
