Was sind Kubernetes Pods?

Ein Kubernetes Pod kann einen oder mehrere Container enthalten, die eng miteinander verbunden sind und Ressourcen teilen. Sie dienen somit als eine koordinierte Umgebung für Anwendungen.

Kubernetes Pod

Pods sind die grundlegenden Bereitstellungseinheiten in Kubernetes, die einen oder mehrere miteinander verbundene Container umfassen. Ein Pod teilt sich denselben Netzwerkraum, Speicher und andere Ressourcen und stellt somit eine logische Gruppierung von Containern dar. Die Container innerhalb eines Kubernetes Pods arbeiten eng zusammen und können miteinander kommunizieren.

Ein-Container-Pod-Modell

Ein Ein-Container-Pod enthält nur einen einzelnen Container. Diese Struktur wird oft verwendet, wenn eine Anwendung oder ein Mikroservice in einem isolierten Umfeld laufen soll, ohne die Notwendigkeit, Ressourcen und Netzwerk mit anderen Containern zu teilen. Ein solcher Pod ist die einfachste Form in Kubernetes und bietet dennoch die Vorteile der Orchestrierung, Skalierung und Verwaltung.

Pods mit mehreren Containern

Pods, die mehrere Container ausführen, beherbergen mehr als einen Container innerhalb desselben Pods. Diese Container arbeiten gemeinsam und teilen sich denselben Netzwerkraum und die gleichen Ressourcen. Es wird häufig genutzt, wenn Container eng miteinander verbunden sind und eine gemeinsame Aufgabe oder Funktion erfüllen. Zum Beispiel könnten ein Hauptanwendungscontainer und ein Sidecar-Container für Logging oder Überwachung in einem Kubernetes Pod ausgeführt werden. Dies ermöglicht eine engere Koordination und Kommunikation zwischen den Containern, während sie dennoch als eine einzige Einheit innerhalb des Kubernetes-Clusters behandelt werden.

Kubernetes Pod erstellen

Um einen Kubernetes Pod erstellen zu können, benötigen Sie eine YAML-Datei, die die Pod-Spezifikation beschreibt. Hier ist ein einfaches Beispiel für einen Nginx-Pod:

apiVersion: v1
kind: Pod
metadata:
    name: nginx-pod
spec:
    containers:
    - name: nginx-container
        image: nginx:latest

Dieses YAML-Dokument definiert einen Pod mit dem Namen nginx-pod, der einen einzelnen Container mit dem Namen nginx-container enthält. Der Container verwendet das neueste Nginx-Image aus dem Docker Hub.

Geben Sie folgenden Befehl zum Erstellen des Pods ein:

kubectl apply -f nginx-pod.yaml

Verwendung von Kubernetes Pods

Der Einsatz von höheren Abstraktionsebenen wie Deployments oder StatefulSets** ist empfohlen, um Pods in einer produktiven Umgebung zu verwalten. Diese Controller übernehmen die Definition des gewünschten Zustands der Anwendung und stellen sicher, dass dieser mit dem tatsächlichen Zustand übereinstimmt. Dabei werden Skalierung, schrittweise Aktualisierung und automatische Wiederherstellung der Pods implementiert.

Bei der Erstellung eines Pods, ob direkt durch den Administrator oder indirekt durch einen Controller, wird der neue Pod auf einem spezifischen Node im Cluster geplant. Der Pod verbleibt auf diesem zugewiesenen Node, bis einer der folgenden Fälle eintritt: Er beendet seine Ausführung, das zugehörige Pod-Objekt wird manuell gelöscht, Ressourcenmangel oder andere Probleme erfordern eine Evakuierung des Pods auf einen anderen Node, oder der aktuelle Node fällt aus. In diesem Fall wird der Pod auf einem anderen verfügbaren Node neu gestartet, um die kontinuierliche Ausführung zu garantieren.

Der Name eines Pods muss als ein gültiger DNS-Subdomain-Wert festgelegt werden. Dies ist wichtig, damit der Pod innerhalb des Kubernetes-Clusters eindeutig identifizierbar ist. DNS-Label sollten kürzer als 253 Zeichen sein, dürfen nur alphanumerische Zeichen und Bindestriche enthalten und müssen mit einem alphanumerischen Zeichen beginnen und enden.

Pod OS

Kubernetes Pods werden normalerweise so konfiguriert, dass sie auf einem Linux-Betriebssystem laufen. Allerdings gibt es Fälle, in denen Sie einen Pod auf einem Windows-Betriebssystem ausführen möchten, zum Beispiel, wenn Ihre Anwendung oder ein bestimmter Teil davon Windows-spezifische Funktionen erfordert. Sie können das Betriebssystem im .spec.os.name-Feld der Pod-Spezifikation (YAML-Datei) ändern.

Pod Management

Während es möglich ist, Pods manuell zu erstellen, ist es aufgrund der wachsenden Komplexität von Anwendungen und Arbeitslasten oft nicht praktisch. Kubernetes-Controller bieten eine abstrakte Ebene, die auf einer deklarativen Konfiguration basiert. Es gibt verschiedene Arten von Controllern:

• Kubernetes Deployment
• Kubernetes StatefulSet
• Kubernetes DaemonSet

Deployment-Controller überwachen kontinuierlich den Zustand des Clusters. Dies ermöglicht automatisierte Aktionen wie das Skalieren, Aktualisieren und Warten von Anwendungen. ReplicaSets sorgen dafür, dass eine konstante Anzahl von identischen Pods läuft. StatefulSet-Controller sind essenziell für datenintensive Anwendungen, da sie stabile Netzwerkidentitäten für Pods gewährleisten.

Pod Templates

Ein Pod Template ist ein Teil der Konfiguration eines Controllers, der die gewünschten Eigenschaften eines Kubernetes Pods beschreibt. Dazu zählen Container, das Docker-Image, Umgebungsvariablen, Ressourcenanforderungen und mehr. Der Controller verwendet das Pod Template, um Pods aufzusetzen oder zu aktualisieren. Bei einem Deployment erstellt es beispielsweise neue Pods, wenn Skalierung erforderlich ist, oder aktualisiert vorhandene Pods während eines Rolling Updates.

apiVersion: batch/v1
kind: Job
metadata:
    name: new-job
spec:
    template:
        metadata:
            name: pod
        spec:
            containers:
            - name: container
                image: ubuntu:latest
                command: ["echo", "Hello from Kubernetes"]
    backoffLimit: 3

In diesem Beispiel konfigurieren wir einen Job mit dem Namen new-job. Das Pod Template erstellt einen einzelnen Pod mit einem Container, der das Ubuntu-Image nutzt und den Befehl echo "Hello from Kubernetes" ausführt. Der Job wird durch das gesetzte backoffLimit höchstens drei Wiederholungsversuche haben, falls ein Fehler auftritt.

Kubernetes Pods aktualisieren

In Kubernetes gibt es verschiedene Methoden, um Ressourcen zu aktualisieren, darunter die beiden häufig verwendeten Methoden patch und replace.

Die Patch-Methode dient dazu, gezielte und partielle Aktualisierungen an einer Ressource vorzunehmen, ohne die gesamte Ressourcendefinition zu ersetzen. Dies geschieht durch Bereitstellung eines Patches, der nur die zu ändernden Felder enthält. Dadurch können spezifische Teile einer Ressource aktualisiert werden, während andere unverändert bleiben. Diese Methode bietet eine effiziente Möglichkeit, minimale Änderungen an einer Ressource vorzunehmen, insbesondere wenn nur bestimmte Felder aktualisiert werden müssen.

Die Replace-Methode hingegen ersetzt alle Felder der Ressource durch die entsprechenden Felder in der neuen Definition. Die Replace-Methode wird eingesetzt, wenn eine umfassende Aktualisierung erforderlich ist oder grundlegende Strukturänderungen an der Ressource vorgenommen werden.

Einige Metadaten und Felder in YAML-Definitionen von Kubernetes-Ressourcen sind unveränderlich. Hierzu gehören:

• apiVersion und kind: Diese Metadaten definieren den Typ und die Version der Ressource und sollten normalerweise nicht geändert werden.
• metadata.name und metadata.namespace: Der Name und der Namespace einer Ressource sind in der Regel unveränderlich, um die eindeutige Identifikation der Ressource sicherzustellen.
• metadata.creationTimestamp: Das Erstellungsdatum einer Ressource ist unveränderlich und gibt an, wann die Ressource erstellt wurde.

Ressourcen teilen

Pods können Volumes verwenden, um Daten zwischen Containern innerhalb desselben Pods zu teilen. Ein Volume ist ein Dateisystem oder ein Verzeichnis, das von einem oder mehreren Containern im Pod gemeinsam genutzt wird. Volumes sind effektive Mechanismen zum Speichern von Daten, die über den Lebenszyklus eines einzelnen Containers hinausgehen.

Jeder Kubernetes Pod hat eine eigene IP-Adresse, die innerhalb des Cluster-Netzwerks eindeutig ist. Diese IP-Adresse ermöglicht die direkte Kommunikation zwischen den Pods. Wenn mehrere Container in einem Pod laufen, können sie über localhost und verschiedene Ports miteinander kommunizieren. Dies vereinfacht die Interaktion zwischen den verschiedenen Teilen einer Anwendung im selben Pod.

Privileged Modus

Wenn ein Container im Privileged-Modus ausgeführt wird, hat er erhöhte Rechte und kann auf Systemressourcen zugreifen, die normalerweise in einem standardmäßig isolierten Container nicht verfügbar sind. In Kubernetes wird der Privileged-Modus durch das Setzen der Option securityContext.privileged in den Container-Spezifikationen aktiviert.

Es ist wichtig zu beachten, dass der Einsatz des Privileged-Modus mit erheblichen Sicherheitsrisiken verbunden ist. Durch die erweiterten Befugnisse könnte ein kompromittierter Container oder eine bösartige Anwendung auf dem Host-System schwerwiegende Sicherheitsprobleme verursachen. Daher sollte der Privileged-Modus nur dann genutzt werden, wenn es erforderlich ist und Sie die potenziellen Sicherheitsrisiken sorgfältig abgewogen haben.

Static Pods

Static Pods in Kubernetes sind Pods, die nicht von der zentralen Steuerungsebene des Clusters überwacht oder verwaltet werden. Im Gegensatz zu regulären Pods, die von Kubernetes-Controllern abhängen, werden Static Pods direkt von einem Node initiiert. Diese Pods sind an einen spezifischen Node gebunden und ihre Definitionen werden auf dem Node selbst platziert, üblicherweise in einem Verzeichnis wie /etc/kubernetes/manifests/. Kubelet auf dem Node überwacht und startet den Static Pod, wobei es automatisch Neustarts durchführt, wenn der Pod abstürzt.

Im Unterschied zu regulären Pods werden Static Pods nicht durch die Kubernetes API kontrolliert und sind für die zentrale Steuerungsebene des Clusters unsichtbar. Static Pods sind eine einfache Methode, Anwendungen oder Dienste auf einem Node ohne ein zentrales Kubernetes-Cluster bereitzustellen. Allerdings haben sie nicht alle Funktionen von regulären Pods, die durch den Kubernetes-Controller-Manager verwaltet werden.

Container Probes

Container Probes sind Mechanismen in Kubernetes, die den Zustand und die Gesundheit eines Containers überwachen.

Um eine Diagnose durchzuführen, kann das Kubelet verschiedene Aktionen auslösen:

• ExecAction (ausgeführt mithilfe der Container-Laufzeitumgebung): Diese Aktion ermöglicht es Kubelet, einen Befehl innerhalb des Containers auszuführen. Dies ist besonders nützlich, um benutzerdefinierte Überprüfungen oder Tests innerhalb des Containers durchzuführen. Wenn der Befehl aufgerufen wurde, wird die Probe als erfolgreich betrachtet.
• TCPSocketAction (direkt vom Kubelet überprüft): Diese Aktion erlaubt dem Kubelet das Überprüfen der Erreichbarkeit eines bestimmten TCP-Ports innerhalb des Containers. Wenn der angegebene Port geöffnet ist, gilt die Probe als erfolgreich.
• HTTPGetAction (direkt vom Kubelet überprüft): Bei dieser Aktion führt das Kubelet eine HTTP-GET-Anfrage an einen bestimmten Pfad und Port innerhalb des Containers durch. Diese Aktion wird häufig für HTTP-Endpunkte genutzt, um sicherzustellen, dass eine Anwendung ordnungsgemäß auf Anfragen antwortet. Wenn die Anfrage einen Statuscode 2xx auslöst, wird die Probe als erfolgreich erachtet.