Kubernetes-Architektur

Willkommen bei Kubernetes! Es ist ein leistungsfähiges System zur Verwaltung containerisierter Anwendungen über viele Rechner hinweg.

Bevor Sie sich mit dem Ausführen von Anwendungen beschäftigen, ist es wichtig, die grundlegende Struktur zu verstehen. Stellen Sie es sich so vor, als würden Sie zuerst die Teile eines Autos kennenlernen, bevor Sie es fahren!

Im Kern arbeitet Kubernetes als Cluster. Ein Cluster ist eine Gruppe von Rechnern, die als Knoten bezeichnet werden und zusammenarbeiten.

Diese Knoten werden in zwei Haupttypen unterteilt:

• Control Plane (Master Node): Das Gehirn des Clusters.
• Worker Nodes: Die Arbeitsrechner, auf denen Ihre Anwendungen ausgeführt werden.

Die Control Plane (in älteren Dokumentationen oft als Master Node bezeichnet) ist für die Verwaltung des Clusters zuständig.

Sie trifft globale Entscheidungen über den Cluster, etwa zur Planung von Anwendungen, und erkennt und verarbeitet Cluster-Ereignisse, etwa den Neustart einer fehlgeschlagenen Anwendung. Ihre Anwendungen werden nicht direkt auf ihr ausgeführt.

Der API-Server ist die Frontend-Komponente der Kubernetes-Control-Plane. Er ist die einzige Komponente, die direkt mit Ihnen interagiert (über kubectl).

Er stellt die Kubernetes-API bereit und verarbeitet die gesamte Kommunikation innerhalb des Clusters. Dabei validiert und konfiguriert er Daten für API-Objekte wie Pods und Services.

etcd ist ein konsistenter und hochverfügbarer Key-Value-Store. Stellen Sie es sich als dauerhaftes Gedächtnis des Clusters vor.

Es speichert sämtliche Clusterdaten, einschließlich Konfiguration, Zustand und Metadaten. Wenn etcd ausfällt, verliert Ihr Cluster sein Gedächtnis und kann nicht mehr ordnungsgemäß funktionieren!

Der Scheduler überwacht neu erstellte Pods (Ihre Anwendungsinstanzen), denen noch kein Worker-Knoten zugewiesen wurde.

Anschließend wählt er für jeden Pod den am besten geeigneten Knoten aus. Dabei berücksichtigt er Faktoren wie Ressourcenanforderungen, Hardwarebeschränkungen und Richtlinien.

Der Controller Manager führt verschiedene Controller aus. Dabei handelt es sich um Hintergrundschleifen, die den Zustand des Clusters regeln.

Beispielsweise überwacht ein Node Controller den Zustand der Knoten, während ein Replication Controller sicherstellt, dass die richtige Anzahl von Pods ausgeführt wird. Er arbeitet kontinuierlich daran, den gewünschten Zustand an den aktuellen Zustand anzugleichen.

Worker-Knoten (in älteren Dokumentationen auch Minions genannt) sind die Rechner, auf denen Ihre tatsächlichen containerisierten Anwendungen (verpackt in Pods) ausgeführt werden.

Jeder Worker-Knoten verfügt über Komponenten, die ihm die Kommunikation mit der Control Plane und die Verwaltung der darauf laufenden Container ermöglichen.

Auf jedem Worker-Knoten:

• Kubelet: Ein Agent, der sicherstellt, dass Container in einem Pod ausgeführt werden. Er empfängt Anweisungen vom API-Server und verwaltet die Pods.
• Container-Runtime: Diese Software ist für die Ausführung von Containern zuständig (z. B. Docker, containerd, CRI-O). Das Kubelet verwendet sie, um Images abzurufen und Ihre Anwendungen auszuführen.

Kube-proxy wird auf jedem Worker-Knoten ausgeführt und übernimmt das Netzwerk-Proxying für Kubernetes-Services.

Er verwaltet Netzwerkregeln auf dem Knoten und ermöglicht die Netzwerkkommunikation mit Ihren Pods sowohl innerhalb als auch außerhalb des Clusters. Dadurch stellt er sicher, dass Ihre Anwendungen erreichbar sind.

Welche der folgenden Komponenten gehören zur Control Plane von Kubernetes?

Sehr gut! Sie verfügen nun über ein grundlegendes Verständnis der Kubernetes-Architektur.

• Die Control Plane (API Server, etcd, Scheduler, Controller Manager) verwaltet den Cluster.
• Worker Nodes (Kubelet, Container Runtime, Kube-proxy) führen Ihre Anwendungen aus.

Als Nächstes sehen wir uns die kleinste bereitstellbare Einheit in Kubernetes an: Pods!