Funktionsweise von Kubernetes

Abgeschlossen

Eine erfolgreich konfigurierte Kubernetes-Installation hängt von einem soliden Verständnis der Kubernetes-Systemarchitektur ab. Hier lernen Sie alle Komponenten kennen, aus denen eine Kubernetes-Installation besteht.

Was ist ein Computercluster?

Ein Cluster besteht aus mehreren Computern, die so konfiguriert werden, dass sie als ein einzelnes System fungieren und angezeigt werden. Die im Cluster konfigurierten Computer führen dieselben Aufgabenarten aus. Sie hosten beispielsweise alle Websites oder APIs oder führen rechenintensive Aufgaben aus.

Diese Aufgaben werden in Clustern mithilfe einer zentralen Software geplant und gesteuert. Die Computer in einem Cluster, die die Aufgaben ausführen, werden Knoten genannt. Die Computer, die die Planungssoftware ausführen, werden als Steuerungsebenen bezeichnet.

Kubernetes-Architektur

Wie bereits erwähnt ist ein Orchestrator ein System, das Apps bereitstellt und verwaltet. Sie haben auch gelernt, dass ein Cluster aus mehreren Computern besteht, die zusammenarbeiten und als ein einzelnes System gelten. Mit Kubernetes als Orchestrierungs- und Clustersoftware können Sie Ihre Apps bereitzustellen und auf Änderungen der Computeressourcenanforderungen reagieren.

Ein Kubernetes-Cluster enthält mindestens eine Hauptsteuerungsebene und mindestens einen Knoten. Die Steuerungsebenen und die Knoteninstanzen können jeweils physische Geräte, virtuelle Computer oder Instanzen in der Cloud sein. Das Standard-Hostbetriebssystem in Kubernetes ist Linux und weist Standardunterstützung für Linux-basierte Workloads auf.

Sie können auch Microsoft-Workloads mit Windows Server 2019 oder höher auf Clusterknoten ausführen. Angenommen, der Datenverarbeitungsdienst in der App für das Drohnentracking wurde als .NET 4.5-App geschrieben, die bestimmte API-Aufrufe des Windows-Betriebssystems verwendet. Dieser Dienst kann nur auf Knoten ausgeführt werden, auf denen ein Windows Server-Betriebssystem ausgeführt wird.

Sehen wir uns nun die Steuerebenen und Workerknoten sowie die darauf ausgeführte Software genauer an. Wenn Sie verstehen, welche Rolle die einzelnen Komponenten spielen und wo die Komponenten im Cluster ausgeführt werden, vereinfacht dies die Kubernetes-Installation für Sie.

Kubernetes-Steuerungsebene

Die Kubernetes-Steuerungsebene in einem Kubernetes-Cluster führt eine Reihe von Diensten aus, die die Orchestrierungsfunktion in Kubernetes verwalten.

Für Lernende ist es sinnvoll, eine einzige Steuerungsebene in der Testumgebung zu verwenden, wenn sie sich mit den Kubernetes-Funktionen vertraut machen. In Produktions- und Cloudbereitstellungen wie Azure Kubernetes Service (AKS) werden Sie jedoch feststellen, dass die bevorzugte Konfiguration eine Bereitstellung mit Hochverfügbarkeit (drei bis fünf replizierte Steuerungsebenen) ist.

Hinweis

Die Tatsache, dass eine Steuerungsebene bestimmte Software ausführt, um den Zustand des Clusters beizubehalten, schließt nicht aus, dass die Steuerungsebene auch andere Computeworkloads ausführt. Sie sollten jedoch in der Regel sicherstellen, dass die Steuerungsebene keine unwichtigen Workloads und App-Workloads von Benutzern ausführt.

Kubernetes-Knoten

Ein Knoten in einem Kubernetes-Cluster ist der Ort, an dem Computeworkloads ausgeführt werden. Jeder Knoten kommuniziert über den API-Server mit der Steuerungsebene, um ihn über Zustandsänderungen auf dem Knoten zu informieren.

Dienste, die auf einer Steuerungsebene ausgeführt werden

Kubernetes basiert auf mehreren administrativen Diensten, die auf der Steuerungsebene ausgeführt werden. Diese Dienste verwalten Aspekte wie die Kommunikation zwischen Clusterkomponenten, die Workloadplanung und die Persistenz des Clusterstatus.

Die folgenden Dienste sind Teil der Steuerungsebene in einem Kubernetes-Cluster:

• der API-Server
• der Sicherungsspeicher
• der Scheduler
• der Controller-Manager
• der Cloudcontroller-Manager

Was ist der API-Server?

Der API-Server ist wie das Front-End für die Steuerungsebene im Kubernetes-Cluster. Die gesamte Kommunikation zwischen den Komponenten in Kubernetes erfolgt über diese API.

Als Benutzer verwenden Sie z. B. eine Befehlszeilen-App mit dem Namen kubectl, mit der Sie Befehle für den API-Server des Kubernetes-Clusters ausführen können. Die Komponente, die diese API bereitstellt, heißt kube-apiserver, und Sie können mehrere Instanzen dieser Komponente bereitstellen, um die Skalierung im Cluster zu unterstützen.

Diese API macht eine RESTful-API verfügbar, mit der Sie Befehle oder YAML-basierte Konfigurationsdateien veröffentlichen können. YAML ist ein lesbarer Datenserialisierungsstandard für Programmiersprachen. Mit YAML-Dateien können Sie den beabsichtigten Zustand aller Objekte in einem Kubernetes-Cluster definieren.

Angenommen, Sie möchten die Anzahl der Instanzen Ihrer App im Cluster erhöhen. Sie definieren den neuen Status mit einer YAML-basierten Datei und senden diese Datei an den API-Server. Der API-Server überprüft die Konfiguration, speichert sie im Cluster und führt schließlich die konfigurierte Erhöhung der App-Bereitstellungen durch.

Was ist der Sicherungsspeicher?

Der Sicherungsspeicher ist ein persistenter Speicher, in dem Ihr Kubernetes-Cluster die vollständige Konfiguration speichert. Kubernetes verwendet einen hochverfügbaren, verteilten und zuverlässigen Schlüsselwertspeicher namens etcd. Dieser Schlüsselwertspeicher speichert den aktuellen Zustand sowie den gewünschten Zustand aller Objekte innerhalb des Clusters.

Gemäß der offiziellen Kubernetes-Anleitung müssen Sie in einem Kubernetes-Produktionscluster drei bis fünf replizierte Instanzen der etcd-Datenbank haben, um eine Hochverfügbarkeit zu gewährleisten.

Hinweis

etcd ist für die Datensicherung nicht verantwortlich. Es ist Ihre Aufgabe sicherzustellen, das ein effektiver Sicherungsplan konfiguriert ist, mit dem die etcd-Daten gesichert werden.

Was ist der Scheduler?

Der Scheduler ist die Komponente, die in allen Knoten für die Zuweisung von Workloads zuständig ist. Der Scheduler überwacht den Cluster auf neu erstellte Container und weist diesen Knoten zu.

Was ist der Controller-Manager?

Der Controller-Manager startet und überwacht die Controller, die für einen Cluster konfiguriert wurden, über den API-Server.

Kubernetes verwendet Controller, um den Zustand von Objekten im Cluster zu nachzuverfolgen. Jeder Controller wird in einer nicht endenden Schleife ausgeführt, während er Ereignisse im Cluster beobachtet und beantwortet. Beispielsweise gibt es Controller, die Knoten, Container, Endpunkte usw. überwachen.

Der Controller kommuniziert mit dem API-Server, um den Zustand des Objekts zu bestimmen. Wenn der aktuelle Status des Objekts vom gewünschten Status abweicht, führt der Controller Aktionen aus, um den gewünschten Status sicherzustellen.

Angenommen, einer von drei Containern, die in Ihrem Cluster ausgeführt werden, reagiert nicht mehr und fällt aus. In diesem Fall entscheidet ein Controller, ob neue Container gestartet werden müssen, um sicherzustellen, dass Ihre Apps immer verfügbar sind. Wenn im gewünschten Zustand jederzeit drei Container ausgeführt werden sollen, wird die Ausführung eines neuen Containers geplant.

Was ist der Cloudcontroller-Manager?

Der Cloudcontroller-Manager wird mit den zugrunde liegenden Cloudtechnologien in den Cluster integriert, wenn der Cluster in einer Cloudumgebung ausgeführt wird. Diese Dienste können zum Beisiel Lastenausgleiche, Warteschlangen und Speicher sein.

Auf einem Knoten ausgeführte Dienste

Es gibt mehrere Dienste, die auf einem Kubernetes-Knoten ausgeführt werden, um die Ausführung von Workloads zu steuern.

Die folgenden Dienste werden auf dem Kubernetes-Knoten ausgeführt:

• Kubelet
• Kube-Proxy
• Containerruntime

Was ist das Kubelet?

Das Kubelet ist der Agent, der auf jedem Knoten im Cluster ausgeführt wird und der die Arbeitsanforderungen vom API-Server überwacht. Er stellt sicher, dass die angeforderte Arbeitseinheit ausgeführt wird und fehlerfrei ist.

Das Kubelet überwacht außerdem die Knoten und stellt sicher, dass die auf den einzelnen Knoten geplanten Container erwartungsgemäß ausgeführt werden. Das Kubelet verwaltet nur Container, die von Kubernetes erstellt werden. Der Agent ist nicht für die Neuplanung der Arbeit auf anderen Knoten zuständig, wenn der aktuelle Knoten die Arbeit nicht ausführen kann.

Was ist der Kube-Proxy?

Die Komponente „Kube-Proxy“ ist für lokale Clusternetzwerke zuständig und wird auf jedem Knoten ausgeführt. Die Komponente stellt sicher, dass jeder Knoten über eine eindeutige IP-Adresse verfügt. Sie implementiert auch Regeln für das Routing und den Lastenausgleich des Datenverkehrs mithilfe von iptables und IPVS.

Dieser Proxy stellt selbst keine DNS-Dienste bereit. Ein DNS-Cluster-Add-On, das auf CoreDNS basiert, wird empfohlen und standardmäßig installiert.

Was ist die Containerruntime?

Die Containerruntime ist die zugrunde liegende Software, die Container in einem Kubernetes-Cluster ausführt. Die Runtime ist für das Abrufen, Starten und Beenden von Containerimages verantwortlich. Kubernetes unterstützt verschiedene Containerruntimes, darunter beispielsweise Docker, containerd, rkt, CRI-O und frakti. Die Unterstützung für viele Containerruntimetypen basiert auf der Containerruntimeschnittstelle. Die Containerruntimeschnittstelle ist ein Plug-In-Design, über das das Kubelet mit der verfügbaren Containerruntime kommunizieren kann.

Die Standardcontainerlaufzeit in AKS ist containerd, eine Branchenstandard-Containerruntime.

Interagieren mit einem Kubernetes-Cluster

Kubernetes bietet ein Befehlszeilentool mit dem Namen kubectl, mit dem Sie den Cluster verwalten können. Mit kubectl können Sie Befehle an die Steuerungsebene des Clusters senden oder Informationen zu allen Kubernetes-Objekten über den API-Server abrufen.

kubectl verwendet eine Konfigurationsdatei, die folgende Konfigurationsinformationen enthält:

• Mit der Konfiguration Cluster werden ein Clustername, Zertifikatinformationen und der Dienst-API-Endpunkt angeben, der dem Cluster zugeordnet ist. Diese Angabe ermöglicht es Ihnen, eine Verbindung von einer einzelnen Workstation zu mehreren Clustern herzustellen.
• Mit der Konfiguration User (Benutzer) werden die Benutzer und deren Berechtigungsstufen beim Zugriff auf die konfigurierten Cluster festgelegt.
• Mit der Konfiguration Context (Kontext) werden Cluster und Benutzer mit einem Anzeigenamen gruppiert. Beispielsweise können Sie Ihren Entwicklungscluster „dev-cluster“ und Ihren Produktionscluster „prod-cluster“ nennen.

Sie können kubectl konfigurieren, um eine Verbindung mit mehreren Clustern herzustellen, indem Sie den richtigen Kontext in der Befehlszeilensyntax bereitstellen.

Kubernetes-Pods

Ein Pod stellt eine einzelne Instanz einer in Kubernetes ausgeführten App dar. Die Workloads, die Sie in Kubernetes ausführen, sind Container-Apps. Anders als in einer Docker-Umgebung können Sie Container nicht direkt in Kubernetes ausführen. Sie müssen den Container erst in ein als Pod bezeichnetes Kubernetes-Objekt packen. Ein Pod ist das kleinste Objekt, das Sie in Kubernetes erstellen können.

Ein einzelner Pod kann eine Gruppe mit einem oder mehreren Containern enthalten. Allerdings enthält ein Pod in der Regel nicht mehrere Instanzen derselben App.

Ein Pod enthält Informationen über den freigegebenen Speicher und die Netzwerkkonfiguration sowie eine Angabe, wie die zugehörigen gepackten Container ausgeführt werden. Die Informationen zu den Pods, die in Ihrem Cluster ausgeführt werden, werden in Podvorlagen definiert. Podvorlagen sind YAML-codierte Dateien, die Sie wiederverwenden und in anderen Objekte verwenden, um Podbereitstellungen zu verwalten.

Angenommen, Sie möchten eine Website in einem Kubernetes-Cluster bereitstellen. Sie erstellen die Definitionsdatei des Pods, die die Containerimages und die Konfiguration der App angibt. Anschließend stellen Sie die Definitionsdatei des Pods in Kubernetes bereit.

Es ist unwahrscheinlich, dass eine Web-App nur eine Website als einzige Komponente in der Lösung aufweist. Eine Web-App verfügt in der Regel über eine Art von Datenspeicher und andere unterstützende Elemente. Kubernetes-Pods können auch mehr als einen Container enthalten.

Angenommen, Ihre Website verwendet eine Datenbank. Die Website ist im Hauptcontainer gepackt, und die Datenbank befindet sich im unterstützenden Container. Mehrere Container kommunizieren über eine Umgebung miteinander. Zu den Containern gehören Dienste für ein Hostbetriebssystem, Netzwerkstapel, Kernel-Namespace, freigegebener Speicher und Speichervolume. Der Pod ist die Sandboxumgebung, die alle diese Dienste für Ihre App bereitstellt. Der Pod ermöglicht außerdem, dass alle enthaltenen Container sich die IP-Adresse des Pods teilen.

Da Sie potenziell viele Pods erstellen können, die auf vielen Knoten ausgeführt werden, kann es schwierig sein, diese zu identifizieren. Sie können Pods mithilfe von Zeichenfolgenbezeichnungen erkennen und gruppieren, die Sie in der Poddefinition angeben.

Lebenszyklus eines Kubernetes-Pods

Kubernetes-Pods haben einen eigenen Lebenszyklus, der sich auf die Weise auswirkt, wie diese bereitgestellt, ausgeführt und aktualisiert werden. Zunächst beginnen Sie, das YAML-Manifest des Pods an den Cluster zu übermitteln. Sobald die Manifestdatei übermittelt und im Cluster persistent gespeichert wurde, definiert sie den gewünschten Status des Pods. Der Scheduler plant den Pod für einen fehlerfreien Knoten mit genügend Ressourcen zum Ausführen des Pods ein.

Die Phasen des Lebenszyklus eines Pods lauten wie folgt:

Phase	BESCHREIBUNG
Ausstehend	Der Pod akzeptiert den Cluster, aber nicht alle Container im Cluster sind eingerichtet oder bereit, ausgeführt zu werden. Der Status „Ausstehend“ gibt die Zeit an, die ein Pod auf die Planung wartet, sowie die Zeit, die für das Herunterladen von Containerimages benötigt wird.
Wird ausgeführt	Der Pod wechselt in den Status „Wird ausgeführt“, sobald alle Ressourcen in einem Pod bereit sind.
Erfolgreich	Der Pod wechselt in den Status „Erfolgreich“, wenn die beabsichtigte Aufgabe abgeschlossen und erfolgreich ausgeführt wurde.
Fehlgeschlagen	Podfehler können aus unterschiedlichen Gründen auftreten. Ein Container im Pod kann möglicherweise ausfallen, was zur Beendigung aller anderen Container führt, oder vielleicht wurde während der Vorbereitung der Podcontainer kein Image gefunden. In diesen Fällen kann der Pod in den Status „Fehlgeschlagen“ wechseln. Der Podstatus kann von einem Status „Ausstehend“ oder „Wird ausgeführt“ zu „Fehlgeschlagen“ wechseln. Bei einem bestimmten Fehler kann ein Pod also auch wieder den Status „Ausstehend“ annehmen.
Unbekannt	Wenn der Status des Pods nicht bestimmt werden kann, hat der Pod den Status „Unbekannt“.

Pods werden in einem Cluster behalten, bis ein Controller, die Steuerungsebene oder ein Benutzer diese explizit entfernt. Wenn ein Pod gelöscht wird, wird unmittelbar danach ein neuer Pod erstellt. Der neue Pod wird basierend auf dem Podmanifest als völlig neue Instanz betrachtet. Es handelt sich nicht um eine genaue Kopie, sie unterscheidet sich also vom gelöschten Pod.

Der Cluster speichert den Podstatus oder die dynamisch zugewiesene Konfiguration nicht. Die Pod-ID und die IP-Adresse werden z. B. nicht gespeichert. Dieser Aspekt ist relevant dafür, wie Sie Pods bereitstellen und Ihre Apps entwerfen. Sie können sich beispielsweise nicht auf vorab zugewiesene IP-Adressen für Ihre Pods verlassen.

Containerstatus

Beachten Sie, dass es sich bei den Phasen um eine Zusammenfassung der Position des Pods in seinem Lebenszyklus handelt. Wenn Sie Pods untersuchen, gibt es drei Status, die der Cluster zum Nachverfolgen Ihrer Container im Pod verwendet:

State	BESCHREIBUNG
Warten	Hierbei handelt es sich um den Standardstatus von Containern. Ein Container weist diesen Status auf, wenn er nicht ausgeführt oder beendet wird.
Wird ausgeführt	Der Container wird erwartungsgemäß ohne Probleme ausgeführt.
Beendet	Der Container wird nicht mehr ausgeführt. Dies liegt entweder daran, dass alle Aufgaben abgeschlossen wurden, oder daran, dass der Container aus irgendeinem Grund fehlgeschlagen ist. Beim Debuggen beider Fälle sind ein Grund und ein Exitcode verfügbar.