Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- it-wiki:kubernetes:understanding_the_architecture [2025/04/29 10:32] – marko
+++ it-wiki:kubernetes:understanding_the_architecture [2025/04/29 10:48] (aktuell) – marko
@@ Zeile 26: / Zeile 26: @@
 In jedem Kubernetes-Cluster gibt es zwei Arten von Nodes:
-  - Einen oder mehrere **Control Plane Nodes** (auch Master Nodes genannt)
+  - Einen oder mehrere **Control Plane Nodes**
   - Einen oder mehrere **Worker Nodes**
@@ Zeile 77: / Zeile 77: @@
     * Docker
     * Mirantis Container Runtime {{ :it-wiki:kubernetes:7cd73c27-8fc2-4286-abe8-e2e45565a251.png?direct&600 |}}
-  - **Kubelet:** Genau wie die Container-Laufzeitumgebung ist das Kubelet sowohl auf den Steuerungsknoten (Control Plane) als auch auf dem Arbeitsknoten (Worker Node) vorhanden. Um ein Pod auf einem Arbeitsknoten auszuführen, braucht es eine Komponente, die mit der Steuerungsebene kommuniziert, damit das Pod gestartet werden kann. Das Kubelet ist genau diese Komponente. Das Kubelet jedes Knotens kommuniziert mit der Steuerungsebene und wartet auf den Befehl vom API-Server, ein Pod zu starten. Sobald das Kubelet eines Knotens den Befehl vom API-Server erhält, kommuniziert es über eine Plugin-basierte Schnittstelle (CRI-Shim) mit der Container-Laufzeitumgebung seines Knotens. Und damit beginnt das Pod zu laufen.
+  - **Kubelet:** Genau wie die Container-Laufzeitumgebung ist das Kubelet sowohl auf den Steuerungsknoten (Control Plane) als auch auf dem Arbeitsknoten (Worker Node) vorhanden. Um ein Pod auf einem Arbeitsknoten auszuführen, braucht es eine Komponente, die mit der Steuerungsebene kommuniziert, damit der Pod gestartet werden kann. Das Kubelet ist genau diese Komponente. Das Kubelet jedes Knotens kommuniziert mit der Steuerungsebene und wartet auf den Befehl vom API-Server, ein Pod zu starten. Sobald das Kubelet eines Knotens den Befehl vom API-Server erhält, kommuniziert es über eine Plugin-basierte Schnittstelle (CRI-Shim) mit der Container-Laufzeitumgebung seines Knotens. Und damit beginnt der Pod zu laufen.
 Falls Du jetzt ein bisschen verwirrt bist, hier ist die Zusammenfassung der internen Funktionsweise der Kubernetes-Komponenten: **Das solltest Du nicht verpassen!**
-  * Der Nutzer (also Du) sendet eine Anfrage an den API-Server, um ein Pod zu starten.
+  * Der Nutzer (also Du) sendet eine Anfrage an den API-Server, um ein Pod zu starten. \\ <code bash>kubectl run <pod-name> --image=<image-name></code>
-<code bash>kubectl run <pod-name> --image=<image-name></code>
   * Diese Anfrage wird jetzt vom API-Server validiert.
   * Der API-Server leitet diese Anfrage an den Scheduler auf der Steuerungsebene (Control Plane) weiter.
   * Im Gegenzug fordert der Scheduler clusterbezogene Informationen vom API-Server an, da der API-Server die einzige Komponente ist, die mit dem etcd-Store interagieren kann.
   * Nachdem der API-Server diese Anfrage vom Scheduler erhalten hat, liest er die Daten aus dem etcd-Store und stellt sie dem Scheduler zur Verfügung.
-  * Der Scheduler weist daraufhin auf Grundlage der erhaltenen Informationen einem Node ein Pod zu und teilt diese Entscheidung dem API-Server mit. \\ „Hey API-Server, das Pod soll auf node-01 laufen.“ \\ – Scheduler
+  * Der Scheduler weist daraufhin auf Grundlage der erhaltenen Informationen einem Node ein Pod zu und teilt diese Entscheidung dem API-Server mit. \\ „Hey API-Server, der Pod soll auf node-01 laufen.“ \\ – Scheduler
-  * Der API-Server weist dem Kubelet des entsprechenden Nodes die Aufgabe zu, das Pod zu starten.
+  * Der API-Server weist dem Kubelet des entsprechenden Nodes die Aufgabe zu, der Pod zu starten.
-  * Nachdem der Kubelet des Nodes die Anweisung vom API-Server erhalten hat, interagiert er über den CRI-Shim mit der Container Runtime – und jetzt läuft das Pod auf einem bestimmten Node.
+  * Nachdem der Kubelet des Nodes die Anweisung vom API-Server erhalten hat, interagiert er über den CRI-Shim mit der Container Runtime – und jetzt läuft der Pod auf einem bestimmten Node.
-  * Während das Pod läuft, überprüft der Controllermanager, ob der gewünschte Zustand des Clusters dem tatsächlichen Zustand des Kubernetes-Clusters entspricht.
+  * Während der Pod läuft, überprüft der Controllermanager, ob der gewünschte Zustand des Clusters dem tatsächlichen Zustand des Kubernetes-Clusters entspricht.
 {{ :it-wiki:kubernetes:aa7ba8d4-9803-404f-8a77-3112f03fba25.png?direct&600 |}}
+Klar! Hier ist die Übersetzung auf Deutsch in der Du-Form:
+Jetzt fragst du dich vielleicht: Was ist die Aufgabe von kube-proxy und Add-ons?
+**Kube-proxy** (läuft auf jedem Node) ist für die Netzwerkregeln im Cluster verantwortlich. Zum Beispiel:
+  * Kommunikation zwischen Containern innerhalb eines Pods
+  * Kommunikation zwischen Pods auf demselben Node und zwischen verschiedenen Nodes im Cluster
+  * Kommunikation zwischen Pods und Services im selben Namespace sowie über verschiedene Namespaces hinweg
+  * Externe-zu-Service-Kommunikation, damit Clients auf Anwendungen im Cluster zugreifen können
+**Add-ons** sind Cluster-Funktionserweiterungen, die durch Drittanbieter-Pods und -Services implementiert werden. Zum Beispiel ist das Dashboard eine benutzerfreundliche Web-Oberfläche zur Clusterverwaltung.
+Zum Schluss: Schau dir die Pfeile im obersten Bild an und sag mir, ob du verstanden hast, worauf sie sich beziehen.
+Wenn du bis hierhin gelesen hast – Herzlichen Glückwunsch!