Kubernetes-Cluster-Architektur

KubernetesKubernetesBeginner
Jetzt üben

💡 Dieser Artikel wurde von AI-Assistenten übersetzt. Um die englische Version anzuzeigen, können Sie hier klicken

Einführung

In diesem Lab werden wir die Architektur von Kubernetes, einer leistungsstarken Container-Orchestrierungsplattform, erkunden. Wir werden die Schlüsselkomponenten eines Kubernetes-Clusters untersuchen und lernen, wie sie zusammenwirken, um containerisierte Anwendungen zu verwalten. Dieses Lab ist für Anfänger konzipiert und bietet eine praktische Einführung in die Kubernetes-Architektur.

Dies ist ein Guided Lab, das schrittweise Anweisungen bietet, um Ihnen beim Lernen und Üben zu helfen. Befolgen Sie die Anweisungen sorgfältig, um jeden Schritt abzuschließen und praktische Erfahrungen zu sammeln. Historische Daten zeigen, dass dies ein Labor der Stufe Anfänger mit einer Abschlussquote von 90% ist. Es hat eine positive Bewertungsrate von 94% von den Lernenden erhalten.

Starten von Minikube und Erkunden der Control-Plane-Komponenten

Beginnen wir damit, einen Kubernetes-Cluster mit Minikube zu starten und die Control-Plane-Komponenten zu untersuchen.

Zunächst öffnen Sie Ihr Terminal. Standardmäßig sollten Sie sich im Verzeichnis /home/labex/project befinden. Wenn nicht, navigieren Sie dorthin:

cd ~/project

Jetzt starten Sie Minikube mit dem folgenden Befehl:

minikube start

Dieser Befehl initialisiert einen Ein-Knoten-Kubernetes-Cluster auf Ihrem lokalen Rechner. Die Ausführung kann einige Minuten dauern. Machen Sie sich keine Sorgen, wenn Sie viel Ausgabe sehen – das ist normal.

Sobald Minikube gestartet ist, lassen Sie uns die Control-Plane-Komponenten erkunden. Die Control Plane ist das "Gehirn" von Kubernetes und verantwortlich für die Verwaltung des Gesamtzustands des Clusters. Um den Status dieser Komponenten zu überprüfen, führen Sie aus:

kubectl get componentstatuses

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

NAME                 STATUS    MESSAGE             ERROR
scheduler            Healthy   ok
controller-manager   Healthy   ok
etcd-0               Healthy   {"health":"true"}

Lassen Sie uns untersuchen, was jede dieser Komponenten tut:

  1. Der Scheduler: Diese Komponente beobachtet neu erstellte Pods, denen kein Knoten zugewiesen ist, und wählt einen Knoten aus, auf dem sie laufen sollen.
  2. Der Controller Manager: Dieser führt Controller-Prozesse aus, die den Zustand des Systems regulieren. Beispielsweise stellt der Replikationscontroller sicher, dass die richtige Anzahl von Pod-Replikaten läuft.
  3. etcd: Dies ist ein verteilter Schlüssel-Wert-Speicher, der als Backing Store von Kubernetes für alle Clusterdaten fungiert.

Wenn alle Komponenten "Healthy" anzeigen, funktioniert Ihre Control Plane korrekt. Wenn Sie Fehler sehen, kann es sich lohnen, Minikube mit minikube delete zu löschen und anschließend mit minikube start neu zu starten.

Untersuchung der Knotenkomponenten

Nachdem wir uns die Control-Plane-Komponenten angesehen haben, wollen wir uns nun die Knotenkomponenten anschauen. In Kubernetes sind Knoten die Arbeitsmaschinen, auf denen Ihre Anwendungen laufen. Stellen Sie sich sie als die "Muskeln" Ihres Clusters vor, die die schweren Aufgaben beim Ausführen von Containern übernehmen.

Um die Knoten in Ihrem Cluster anzuzeigen, führen Sie folgenden Befehl aus:

kubectl get nodes

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

NAME       STATUS   ROLES    AGE   VERSION
minikube   Ready    control plane   10m   v1.20.0

Diese Ausgabe zeigt, dass wir einen Knoten namens "minikube" haben, der sowohl ein Master-Knoten (Control Plane) als auch ein Arbeitsknoten ist, da wir einen Ein-Knoten-Cluster verwenden. In einer Produktionsumgebung würden Sie normalerweise mehrere Knoten haben, wobei Master- und Arbeitsknoten getrennt sind.

Der Status "Ready" bedeutet, dass der Knoten gesund ist und bereit ist, Pods anzunehmen.

Um detailliertere Informationen über den Knoten zu erhalten, verwenden Sie folgenden Befehl:

kubectl describe node minikube

Dieser Befehl liefert eine Fülle von Informationen über den Knoten. Machen Sie sich keine Sorgen, wenn es überwältigend erscheint – lassen Sie uns einige Schlüsselabschnitte aufschlüsseln:

  1. Node Conditions (Knotenbedingungen): Diese zeigen den Status verschiedener Knotenbedingungen (z. B. Ready, DiskPressure, MemoryPressure).
  2. Capacity (Kapazität): Dies zeigt die gesamten auf dem Knoten verfügbaren Ressourcen (CPU und Arbeitsspeicher).
  3. Allocatable (Zuweisbare Ressourcen): Dies zeigt die Ressourcen, die für Pods zur Verfügung stehen.
  4. System Info (Systeminformationen): Dies liefert Informationen über das Betriebssystem des Knotens, die Kernel-Version und die Container-Runtime.

Die wichtigsten Knotenkomponenten, die Sie nicht direkt sehen, aber die auf dem Knoten laufen, umfassen:

  1. kubelet: Dies ist der primäre Knoten-Agent. Er beobachtet die Pods, die seinem Knoten zugewiesen wurden, und stellt sicher, dass sie laufen.
  2. kube-proxy: Dieser verwaltet die Netzwerkregeln auf dem Knoten und ermöglicht die Netzwerkkommunikation mit Ihren Pods von innerhalb oder außerhalb Ihres Clusters.

Erstellen und Untersuchen eines Pods

Bevor wir loslegen, verstehen wir zunächst, wie YAML in Kubernetes funktioniert:

graph TB A[YAML Config File] -->|Declares Desired State| B[Kubernetes API] B -->|Creates/Manages| C[Running Containers] D[kubectl CLI] -->|Reads| A

YAML-Dateien in Kubernetes fungieren als "Infrastructure as Code" (Infrastruktur als Code):

  • Stellen Sie sich sie als eine "Speisekarte" vor, die Kubernetes mitteilt, was Sie möchten.
  • Beschreiben den gewünschten Systemzustand in einem menschenlesbaren Format.
  • Können für die Teamarbeit versioniert werden.

Lassen Sie uns unsere erste YAML-Datei erstellen. Erstellen Sie simple-pod.yaml:

nano ~/project/simple-pod.yaml

Fügen Sie den folgenden Inhalt hinzu:

## --- Beginn der YAML-Datei ---
## 1. Teilen Sie Kubernetes mit, welche API-Version verwendet werden soll
apiVersion: v1
## 2. Deklarieren Sie, welche Art von Ressource Sie erstellen möchten
kind: Pod
## 3. Legen Sie die Metadaten für diese Ressource fest
metadata:
  name: nginx-pod ## Name des Pods
  labels: ## Labels helfen uns, Pods zu finden und zu organisieren
    app: nginx
## 4. Definieren Sie, was der Pod enthalten soll
spec:
  containers: ## Ein Pod kann einen oder mehrere Container ausführen
    - name: nginx ## Name des Containers
      image: nginx:latest ## Welches Container-Image verwendet werden soll
      ports: ## Welche Ports freigegeben werden sollen
        - containerPort: 80 ## Nginx verwendet standardmäßig Port 80

Die Struktur der YAML-Datei ist wie ein Baum:

Pod (Wurzel)
├── metadata (Zweig)
│   ├── name (Blatt)
│   └── labels (Blatt)
└── spec (Zweig)
    └── containers (Zweig)
        └── - name, image, ports (Blätter)

Erstellen Sie den Pod:

kubectl apply -f simple-pod.yaml ## -f bedeutet, aus einer Datei lesen

Dieser Befehl wird:

  1. Ihre YAML-Datei lesen.
  2. Sie an die Kubernetes-API senden.
  3. Kubernetes wird arbeiten, um den von Ihnen beschriebenen Zustand zu erreichen.

Überprüfen Sie die Erstellung des Pods:

kubectl get pods

Sie sollten Folgendes sehen:

NAME        READY   STATUS    RESTARTS   AGE
nginx-pod   1/1     Running   0          30s

Das "1/1" unter READY bedeutet, dass einer von einem Container im Pod bereit ist. "Running" unter STATUS bedeutet, dass Ihre erste YAML-Konfiguration funktioniert hat!

💡 Pro-Tipps:

  • Die Einrückung in YAML ist von entscheidender Bedeutung - verwenden Sie Leerzeichen, keine Tabulatoren.
  • Verwenden Sie kubectl explain pod, um die Felddokumentation anzuzeigen.
  • Fügen Sie immer Kommentare hinzu, um die Wartbarkeit zu verbessern.

Um detaillierte Informationen über den Pod zu erhalten:

kubectl describe pod nginx-pod

Dieser Befehl liefert viele Informationen, darunter:

  • Der Knoten, auf dem der Pod läuft.
  • Die IP-Adresse des Pods.
  • Die Container im Pod.
  • Kürzlich aufgetretene Ereignisse im Zusammenhang mit dem Pod.

Diese Informationen sind für die Fehlersuche und das Verständnis des Zustands Ihrer Anwendung von entscheidender Bedeutung.

Erstellen eines Services

Nachdem wir nun einen laufenden Pod haben, erstellen wir einen Service, um ihn bereitzustellen. In Kubernetes ist ein Service eine Abstraktion, die eine logische Gruppe von Pods und eine Richtlinie zur Zugriffssteuerung definiert. Stellen Sie sich ihn als eine Möglichkeit vor, Ihre Anwendung im Netzwerk, entweder innerhalb des Clusters oder extern, zugänglich zu machen.

Erstellen Sie eine Datei namens nginx-service.yaml in Ihrem Projektverzeichnis:

nano ~/project/nginx-service.yaml

Fügen Sie der Datei den folgenden Inhalt hinzu:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: NodePort

Lassen Sie uns diese YAML-Datei analysieren:

  • selector: Dies bestimmt, an welche Pods der Service den Datenverkehr leiten wird. In diesem Fall werden alle Pods ausgewählt, die das Label app: nginx tragen.
  • ports: Hier werden die Ports angegeben, die der Service verwenden soll.
  • type: NodePort: Dies bedeutet, dass der Service über einen Port auf jedem Knoten in Ihrem Cluster zugänglich sein wird.

Speichern Sie die Datei und verlassen Sie den Editor.

Jetzt erstellen Sie den Service, indem Sie folgenden Befehl ausführen:

kubectl apply -f nginx-service.yaml

Um den Status Ihres Services zu überprüfen, verwenden Sie:

kubectl get services

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes      ClusterIP   10.96.0.1       <none>        443/TCP        1h
nginx-service   NodePort    10.110.126.65   <none>        80:30080/TCP   30s

Die Zeile nginx-service zeigt, dass Ihr Service erstellt wurde. Die Angabe 80:30080/TCP unter PORT(S) bedeutet, dass Port 80 innerhalb des Clusters auf Port 30080 auf dem Knoten gemappt ist.

Um detailliertere Informationen über den Service zu erhalten, verwenden Sie:

kubectl describe service nginx-service

Dieser Befehl liefert Informationen über den Service-Typ, die IP-Adressen, die Ports und die Endpunkte. Die Endpunkte sind die IP-Adressen der Pods, an die der Service den Datenverkehr leitet.

Zugriff auf die Anwendung

Nachdem wir nun einen Pod, der unsere Anwendung ausführt, und einen Service, der diese zugänglich macht, haben, wollen wir auf die Anwendung zugreifen. Dieser Schritt zeigt Ihnen, wie alle von uns eingerichteten Komponenten zusammenarbeiten, um Ihre Anwendung zugänglich zu machen.

Zunächst müssen wir herausfinden, welche URL Minikube unserem Service zugewiesen hat:

minikube service nginx-service --url

Dieser Befehl gibt eine URL aus, die in etwa so aussehen sollte: http://192.168.64.2:30080. Die IP-Adresse kann auf Ihrem Rechner unterschiedlich sein.

Um auf die Anwendung zuzugreifen, können Sie den curl-Befehl gefolgt von der URL verwenden:

curl $(minikube service nginx-service --url)

Dies sollte die Standard-Willkommensseite von Nginx als HTML zurückgeben. Wenn Sie eine HTML-Ausgabe sehen, die mit <!DOCTYPE html> beginnt, herzlichen Glückwunsch! Sie haben erfolgreich auf Ihre Anwendung zugegriffen.

Lassen Sie uns analysieren, was gerade passiert ist:

  1. Ihre Anfrage traf zunächst auf den von uns erstellten NodePort-Service.
  2. Der Service leitet die Anfrage dann an den Pod weiter, der den Nginx-Container ausführt.
  3. Der Nginx-Container verarbeitet die Anfrage und sendet die Standard-Willkommensseite zurück.

Dies zeigt, wie Kubernetes die zugrunde liegende Infrastruktur abstrahiert und es Ihnen ermöglicht, sich auf Ihre Anwendung zu konzentrieren, anstatt sich Gedanken darüber zu machen, auf welchem bestimmten Rechner sie läuft.

Zusammenfassung

In diesem Lab haben wir die Architektur von Kubernetes erkundet, indem wir seine Schlüsselkomponenten und deren Interaktionen untersucht haben. Wir haben einen Kubernetes-Cluster mit Minikube gestartet, die Control-Plane- und Knotenkomponenten inspiziert, einen Pod erstellt, um eine Anwendung auszuführen, die Anwendung über einen Service zugänglich gemacht und schließlich auf die Anwendung zugegriffen.

graph TB subgraph Control Plane API[API Server] CM[Controller Manager] SCH[Scheduler] ETCD[etcd] API --> ETCD API --> CM API --> SCH end subgraph Worker Node KL[kubelet] KP[kube-proxy] CR[Container Runtime] subgraph Workloads POD1[Pod] POD2[Pod] end SVC[Service] KL --> CR POD1 --> CR POD2 --> CR KP --> SVC SVC --> POD1 SVC --> POD2 end API --> KL Client[External Client] --> SVC

Wir haben gelernt über:

  • Control-Plane-Komponenten wie den API-Server, den Scheduler und den Controller-Manager
  • Knotenkomponenten wie kubelet und kube-proxy
  • Pods als die kleinsten deployierbaren Einheiten in Kubernetes
  • Services als Möglichkeit, Anwendungen zugänglich zu machen

Diese praktische Erfahrung bietet eine solide Grundlage für das Verständnis der Kubernetes-Architektur. Denken Sie daran, dass Kubernetes ein komplexes System mit vielen beweglichen Teilen ist, und es ist in Ordnung, wenn Sie nicht alles sofort verstehen. Wenn Sie weiterhin mit Kubernetes arbeiten, werden diese Konzepte Ihnen vertrauter und intuitiver werden.

Nächste Schritte in Ihrer Kubernetes-Reise könnten das Lernen über Deployments zur Verwaltung mehrerer Replikate Ihrer Anwendung, ConfigMaps und Secrets zur Verwaltung der Konfiguration sowie Persistent Volumes zur Datenspeicherung umfassen. Bleiben Sie neugierig und viel Spaß mit Kubernetes!