Was sind Ku­ber­netes Pods?

Ein Ku­ber­netes Pod kann einen oder mehrere Container enthalten, die eng mit­ein­an­der verbunden sind und Res­sour­cen teilen. Sie dienen somit als eine ko­or­di­nier­te Umgebung für An­wen­dun­gen.

Ku­ber­netes Pod

Pods sind die grund­le­gen­den Be­reit­stel­lungs­ein­hei­ten in Ku­ber­netes, die einen oder mehrere mit­ein­an­der ver­bun­de­ne Container umfassen. Ein Pod teilt sich denselben Netz­werk­raum, Speicher und andere Res­sour­cen und stellt somit eine logische Grup­pie­rung von Con­tai­nern dar. Die Container innerhalb eines Ku­ber­netes Pods arbeiten eng zusammen und können mit­ein­an­der kom­mu­ni­zie­ren.

Ein-Container-Pod-Modell

Ein Ein-Container-Pod enthält nur einen einzelnen Container. Diese Struktur wird oft verwendet, wenn eine Anwendung oder ein Mi­kro­ser­vice in einem iso­lier­ten Umfeld laufen soll, ohne die Not­wen­dig­keit, Res­sour­cen und Netzwerk mit anderen Con­tai­nern zu teilen. Ein solcher Pod ist die ein­fachs­te Form in Ku­ber­netes und bietet dennoch die Vorteile der Or­ches­trie­rung, Ska­lie­rung und Ver­wal­tung.

Pods mit mehreren Con­tai­nern

Pods, die mehrere Container ausführen, be­her­ber­gen mehr als einen Container innerhalb desselben Pods. Diese Container arbeiten gemeinsam und teilen sich denselben Netz­werk­raum und die gleichen Res­sour­cen. Es wird häufig genutzt, wenn Container eng mit­ein­an­der verbunden sind und eine ge­mein­sa­me Aufgabe oder Funktion erfüllen. Zum Beispiel könnten ein Haupt­an­wen­dungs­con­tai­ner und ein Sidecar-Container für Logging oder Über­wa­chung in einem Ku­ber­netes Pod aus­ge­führt werden. Dies er­mög­licht eine engere Ko­or­di­na­ti­on und Kom­mu­ni­ka­ti­on zwischen den Con­tai­nern, während sie dennoch als eine einzige Einheit innerhalb des Ku­ber­netes-Clusters behandelt werden.

Ku­ber­netes Pod erstellen

Um einen Ku­ber­netes Pod erstellen zu können, benötigen Sie eine YAML-Datei, die die Pod-Spe­zi­fi­ka­ti­on be­schreibt. 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

Ver­wen­dung von Ku­ber­netes Pods

Der Einsatz von höheren Abs­trak­ti­ons­ebe­nen wie De­ploy­ments oder Sta­teful­Sets** ist empfohlen, um Pods in einer pro­duk­ti­ven Umgebung zu verwalten. Diese Con­trol­ler über­neh­men die De­fi­ni­ti­on des ge­wünsch­ten Zustands der Anwendung und stellen sicher, dass dieser mit dem tat­säch­li­chen Zustand über­ein­stimmt. Dabei werden Ska­lie­rung, schritt­wei­se Ak­tua­li­sie­rung und au­to­ma­ti­sche Wie­der­her­stel­lung der Pods im­ple­men­tiert.

Bei der Er­stel­lung eines Pods, ob direkt durch den Ad­mi­nis­tra­tor oder indirekt durch einen Con­trol­ler, wird der neue Pod auf einem spe­zi­fi­schen Node im Cluster geplant. Der Pod verbleibt auf diesem zu­ge­wie­se­nen Node, bis einer der folgenden Fälle eintritt: Er beendet seine Aus­füh­rung, das zu­ge­hö­ri­ge Pod-Objekt wird manuell gelöscht, Res­sour­cen­man­gel oder andere Probleme erfordern eine Eva­ku­ie­rung des Pods auf einen anderen Node, oder der aktuelle Node fällt aus. In diesem Fall wird der Pod auf einem anderen ver­füg­ba­ren Node neu gestartet, um die kon­ti­nu­ier­li­che Aus­füh­rung zu ga­ran­tie­ren.

Der Name eines Pods muss als ein gültiger DNS-Subdomain-Wert fest­ge­legt werden. Dies ist wichtig, damit der Pod innerhalb des Ku­ber­netes-Clusters eindeutig iden­ti­fi­zier­bar ist. DNS-Label sollten kürzer als 253 Zeichen sein, dürfen nur al­pha­nu­me­ri­sche Zeichen und Bin­de­stri­che enthalten und müssen mit einem al­pha­nu­me­ri­schen Zeichen beginnen und enden.

Pod OS

Ku­ber­netes Pods werden nor­ma­ler­wei­se so kon­fi­gu­riert, dass sie auf einem Linux-Be­triebs­sys­tem laufen. Al­ler­dings gibt es Fälle, in denen Sie einen Pod auf einem Windows-Be­triebs­sys­tem ausführen möchten, zum Beispiel, wenn Ihre Anwendung oder ein be­stimm­ter Teil davon Windows-spe­zi­fi­sche Funk­tio­nen erfordert. Sie können das Be­triebs­sys­tem im .spec.os.name-Feld der Pod-Spe­zi­fi­ka­ti­on (YAML-Datei) ändern.

Pod Ma­nage­ment

Während es möglich ist, Pods manuell zu erstellen, ist es aufgrund der wach­sen­den Kom­ple­xi­tät von An­wen­dun­gen und Ar­beits­las­ten oft nicht praktisch. Ku­ber­netes-Con­trol­ler bieten eine abstrakte Ebene, die auf einer de­kla­ra­ti­ven Kon­fi­gu­ra­ti­on basiert. Es gibt ver­schie­de­ne Arten von Con­trol­lern:

• Ku­ber­netes De­ploy­ment
• Ku­ber­netes Sta­teful­Set
• Ku­ber­netes DaemonSet

De­ploy­ment-Con­trol­ler über­wa­chen kon­ti­nu­ier­lich den Zustand des Clusters. Dies er­mög­licht au­to­ma­ti­sier­te Aktionen wie das Skalieren, Ak­tua­li­sie­ren und Warten von An­wen­dun­gen. Re­pli­ca­Sets sorgen dafür, dass eine konstante Anzahl von iden­ti­schen Pods läuft. Sta­teful­Set-Con­trol­ler sind es­sen­zi­ell für da­ten­in­ten­si­ve An­wen­dun­gen, da sie stabile Netz­werk­i­den­ti­tä­ten für Pods ge­währ­leis­ten.

Pod Templates

Ein Pod Template ist ein Teil der Kon­fi­gu­ra­ti­on eines Con­trol­lers, der die ge­wünsch­ten Ei­gen­schaf­ten eines Ku­ber­netes Pods be­schreibt. Dazu zählen Container, das Docker-Image, Um­ge­bungs­va­ria­blen, Res­sour­cen­an­for­de­run­gen und mehr. Der Con­trol­ler verwendet das Pod Template, um Pods auf­zu­set­zen oder zu ak­tua­li­sie­ren. Bei einem De­ploy­ment erstellt es bei­spiels­wei­se neue Pods, wenn Ska­lie­rung er­for­der­lich ist, oder ak­tua­li­siert vor­han­de­ne 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 kon­fi­gu­rie­ren 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 Wie­der­ho­lungs­ver­su­che haben, falls ein Fehler auftritt.

Ku­ber­netes Pods ak­tua­li­sie­ren

In Ku­ber­netes gibt es ver­schie­de­ne Methoden, um Res­sour­cen zu ak­tua­li­sie­ren, darunter die beiden häufig ver­wen­de­ten Methoden patch und replace.

Die Patch-Methode dient dazu, gezielte und partielle Ak­tua­li­sie­run­gen an einer Ressource vor­zu­neh­men, ohne die gesamte Res­sour­cen­de­fi­ni­ti­on zu ersetzen. Dies geschieht durch Be­reit­stel­lung eines Patches, der nur die zu ändernden Felder enthält. Dadurch können spe­zi­fi­sche Teile einer Ressource ak­tua­li­siert werden, während andere un­ver­än­dert bleiben. Diese Methode bietet eine ef­fi­zi­en­te Mög­lich­keit, minimale Än­de­run­gen an einer Ressource vor­zu­neh­men, ins­be­son­de­re wenn nur bestimmte Felder ak­tua­li­siert werden müssen.

Die Replace-Methode hingegen ersetzt alle Felder der Ressource durch die ent­spre­chen­den Felder in der neuen De­fi­ni­ti­on. Die Replace-Methode wird ein­ge­setzt, wenn eine um­fas­sen­de Ak­tua­li­sie­rung er­for­der­lich ist oder grund­le­gen­de Struk­tur­än­de­run­gen an der Ressource vor­ge­nom­men werden.

Einige Metadaten und Felder in YAML-De­fi­ni­tio­nen von Ku­ber­netes-Res­sour­cen sind un­ver­än­der­lich. Hierzu gehören:

• apiVersion und kind: Diese Metadaten de­fi­nie­ren den Typ und die Version der Ressource und sollten nor­ma­ler­wei­se nicht geändert werden.
• metadata.name und metadata.namespace: Der Name und der Namespace einer Ressource sind in der Regel un­ver­än­der­lich, um die ein­deu­ti­ge Iden­ti­fi­ka­ti­on der Ressource si­cher­zu­stel­len.
• metadata.creationTimestamp: Das Er­stel­lungs­da­tum einer Ressource ist un­ver­än­der­lich und gibt an, wann die Ressource erstellt wurde.

Res­sour­cen teilen

Pods können Volumes verwenden, um Daten zwischen Con­tai­nern innerhalb desselben Pods zu teilen. Ein Volume ist ein Da­tei­sys­tem oder ein Ver­zeich­nis, das von einem oder mehreren Con­tai­nern im Pod gemeinsam genutzt wird. Volumes sind effektive Me­cha­nis­men zum Speichern von Daten, die über den Le­bens­zy­klus eines einzelnen Con­tai­ners hin­aus­ge­hen.

Jeder Ku­ber­netes Pod hat eine eigene IP-Adresse, die innerhalb des Cluster-Netzwerks eindeutig ist. Diese IP-Adresse er­mög­licht die direkte Kom­mu­ni­ka­ti­on zwischen den Pods. Wenn mehrere Container in einem Pod laufen, können sie über localhost und ver­schie­de­ne Ports mit­ein­an­der kom­mu­ni­zie­ren. Dies ver­ein­facht die In­ter­ak­ti­on zwischen den ver­schie­de­nen Teilen einer Anwendung im selben Pod.

Pri­vi­le­ged Modus

Wenn ein Container im Pri­vi­le­ged-Modus aus­ge­führt wird, hat er erhöhte Rechte und kann auf Sys­tem­res­sour­cen zugreifen, die nor­ma­ler­wei­se in einem stan­dard­mä­ßig iso­lier­ten Container nicht verfügbar sind. In Ku­ber­netes wird der Pri­vi­le­ged-Modus durch das Setzen der Option securityContext.privileged in den Container-Spe­zi­fi­ka­tio­nen aktiviert.

Es ist wichtig zu beachten, dass der Einsatz des Pri­vi­le­ged-Modus mit er­heb­li­chen Si­cher­heits­ri­si­ken verbunden ist. Durch die er­wei­ter­ten Be­fug­nis­se könnte ein kom­pro­mit­tier­ter Container oder eine bösartige Anwendung auf dem Host-System schwer­wie­gen­de Si­cher­heits­pro­ble­me ver­ur­sa­chen. Daher sollte der Pri­vi­le­ged-Modus nur dann genutzt werden, wenn es er­for­der­lich ist und Sie die po­ten­zi­el­len Si­cher­heits­ri­si­ken sorg­fäl­tig abgewogen haben.

Static Pods

Static Pods in Ku­ber­netes sind Pods, die nicht von der zentralen Steue­rungs­ebe­ne des Clusters überwacht oder verwaltet werden. Im Gegensatz zu regulären Pods, die von Ku­ber­netes-Con­trol­lern abhängen, werden Static Pods direkt von einem Node initiiert. Diese Pods sind an einen spe­zi­fi­schen Node gebunden und ihre De­fi­ni­tio­nen werden auf dem Node selbst platziert, üb­li­cher­wei­se in einem Ver­zeich­nis wie /etc/kubernetes/manifests/. Kubelet auf dem Node überwacht und startet den Static Pod, wobei es au­to­ma­tisch Neustarts durch­führt, wenn der Pod abstürzt.

Im Un­ter­schied zu regulären Pods werden Static Pods nicht durch die Ku­ber­netes API kon­trol­liert und sind für die zentrale Steue­rungs­ebe­ne des Clusters un­sicht­bar. Static Pods sind eine einfache Methode, An­wen­dun­gen oder Dienste auf einem Node ohne ein zentrales Ku­ber­netes-Cluster be­reit­zu­stel­len. Al­ler­dings haben sie nicht alle Funk­tio­nen von regulären Pods, die durch den Ku­ber­netes-Con­trol­ler-Manager verwaltet werden.

Container Probes

Container Probes sind Me­cha­nis­men in Ku­ber­netes, die den Zustand und die Ge­sund­heit eines Con­tai­ners über­wa­chen.

Um eine Diagnose durch­zu­füh­ren, kann das Kubelet ver­schie­de­ne Aktionen auslösen:

• Exe­cAc­tion (aus­ge­führt mithilfe der Container-Lauf­zeit­um­ge­bung): Diese Aktion er­mög­licht es Kubelet, einen Befehl innerhalb des Con­tai­ners aus­zu­füh­ren. Dies ist besonders nützlich, um be­nut­zer­de­fi­nier­te Über­prü­fun­gen oder Tests innerhalb des Con­tai­ners durch­zu­füh­ren. Wenn der Befehl auf­ge­ru­fen wurde, wird die Probe als er­folg­reich be­trach­tet.
• TCP­So­cketA­c­tion (direkt vom Kubelet überprüft): Diese Aktion erlaubt dem Kubelet das Über­prü­fen der Er­reich­bar­keit eines be­stimm­ten TCP-Ports innerhalb des Con­tai­ners. Wenn der an­ge­ge­be­ne Port geöffnet ist, gilt die Probe als er­folg­reich.
• HTTPGetA­c­tion (direkt vom Kubelet überprüft): Bei dieser Aktion führt das Kubelet eine HTTP-GET-Anfrage an einen be­stimm­ten Pfad und Port innerhalb des Con­tai­ners durch. Diese Aktion wird häufig für HTTP-Endpunkte genutzt, um si­cher­zu­stel­len, dass eine Anwendung ord­nungs­ge­mäß auf Anfragen antwortet. Wenn die Anfrage einen Sta­tus­code 2xx auslöst, wird die Probe als er­folg­reich erachtet.