Was ist ein Pod in Kubernetes?

Hinweis perev. : Dieser Artikel setzt den Materialzyklus eines technischen Redakteurs von Google fort, der an der Dokumentation für Kubernetes (Andrew Chen) arbeitet, und eines Direktors für Software-Engineering von SAP (Dominik Tornow). Ihr Ziel ist es, die Grundlagen von Kubernetes klar und deutlich zu erklären. Das letzte Mal haben wir einen Artikel über Hochverfügbarkeit übersetzt , und jetzt werden wir über ein solches Grundkonzept in Kubernetes wie pod sprechen.



Kubernetes ist eine Container-Orchestrierungs-Engine, mit der containerisierte Anwendungen auf mehreren Knoten ausgeführt werden können, die üblicherweise als Cluster bezeichnet werden. In diesen Veröffentlichungen verwenden wir einen Systemmodellierungsansatz, um das Verständnis von Kubernetes und den zugrunde liegenden Konzepten zu verbessern. Die Leser werden ermutigt, bereits ein grundlegendes Verständnis von Kubernetes zu haben.

Pods sind die Grundbausteine ​​von Kubernetes, aber selbst erfahrene Kubernetes-Benutzer können nicht immer erklären, was es ist.

Diese Veröffentlichung bietet ein prägnantes Gedankenmodell, das die charakteristischen Merkmale von Kubernetes-Pods beleuchtet. Aus Gründen dieser Kürze musste ich einige andere Funktionen von Pods weglassen, z. B. Lebendigkeits- und Bereitschaftstests , gemeinsame Nutzung von Ressourcen (einschließlich der kürzlich erschienenen gemeinsamen Nutzung von Namespaces - ca. übersetzt ) und Arbeit mit dem Netzwerk.

Definition

Ein Pod ist eine Anforderung, einen oder mehrere Container auf einem einzelnen Knoten auszuführen.

Ein Pod wird definiert, indem eine Anforderung zum Ausführen eines oder mehrerer Container auf einem einzelnen Knoten angezeigt wird. Diese Container teilen sich den Zugriff auf Ressourcen wie Speichervolumes und den Netzwerkstapel.

Im Alltag kann der Begriff "Pod" jedoch sowohl im Sinne dieser Anfrage als auch im Sinne der Sammlung von Containern verwendet werden, die als Antwort auf die Anfrage gestartet werden. Daher werden wir in der Veröffentlichung das Wort "pod" verwenden, wenn wir über die Anforderung sprechen, und für den zweiten Fall - verwenden Sie den Ausdruck "Satz von Containern".

Pods gelten als Grundbausteine ​​von Kubernetes, da alle Workloads in Kubernetes - z. B. Bereitstellungen , ReplicaSets und Jobs - als Pods ausgedrückt werden können.

Pod ist das einzige Objekt in Kubernetes, bei dem Container ausgeführt werden. Kein Pod - kein Container!


Schema 1. Bereitstellung, ReplicaSet, Pod und Container

Kubernetes Architektur

Schema 2. Pods, Scheduler und Kubelet

In dieser Abbildung werden die entsprechenden Objekte und Komponenten hervorgehoben. Pods werden als Kubernetes Pod-Objekte dargestellt und arbeiten mit ihnen:

• Scheduler
• Kubelet.

Kubernetes Objekte

Abbildung 3. Kubernetes-Objekte

Diese Abbildung zeigt die Kubernetes-Objekte, die für die Arbeit mit dem Pod verantwortlich sind:

• das eigentliche Pod- Objekt (Pod-Objekt) ;
• Bindungsobjekt
• Knotenobjekt

Pod Object legt die Anzahl der zu startenden Container und die gewünschte Neustartrichtlinie für den Fall eines Containerabsturzes fest und überwacht auch den Startstatus.

Das Bindungsobjekt bindet das Pod-Objekt an das Knotenobjekt , d.h. Weist dem Host einen Pod für den späteren Start zu.

Das Knotenobjekt repräsentiert einen Knoten in einem Kubernetes-Cluster.

Pod-Verarbeitung

Schema 4. Verarbeitung von pod'a

Wenn ein Pod von einem Benutzer oder Controller wie ReplicaSet Controller oder Job Controller erstellt wird , verarbeitet Kubernetes den Pod in zwei Schritten:

• Scheduler plant einen Pod,
• Kubelet startet den Pod.

Pod Planung

Abbildung 5. Kubernetes Scheduler-Steuerzyklus

Die Aufgabe des Schedulers in Kubernetes besteht darin, einen Pod zu planen, dh ihm einen geeigneten Knoten im Kubernetes-Cluster für den späteren Start zuzuweisen.


Verknüpfen eines Pod-Objekts mit einem Knotenobjekt

Ein Pod wird einem Knoten genau dann zugewiesen (oder an ihn gebunden), wenn es ein Bindungsobjekt gibt, das Folgendes enthält:

• Der Namespace entspricht dem Pod-Namespace.
• Der Name entspricht dem Namen der Kapsel.
• Zieltyp entspricht Node ,
• Der Name des Ziels entspricht dem Namen des Knotens.

(Abenteuerliebhaber können sich Kelsey Hightowers GitHub-Inhalt mit dem Titel "Manuelles Erstellen und Planen eines Pods" ansehen , eine Schritt-für-Schritt-Anleitung zum manuellen Erstellen eines Bindungsobjekts.)

Pod-Start

Abbildung 6. Kubelet-Regelzyklus

Kubelets Aufgabe ist es, einen Pod zu starten, was im Wesentlichen bedeutet, einen Satz Pod-Container zu starten. Der Start des Kubelet-Pods erfolgt in zwei Phasen: Initialisierung und Hauptphase.

In der Regel führt eine Reihe von Containern während der Initialisierungsphase vorbereitende Arbeiten durch, z. B. die Vorbereitung des erforderlichen Verzeichnisses und der erforderlichen Dateistruktur. Und der Satz von Containern in der Hauptphase führt bereits die „wichtigsten“ Aufgaben aus.

Obwohl dies im Alltag nicht ganz richtig ist, impliziert der Begriff „Pod“ häufig eine Reihe von Containern in der Hauptphase oder eine noch engere Bedeutung des „wichtigsten“ Containers in der Hauptphase.


Schema 7.1. Starten eines Pods, Initialisierungsphase (init) und Hauptphase (main)

Während der Initialisierung startet Kubelet die Container nacheinander gemäß den Spezifikationen des .Spec.InitContainers und in der in der Liste angegebenen Reihenfolge. Um den Pod erfolgreich zu starten und die Neustartrichtlinie zu berücksichtigen, müssen seine Init-Container gestartet und erfolgreich abgeschlossen werden.

Während der Hauptphase startet Kubelet gleichzeitig Container gemäß den Spezifikationen des .Spec.Containers . Hier müssen die Hauptcontainer für einen erfolgreichen Start des Pods und unter Berücksichtigung der Neustartrichtlinie gestartet und entweder erfolgreich abgeschlossen werden oder unbegrenzt arbeiten.


Schema 7.2. Running Pod, Details zu diesem Prozess

Im Falle eines Containerfehlers kann Kubelet den Container gemäß der Pod-Neustartrichtlinie neu starten, wenn der Container nicht mehr mit einem Exit-Code ungleich Null (0) arbeitet. Diese Richtlinie hat eine der folgenden Bedeutungen: Always , OnFailure , Never .

Die Pod-Neustartrichtlinie hat unterschiedliche Semantiken für Init-Container und Hauptcontainer: Wenn das Starten von Init-Containern zum Abschluss führen muss, werden die Hauptcontainer möglicherweise nicht beendet.


Starten Sie die Richtlinie für den Init-Container neu

Der ursprüngliche Container wird nach Abschluss seiner Arbeit nur dann neu gestartet (d. H. Es wird ein neuer Container mit derselben Spezifikation gestartet), wenn die folgenden Bedingungen erfüllt sind:

• Der Container-Exit-Code meldet einen Fehler und
• OnFailure Neustartrichtlinie von OnFailure lautet Always oder OnFailure .

Starten Sie die Richtlinie für den Hauptcontainer neu

Der Hauptcontainer wird nach Abschluss seiner Arbeit nur dann neu gestartet (d. H. Es wird ein neuer Container mit derselben Spezifikation gestartet), wenn die folgenden Bedingungen erfüllt sind:

• Neustartrichtlinie definiert als Always oder
• Die Neustartrichtlinie ist als OnFailure definiert und der Container-Exit-Code meldet einen Fehler.

Abbildung 8. Beispiel einer Zeitleiste mit einem roten Punkt als Symbol für einen Containerfehler

Die Abbildung zeigt eine mögliche Pod-Startzeitleiste mit zwei Spezifikationen für Init-Container und zwei Spezifikationen für Hauptcontainer. Außerdem wird die Erstellung (gemäß der Neustartrichtlinie) des neuen Hauptcontainers 1.2 nach einem Problem mit dem Start von Hauptcontainer 1.1 angezeigt .

Pod-Phasen

Diagramm 9. Interaktion von Kubelet mit dem Pod-Objekt und der Container-Laufzeit (Container-Laufzeit)

Kubelet erhält die Pod-Spezifikationen für .Spec.InitContainers und .Spec.Containers , startet den angegebenen Containersatz und aktualisiert die .Status.InitContainerStatuses Werte für .Status.InitContainerStatuses und .Status.ContainerStatuses .

Kubelet reduziert .Status.InitContainerStatuses und .Status.ContainerStatuses in einem Wert - .Status.Phase .

Die Pod-Phase ist eine Projektion des Zustands von Containern aus einer Reihe von Containern. Dies hängt ab von:

• Zustände und Exit-Codes von Init-Containern,
• Zustände und Ausstiegscodes der Hauptcontainer.

Schema 10. Phasen der Kapsel

Ausstehend

Ausstehende Phase

Ein Pod befindet sich genau dann in einer Wartephase, wenn:

• Keiner der Pod-Init-Container befindet sich mit einem Fehler ( Failure ) im Status " Failure .
• Alle wichtigen Pod-Container befinden sich im Waiting .

Laufen

Laufphase

Pod ist genau dann in der Arbeitsphase, wenn:

• Alle Pod-Init-Container befinden sich mit Erfolg im Status "Beendet".
• Mindestens ein Haupt-Pod-Container befindet sich im Running .
• Keiner der Haupt-Pod-Container befindet sich mit einem Failure im Status " Failure .

Erfolg

Erfolgsphase

Pod befindet sich genau dann in einer Erfolgsphase, wenn:

• Alle Pod-Init-Container befinden sich mit Erfolg im Status "Beendet".
• Alle wichtigen Pod-Container befinden sich mit Erfolg im Status "Beendet".

Fehler

Fehlerphase

Ein Pod befindet sich genau dann in einer Fehlerphase, wenn:

• Alle Pod-Container befinden sich im Status "Beendet".
• Mindestens einer der Pod-Container befindet sich mit einem Fehler ( Failure ) im Status " Failure .

Unbekannt

Zusätzlich zu den oben beschriebenen Phasen kann sich der Pod in einer unbekannten Phase befinden, was auf die Unmöglichkeit hinweist, seine aktuelle Phase zu bestimmen.

Müllabfuhr für Hülsen

Abbildung 11. Kontrollzyklus des Pod Garbage Collector

Nachdem der Pod geplant und gestartet wurde, ist ein spezieller Controller in Kubernetes - der Pod Garbage Collector Controller - für das Entfernen von Pod-Objekten aus dem Kubernetes Object Store verantwortlich .

Fazit

Pod - der Grundbaustein von Kubernetes: Pod ist definiert als die Darstellung einer Anforderung zum Starten eines oder mehrerer Container auf einem Knoten. Nachdem der Pod erstellt wurde, verarbeitet Kubernetes ihn in zwei Schritten: Zuerst plant der Scheduler den Pod und dann startet Kubelet ihn. Während seines gesamten Lebenszyklus durchläuft der Pod verschiedene Phasen und meldet dem Benutzer und dem System den Status - genauer gesagt den Status seines Containersatzes.

PS vom Übersetzer

Lesen Sie auch in unserem Blog:

• Kubernetes: Das Leben des Herdes ;
• " Wie hohe Verfügbarkeit bei Kubernetes bereitgestellt wird ";
• " Wie funktioniert der Kubernetes-Scheduler tatsächlich?" ";
• "Was passiert in Kubernetes, wenn der Kubectl-Lauf startet?" Teil 1 und Teil 2 ;
• " Unsere Erfahrung mit Kubernetes in kleinen Projekten " (Videobericht, der eine Einführung in das technische Gerät von Kubernetes enthält) .