Kubernetes Pod
Kubernetes-Pods sind die kleinsten bereitstellbaren Computing-Einheiten in Kubernetes, einer Containerplanungs- und Orchestrierungsplattform, die als Open Source verfügbar ist.
Ein Pod ist eine Gruppierung von einem oder mehreren Containern, die zusammenarbeiten. Pods befinden sich auf Knoten, die sie sich miteinander teilen können. Die Container in den Pod nutzen Netzwerk- und Speicherressourcen auf diesem Knoten gemeinsam und haben die gleichen Spezifikationen für ihre Ausführung. Der Name Pod lehnt sich an den gleichnamigen Pflanzenteil an – nämlich eine Schote, in der die Container sitzen wie Erbsen. Pods können also eine Reihe von Containern enthalten, in der Praxis ist es aber meistens nur einer – oder einige wenige, die eng zusammenarbeiten.
IT-Teams planen und platzieren die Inhalte eines Pods gemeinsam, wodurch ein anwendungsspezifischer logischer Host entsteht. Ein Kubernetes-Benutzer sollte eng zusammenarbeitende Anwendungscontainer in einem gemeinsamen Pod hosten, wenn diese Anwendungen oder Dienste ohne Container auf derselben virtuellen oder physischen Maschine laufen würden.
er gemeinsame Kontext eines Pods wird durch entkoppelte Facetten festgelegt, wie zum Beispiel Linux-Namespaces oder Cgroups.
Der Operator kann mit von Umgebungsvariablen Informationen über den Pod, den Knoten oder die Container bereitstellen. Pod-Umgebungsvariablen teilen der Anwendung in den Containern mit, wo die benötigten Ressourcen zu finden sind oder wie eine Komponente konfiguriert zu konfigurieren ist. Diese Informationen werden zur Laufzeit in den Container eingefügt. Nodes enthalten zwar auch Umgebungsvariablen, diese sind jedoch nicht für die Container verfügbar. Nutzer definieren oder schreiben Kubernetes-Umgebungsvariablen statisch.
Verwaltung von Kubernetes-Pod
Kubernetes unterstützt die Docker-Container-Laufzeit sowie CoreOS rkt und CRI-O – letzteres steht für Kubelet Container Runtime Interface mit Laufzeiten konform zur Open Container Initiative.
Benutzer können zwar manuell Pods erstellen, aber häufiger erstellt der Kubernetes Controller Pods und Replikate davon automatisiert für Hochverfügbarkeit oder horizontale Skalierung. Wenn der Nutzer beispielsweise drei neue Instanzen eines Pods anfordert, erstellt Kubernetes drei Pods als Ressourcen auf API-Ebene. Der Scheduler findet den passenden Node für jeden Pod basierend auf den Richtlinien des Kubernetes-Benutzers und platziert den Pod dort.
Container innerhalb eines Pods haben eine gemeinsame IP-Adresse und einen gemeinsamen Portbereich. Sie können einander über localhost finden. Anwendungen, die demselben Pod zugewiesen sind, greifen auf freigegebene Volumes zu, die mit dem Pod verbunden sind.
Durch Pods gibt es außerdem mehr Möglichkeit für die Kommunikation zwischen Containern, wie POSIX Shared Memory oder SystemV-Semaphoren. Die Container in einem Pod haben andere IP-Adressen als die Container in einem anderen und können das IPC-Protokoll nicht verwenden, um Nachrichten auszutauschen. Die Kubernetes-Pod-zu-Pod-Kommunikation wird über zusätzliche Dienste geleitet. Wenn sich beispielsweise ein Frontend einer Anwendung in einem Pod auf einem Node befindet, kann sich das Backend auf demselben Node auf einem anderen Node in zehn Instanzen befinden, die über verschiedene Nodes verteilt sind, der Frontend-Pod verbindet sich dann einfach mit einem Dienst, der den oder die Backend-Pods darstellt.
Wie Pods verwendet werden
In Kubernetes sind Pods und die in ihnen befindlichen Anwendungscontainer im Allgemeinen kurzlebig. Benutzer entwerfen einen Pod, weisen ihm eine eindeutige Identifizierung und Ressourcenanforderungen zu und erlauben es dem System, ihn auf einen geeigneten Knoten zu platzieren, vielleicht mit Vorgaben rund um die Dienstqualität. Der Pod verwendet diesen Knoten, bis die Sitzung beendet oder der Pod gelöscht wird.
Fahren Anwender einen Knoten herunter, löscht das System die Pods nach einem bestimmten Zeitraum automatisch. Parallel dazu werden Pods, die auf einen anderen Knoten wandern sollen, nicht verschoben, sondern gelöscht und eine Kopie auf dem neuen Knoten neu gestartet. Der Benutzer kann denselben Namen und dieselbe ID für den neuen Pod wiederverwenden.
