Was sind die Hauptkomponenten der Kubernetes-Architektur und wofür sind sie jeweils verantwortlich?

Ein Kubernetes-Cluster besteht aus einer Steuerungsebene sowie einer Reihe von Arbeitsmaschinen, sogenannten Knoten, die containerisierte Anwendungen in Pods ausführen. Jeder Cluster benötigt mindestens einen Worker-Knoten, um Pods auszuführen.

Vom Konzept her ist Kubernetes deklarativ: Sie übermitteln den gewünschten Zustand an den API-Server (gespeichert in etcd), und Controller führen kontinuierliche Abgleichsschleifen aus, die auf Unterschiede achten und so agieren, dass sie den tatsächlichen Zustand in den gewünschten Zustand bringen.

Komponenten der Steuerebene

Die Steuerungsebene trifft globale Entscheidungen über den Cluster (z. B. Planung) und reagiert auf Clusterereignisse. In der Produktion läuft es für eine hohe Verfügbarkeit meist auf mehreren Maschinen.

• kube-apiserver – die Kernkomponente, die die Kubernetes-HTTP-API verfügbar macht. Es ist das Frontend der Steuerebene und der einzige Kontaktpunkt: Alle Authentifizierung, Autorisierung, Anforderungsvalidierung und Lese-/Schreibvorgänge des Clusterstatus fließen über es. Es skaliert horizontal. In normalen Bereitstellungen ist es die einzige Kubernetes-Komponente, die den Clusterstatus direkt in etcd liest und schreibt; Alle anderen Komponenten interagieren mit dem Status über den API-Server.
• etcd – ein konsistenter und hochverfügbarer Schlüsselwertspeicher, der als Kubernetes-Backing-Speicher für alle Clusterdaten verwendet wird: Konfiguration, Status und Metadaten. etcd ist obligatorisch und stellt die einzige Quelle der Wahrheit dar. Wenn Sie es verlieren, verlieren Sie den gesamten Clusterstatus. Daher muss es mit Quorum (einer ungeraden Anzahl von Mitgliedern) ausgeführt und regelmäßig gesichert werden.
• kube-scheduler – sucht nach Pods, die noch nicht an einen Knoten gebunden sind, und weist jeden Pod unter Berücksichtigung von Ressourcen, Einschränkungen und Richtlinien einem geeigneten Knoten zu.
• kube-controller-manager – führt Controller aus, die das Kubernetes-API-Verhalten implementieren (z. B. Node-Controller, Job-Controller, EndpointSlice-Controller). Jeder Controller überwacht den gewünschten Zustand und gleicht ihn mit dem tatsächlichen Zustand ab.
• cloud-controller-manager (optional) – integriert sich in den zugrunde liegenden Cloud-Anbieter und isoliert cloudspezifische Logik von den Kubernetes-Kernkomponenten.

Knotenkomponenten

Diese laufen auf jedem Knoten, halten die Pods am Laufen und stellen die Laufzeitumgebung bereit.

• kubelet – der Agent, der sicherstellt, dass Pods ausgeführt werden, einschließlich ihrer Container. Es überwacht den API-Server auf Pod-Zuweisungen, startet Container über die Laufzeit, stellt Volumes bereit, führt Liveness-/Bereitschaftsprüfungen durch und meldet den Knotenstatus.
• kube-proxy – implementiert Service-Netzwerke durch Programmierung von iptables oder IPVS-Regeln auf Knoten, sodass der Datenverkehr zu einem Service an die richtigen Pod-IPs weitergeleitet wird. Es ist als optional markiert, da einige CNI-Plugins (z. B. Cilium im eBPF-Modus) seine Aufgabe übernehmen, in einem Standardcluster ist es jedoch erforderlich.
• Container-Laufzeit – die Software, die für die Ausführung von Containern (Container, CRI-O usw. über die CRI-Schnittstelle) verantwortlich ist.

Add-ons

Add-ons erweitern die Cluster-Funktionalität: Cluster-DNS (standardmäßig CoreDNS), die Dashboard-Web-Benutzeroberfläche, Container-Ressourcenüberwachung und Protokollierung auf Cluster-Ebene.

Gemeinsame Folgemaßnahmen: Die gesamte Kommunikation läuft über den API-Server – der Scheduler, die Controller und die Kubelets beobachten sie einfach und reagieren – was den API-Server zum kritischen Knotenpunkt des Clusters macht.