Pod

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

Was ist ein Pod?

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 miteinander.
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 solcher Satz replizierter Pods wird von einem Controller (z. B. einem Deployment) erstellt und verwaltet. Controller verwalten den Lebenszyklus ihrer Pods und können auch eine horizontale Skalierung durchführen und dabei 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. Nachdem ein Pod erstellt wurde, verbleibt er auf dem jeweiligen Knoten, bis der zugehörige Prozess abgeschlossen ist. Dann wird der Pod gelöscht und vom 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 hat das 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.

Mit kubectl get pod können Sie auf Ihrem Cluster ausgeführte Pods prüfen. Ein Pod kann 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 Images 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.

Darüber hinaus enthält PodStatus ein Array namens PodConditions, das im Pod-Manifest als conditions dargestellt wird. Das Feld hat die Felder type und status. Mit conditions werden die Bedingungen innerhalb des Pods, die den aktuellen Status verursachen, genauer angegeben.

Das Feld type kann die Felder 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. ein Deployment, das Pods für Sie erstellt und verwaltet. Controller sind ebenfalls nützlich für die Durchführung 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-Anfragen

Mit der Ausführung eines Pods werden CPU- und Speicherkapazität angefordert. Dadurch kann Kubernetes den Pod auf einem geeigneten Knoten planen, um die Arbeitslast auszuführen. Ein Pod wird nur auf einem Knoten geplant, der genügend Ressourcen hat, um die Anfrage des Pods anzunehmen. Eine Anforderung ist die minimale CPU- oder Speicherkapazität, die Kubernetes einem Pod garantiert.

Sie können die CPU- und Speicheranforderungen für einen Pod basierend auf den Ressourcen konfigurieren, die Ihre Anwendungen benötigen. Sie können auch Anforderungen für einzelne Container angeben, die im Pod ausgeführt werden. Beachten Sie Folgendes:

Es gibt keine Standardanforderung für Arbeitsspeicher. Ein Pod ohne Standardarbeitsspeicheranforderung könnte auf einem Knoten geplant werden, der nicht über genügend Arbeitsspeicher verfügt, um die Arbeitslasten des Pods auszuführen.
Es gibt keine Standardanforderung für Arbeitsspeicher. Ein Pod ohne Standardarbeitsspeicheranforderung könnte auf einem Knoten geplant werden, der nicht über genügend Arbeitsspeicher verfügt, um die Arbeitslasten des Pods auszuführen.
Wenn Sie einen zu niedrigen Wert für CPU- oder Arbeitsspeicheranfragen festlegen, kann dies dazu führen, dass zu viele Pods oder eine nicht optimale Kombination von Pods auf einem bestimmten Knoten geplant werden, was die Leistung beeinträchtigen kann.
Wenn Sie einen zu hohen Wert für CPU- oder Arbeitsspeicheranforderungen festlegen, ist der Pod möglicherweise nicht mehr planbar, wodurch sich die Kosten für Clusterressourcen erhöhen.
Zusätzlich zum Festlegen der Ressourcen eines Pods oder auch stattdessen können Sie Anforderungen für einzelne Container angeben, die im Pod ausgeführt werden. Wenn Sie nur Ressourcen für die Container angeben, sind die Anforderungen des Pods die Summe der Anforderungen, die für die Container angegeben wurden. Wenn Sie beides angeben, darf die Summe der Anforderungen für alle Container die Pod-Anforderungen nicht überschreiten.

Es wird dringend empfohlen, Anfragen für Pods anhand der Anforderungen der tatsächlichen Arbeitslasten zu konfigurieren. Weitere Informationen finden Sie im Google Cloud-Blog unter Kubernetes best practices: Resource requests and limits.

Pod-Limits

Standardmäßig hat ein Pod keine Obergrenze für die maximale CPU- oder Speicherkapazität, die auf einem Knoten verwendet werden kann. Sie können Limits festlegen, um die CPU- oder Speicherkapazität zu steuern, die Ihr Pod auf einem Knoten verwenden kann. Ein Limit ist die maximale CPU- oder Speicherkapazität, die Kubernetes für einen Pod garantiert.

Zusätzlich zum Festlegen der Limits eines Pods oder auch stattdessen können Sie Limits für einzelne Container angeben, die im Pod ausgeführt werden. Wenn Sie nur Limits für die Container angeben, sind die Limits des Pods die Summe der Limits, die für die Container angegeben wurden. Jeder Container kann jedoch nur bis zu seinem Limit auf Ressourcen zugreifen. Wenn Sie also nur Limits für Container festlegen möchten, müssen Sie Limits für jeden Container angeben. Wenn Sie beides angeben, darf die Summe der Limits für alle Container das Pod-Limit nicht überschreiten.

Limits werden bei der Planung von Pods nicht berücksichtigt, sie können jedoch Ressourcenkonflikte zwischen Pods und auf einem Knoten verhindern. Außerdem können Sie Systeminstabilität auf dem Knoten verhindern, die dadurch verursacht wird, dass der Pod das zugrunde liegende Betriebssystem von Ressourcen an sich bindet.

Es wird dringend empfohlen, Limits für Ihre Pods basierend auf den Anforderungen der tatsächlichen Arbeitslasten zu konfigurieren. Weitere Informationen finden Sie im Google Cloud-Blog unter Kubernetes Best Practices: Resource Requests and Limits.

Pod-Vorlagen

Controller-Objekte wie Deployments und StatefulSets enthalten das Feld Pod-Vorlage. Pod-Vorlagen enthalten eine Pod-Spezifikation mit Vorgaben zur Ausführung der einzelnen Pods, 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 Ressourcenanfragen für die ausgeführten Container angeben. 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. Kubernetes legt einen standardmäßigen Beendigungszeitraum von 30 Sekunden fest. Beim Löschen eines Pods können Sie diesen Kulanzzeitraum überschreiben. Dazu stellen Sie das Flag --grace-period auf die Anzahl der Sekunden ein, die bis zur Beendigung des Pods gewartet werden soll.

Wenn Sie Cluster Autoscaler verwenden, beträgt der maximale Kulanzzeitraum für die Beendigung, der bei Herunterskalierungen berücksichtigt wird, 10 Minuten. Der maximale Kulanzzeitraum für die Beendigung während der Knotenupgrades beträgt eine Stunde.