Pod

Auf dieser Seite werden Pod-Objekte von Kubernetes und deren Verwendung in Google Kubernetes Engine beschrieben.

Konzept des Pods

Pods sind die kleinsten, grundlegendsten bereitstellbaren Objekte in Kubernetes. Ein Pod stellt eine einzelne Instanz eines laufenden Prozesses in Ihrem Cluster dar.

Pods enthalten einen oder mehrere Container, z. B. Docker-Container. Wenn ein Pod mehrere Container ausführt, werden die Container als eine Einheit verwaltet und teilen die Ressourcen des Pods. Im Allgemeinen ist das Ausführen mehrerer Container in einem einzelnen Pod ein erweiterter Anwendungsfall.

Pods enthalten außerdem freigegebene Netzwerk- und Speicherressourcen für ihre Container:

  • Netzwerk: Pods erhalten automatisch eine einmalige IP-Adresse. Pod-Container verwenden denselben Netzwerk-Namespace, einschließlich IP-Adresse und Netzwerkports. Container in einem Pod kommunizieren innerhalb des Pods über localhost.
  • Speicher: Pods können eine Gruppe von freigegebenen Speicher-Volumes festlegen, die von den Containern gemeinsam genutzt werden können.

Sie können sich einen Pod als einen eigenständigen, isolierten "logischen Host" vorstellen, der die systemischen Anforderungen der Anwendung enthält, die er beliefert.

Ein Pod soll eine einzelne Instanz Ihrer Anwendung auf Ihrem Cluster ausführen. Es wird jedoch nicht empfohlen, einzelne Pods direkt zu erstellen. Stattdessen erstellen Sie in der Regel ein Set identischer Pods, Replikate genannt, um Ihre Anwendung auszuführen. Ein solches Set replizierter Pods wird von einem Controller, z. B. einer Bereitstellung, erstellt und verwaltet. Controller verwalten den Lebenszyklus ihrer Pods und können auch eine horizontale Skalierung durchführen und die Anzahl der Pods nach Bedarf ändern.

Obwohl Sie gelegentlich direkt mit Pods interagieren, um Fehler zu beheben, Probleme zu lösen oder sie zu überprüfen, wird dringend empfohlen, dass Sie einen Controller zum Verwalten Ihrer Pods verwenden.

Pods werden in Ihrem Cluster auf Knoten ausgeführt. Wenn ein Pod einmal erstellt wurde, bleibt er auf seinem Knoten bis sein Prozess abgeschlossen ist. Dann wird der Pod gelöscht und aus dem Knoten entfernt, damit kein Ressourcenmangel auftritt oder der Knoten ausfällt. Wenn ein Knoten ausfällt, werden die Pods auf dem Knoten automatisch zum Löschen eingeplant.

Lebenszyklus eines Pods

Pods sind sitzungsspezifisch. Sie sind nicht dafür ausgelegt, für immer zu laufen. Wenn ein Pod beendet wird, kann er nicht zurückgeholt werden. Pods werden jedoch im Allgemeinen erst ausgeblendet, wenn sie durch einen Nutzer oder Controller gelöscht wurden.

Pods können sich nicht selbst "heilen" oder reparieren. Wenn beispielsweise ein Pod auf einem Knoten geplant ist, der später ausfällt, wird der Pod gelöscht. Wenn ein Pod aus irgendeinem Grund aus einem Knoten entfernt wurde, kann sich der Pod nicht selbst ersetzen.

Jeder Pod verfügt über ein API-Objekt PodStatus, das durch das Feld status eines Pods dargestellt wird. Pods veröffentlichen ihre Phase im Feld status: phase. Jede Phase ist eine ausführliche Zusammenfassung des Pods in seinem aktuellen Zustand.

Wenn Sie mit kubectl get pod einen Pod überprüfen, der in Ihrem Cluster ausgeführt wird, kann er sich in einer der folgenden Phasen befinden:

  • Ausstehend: Pod wurde vom Cluster erstellt und akzeptiert, aber einer oder mehrere seiner Container werden noch nicht ausgeführt. Diese Phase umfasst die Zeit, die für die Planung auf einem Knoten und das Herunterladen von Bildern aufgewendet wurde.
  • Wird ausgeführt: Pod wurde an einen Knoten gebunden und alle Container wurden erstellt. Mindestens ein Container wird ausgeführt, gerade gestartet oder neu gestartet.
  • Erfolgreich: Alle Container im Pod wurden erfolgreich beendet. Beendete Pods werden nicht neu gestartet.
  • Fehler: Alle Container im Pod wurden beendet und mindestens ein Container ist fehlerhaft beendet worden. Ein Container schlägt fehl, wenn er mit einem anderen Status als Null beendet wird.
  • Unbekannt: Der Status des Pods kann nicht bestimmt werden.

Zusätzlich enthält PodStatus ein Array mit dem Namen PodConditions, der im Pod-Manifest als conditions dargestellt wird. Das Feld enthält die Felder type und status. conditions gibt die Bedingungen innerhalb des Pods, die seinen aktuellen Status verursachen, etwas genauer an.

Das Feld type kann PodScheduled, Ready, Initialized und Unschedulable enthalten. Das Feld status entspricht dem Feld type und kann True, False oder Unknown enthalten.

Pods erstellen

Da Pods sitzungsspezifisch sind, ist es nicht nötig, die Pods direkt zu erstellen. Ebenso ist es nicht empfohlen, Pods direkt zu erstellen, da sie sich nicht selbst reparieren oder ersetzen können.

Stattdessen sollten Sie einen Controller verwenden, z. B. eine Bereitstellung, die Pods für Sie erstellt und verwaltet. Controller sind ebenfalls nützlich für das Ausrollen von Aktualisierungen, wie beispielsweise das Ändern der Version einer Anwendung, die in einem Container ausgeführt wird, da der Controller den gesamten Aktualisierungsprozess für Sie verwaltet.

Pod-Vorlagen

Controller-Objekte wie Deployments und StatefulSets enthalten ein Pod-Vorlagenfeld. Pod-Vorlagen enthalten eine Pod-Spezifikation, die vorgibt, wie die einzelnen Pods ausgeführt werden, beispielsweise welche Container innerhalb der Pods auszuführen sind und welche Volumes die Pods bereitstellen sollen.

Controller-Objekte verwenden Pod-Vorlagen zur Erstellung von Pods und zur Verwaltung ihres "gewünschten Status" innerhalb Ihres Clusters. Wenn eine Pod-Vorlage geändert wird, verwenden alle zukünftigen Pods die neue Vorlage, bereits vorhandene Pods jedoch nicht.

Weitere Informationen zur Funktionsweise von Pod-Vorlagen finden Sie unter Deployments erstellen in der Kubernetes-Dokumentation.

Steuern, auf welchen Knoten ein Pod ausgeführt wird

Standardmäßig werden Pods auf Knoten im Standardknotenpool des Clusters ausgeführt. Sie können den Knotenpool, den ein Pod auswählt, explizit oder implizit konfigurieren:

  • Sie können einen Pod explizit dazu anweisen, einen bestimmten Knotenpool bereitzustellen, indem Sie im Pod-Manifest einen nodeSelector festlegen. Dadurch kann der Pod nur auf Knoten in diesem Knotenpool ausgeführt werden.

  • Sie können Ressourcenanforderungen für die Container angeben, die von einem Pod ausgeführt werden. Der Pod kann nur auf Knoten ausgeführt werden, die den Ressourcenanforderungen entsprechen. Wenn die Pod-Definition etwa einen Container enthält, für den vier CPUs erforderlich sind, wählt der Dienst keine Pods aus, die auf Knoten mit zwei CPUs ausgeführt werden.

Nutzungsmuster eines Pods

Pods können auf zwei Arten verwendet werden:

  • Pods, die einen einzelnen Container ausführen. Das einfachste und gebräuchlichste Pod-Muster ist ein einzelner Container pro Pod, wobei der einzelne Container eine gesamte Anwendung darstellt. In diesem Fall können Sie sich einen Pod als Wrapper vorstellen.
  • Pods, die mehrere Container ausführen, müssen zusammenarbeiten. Pods mit mehreren Containern werden hauptsächlich zur Unterstützung von gemeinsam lokalisierten, gemeinsam verwalteten Programmen verwendet, die Ressourcen gemeinsam nutzen. Diese gemeinsam lokalisierten Container bilden eine einzelne zusammenhängende Diensteinheit. Ein Container verarbeitet beispielsweise Dateien eines gemeinsam genutzten Volumes, während ein anderer Container diese Dateien aktualisiert. Der Pod umschließt diese Container und Speicherressourcen als eine einzige gemeinsam verwaltbare Einheit.

Jeder Pod sollte eine einzelne Instanz einer bestimmten Anwendung ausführen. Wenn Sie mehrere Instanzen ausführen möchten, sollten Sie für jede Instanz der Anwendung einen eigenen Pod verwenden. Dies wird im Allgemeinen als Replikation bezeichnet. Replizierte Pods werden von einem Controller, z. B. einer Bereitstellung, als Gruppe erstellt und verwaltet.

Beendigung eines Pods

Pods werden ordnungsgemäß beendet, wenn ihre Prozesse abgeschlossen sind. Standardmäßig wird ein Pod dann innerhalb von 30 Sekunden beendet.

Mit dem Befehl kubectl delete können Sie einen Pod manuell löschen. Mit dem Flag --grace-period des Befehls lässt sich der standardmäßige Kulanzzeitraum überschreiben.

Weitere Informationen

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

Dokumentation zu Kubernetes Engine