Über Pods
Pods sind die kleinste API-Einheit in Kubernetes. Technischer ausgedrückt: Pods sind die atomare Scheduling-Einheit in Kubernetes. Aber warum brauchen wir Pods? Um diese Frage zu beantworten, müssen wir zuerst das Wesen eines Containers verstehen: Ein Container ist im Grunde ein Prozess.
Genau. Container sind Prozesse in einem Cloud-Computing-System, und Container-Images sind im Wesentlichen die „.exe“-Installationspakete für dieses System. Kubernetes fungiert in dieser Analogie als Betriebssystem.
Prozesse und Prozessgruppen
Melden wir uns auf einer Linux-Maschine an und führen den folgenden Befehl aus:
$ pstree -g
Dieser Befehl zeigt die Baumstruktur der aktuell laufenden Prozesse im System an. Die Ausgabe könnte wie folgt aussehen:
systemd(1)-+-accounts-daemon(1984)-+-{gdbus}(1984)
| `-{gmain}(1984)
|-acpid(2044)
...
|-lxcfs(1936)-+-{lxcfs}(1936)
| `-{lxcfs}(1936)
|-mdadm(2135)
|-ntpd(2358)
|-polkitd(2128)-+-{gdbus}(2128)
| `-{gmain}(2128)
|-rsyslogd(1632)-+-{in:imklog}(1632)
| |-{in:imuxsock) S 1(1632)
| `-{rs:main Q:Reg}(1632)
|-snapd(1942)-+-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
Wie Sie sehen, laufen Prozesse in einem echten Betriebssystem nicht isoliert. Stattdessen sind sie in Prozessgruppen organisiert. Das Programm „rsyslogd“ beispielsweise ist für die Logverarbeitung unter Linux zuständig. Das Hauptprogramm von rsyslogd, „main“, und das von ihm verwendete Kernel-Logmodul „imklog“ gehören zur Prozessgruppe 1632. Diese Prozesse arbeiten zusammen, um die Aufgaben des rsyslogd-Programms zu erfüllen.
Kubernetes bildet dieses Konzept der „Prozessgruppen“ im Wesentlichen auf die Container-Technologie ab und macht es zu einem „Bürger erster Klasse“ in diesem Cloud-Computing-„Betriebssystem“. Kubernetes hat diesen Ansatz gewählt, weil die Ingenieure von Google erkannten, dass die von ihnen bereitgestellten Anwendungen oft Beziehungen aufwiesen, die denen von „Prozessen und Prozessgruppen“ ähneln. Konkret benötigten diese Anwendungen eine enge Zusammenarbeit, was ihre Bereitstellung auf derselben Maschine erforderte.
Die Verwaltung solcher Betriebsbeziehungen ohne das Konzept von „Gruppen“ wäre unglaublich schwierig. Nehmen wir rsyslogd als Beispiel. Es besteht aus drei Prozessen: einem imklog-Modul, einem imuxsock-Modul und der Hauptfunktion von rsyslogd selbst. Diese drei Prozesse müssen auf derselben Maschine laufen, da sonst ihre socketbasierte Kommunikation und ihr Dateiaustausch auf Probleme stoßen würden.
Kommunikation zwischen Containern
Wie im obigen Diagramm dargestellt, enthält dieser Pod zwei Benutzercontainer, A und B, sowie einen Infra-Container. In Kubernetes ist der Infra-Container darauf ausgelegt, möglichst wenig Ressourcen zu verbrauchen, und verwendet ein spezielles Image namens „k8s.gcr.io/pause“. Dieses Image stellt einen Container dar, der in Assemblersprache geschrieben ist und sich permanent in einem „angehaltenen“ Zustand befindet, mit einer unkomprimierten Größe von nur etwa 100–200 KB.
Sobald der Infra-Container den Network Namespace „hält“, können die Benutzercontainer diesem Namespace beitreten. Wenn Sie also die Namespace-Dateien dieser Container auf der Host-Maschine untersuchen (der Pfad zu dieser Datei wurde bereits erwähnt), zeigen sie auf genau denselben Wert. Dies bedeutet, dass Container A und B innerhalb des Pods direkt über „localhost“ kommunizieren können.
Sie nehmen dieselben Netzwerkgeräte wahr wie der Infra-Container. Ein Pod hat nur eine IP-Adresse, nämlich die IP-Adresse, die dem Network Namespace des Pods zugeordnet ist. Natürlich werden alle anderen Netzwerkressourcen pro Pod zugewiesen und von allen Containern innerhalb dieses Pods gemeinsam genutzt. Der Lebenszyklus eines Pods ist ausschließlich an den Infra-Container gebunden und unabhängig von den Containern A und B.
Darüber hinaus kann der ein- und ausgehende Datenverkehr aller Benutzercontainer im selben Pod als durch den Infra-Container fließend betrachtet werden. Dieser Aspekt ist entscheidend, denn wenn Sie in Zukunft ein Netzwerk-Plugin für Kubernetes entwickeln, sollte Ihr Hauptaugenmerk auf der Konfiguration des Network Namespace des Pods liegen, nicht darauf, wie jeder Benutzercontainer Ihre Netzwerkkonfiguration nutzt. Letzteres ist unerheblich.
Dies bedeutet, dass Ihr Netzwerk-Plugin, wenn es auf der Installation von Paketen oder Konfigurationen innerhalb des Containers basiert, keine praktikable Lösung ist. Das Root-Dateisystem des Infra-Container-Images ist praktisch leer, sodass Ihnen kaum Spielraum für Anpassungen bleibt. Andererseits bedeutet dies auch, dass Ihr Netzwerk-Plugin sich nicht um den Startstatus der Benutzercontainer kümmern muss, sondern sich nur auf die Konfiguration des Pods, also des Network Namespace des Infra-Containers, konzentrieren muss.
Durch dieses Design wird die gemeinsame Nutzung von Volumes viel einfacher. Kubernetes kann alle Volume-Konfigurationen auf Pod-Ebene definieren. Folglich ist das Host-Verzeichnis eines Volumes für den Pod eindeutig, und jeder Container innerhalb des Pods muss nur das Mounten dieses Verzeichnisses deklarieren.
Dieses Designprinzip hinter Pods, das eine „superenge Beziehung“ zwischen den Containern fördert, soll Benutzer dazu ermutigen, zu überlegen, ob Anwendungen mit mehreren, funktional nicht zusammenhängenden Komponenten, die in einem einzigen Container laufen, nicht besser als mehrere Container in einem Pod dargestellt werden könnten.
Um diese Denkweise zu verstehen, versuchen Sie, sie auf Szenarien anzuwenden, die mit einem einzelnen Container schwer zu lösen sind. Stellen Sie sich zum Beispiel eine Anwendung vor, die kontinuierlich Logdateien in das Verzeichnis „/var/log“ innerhalb des Containers ausgibt. In diesem Fall können Sie ein Volume innerhalb des Pods in das Verzeichnis „/var/log“ des Anwendungscontainers einhängen. Führen Sie dann im selben Pod einen Sidecar-Container aus, der ebenfalls das Mounten desselben Volumes in sein „/var/log“-Verzeichnis deklariert.
Von dort aus besteht die einzige Aufgabe des Sidecar-Containers darin, kontinuierlich Logdateien aus seinem „/var/log“-Verzeichnis zu lesen und an Speicherlösungen wie MongoDB oder Elasticsearch weiterzuleiten. Dieses Setup etabliert einen grundlegenden Log-Erfassungsmechanismus.
Ähnlich wie im ersten Beispiel besteht die Hauptfunktion des Sidecars auch in diesem Szenario darin, mithilfe des gemeinsam genutzten Volumes Dateioperationen durchzuführen. Übersehen Sie jedoch nicht das andere entscheidende Merkmal von Pods: Alle Container innerhalb eines Pods teilen denselben Network Namespace. Dadurch können viele Konfigurations- und Verwaltungsaufgaben im Zusammenhang mit dem Netzwerk des Pods an den Sidecar delegiert werden, ohne dass die Benutzercontainer beeinträchtigt werden müssen. Ein Paradebeispiel hierfür ist das Istio Service-Mesh-Projekt.
Zusammenfassung
In dieser Diskussion haben wir uns mit den Gründen beschäftigt, warum wir Pods brauchen. Im Wesentlichen ist ein Pod die grundlegende Einheit in einem Kubernetes-Cluster, die einen oder mehrere Container (normalerweise Docker-Container) kapselt. Diese Container teilen sich Netzwerk- und Speicherressourcen. Aus der Perspektive von Prozessen und Prozessgruppen kann ein Pod als eine leichtgewichtige Prozessgruppe betrachtet werden. Er ermöglicht die Bereitstellung, Skalierung und Verwaltung mehrerer eng zusammenarbeitender Prozesse (Container) als eine zusammenhängende Einheit, was die Bereitstellung und den Betrieb komplexer Anwendungen vereinfacht. Im nächsten Artikel werden wir Pods genauer erläutern.
Novita AI ist die All-in-One-Cloud-Plattform, die Ihre KI-Ambitionen unterstützt. Mit nahtlos integrierten APIs, serverlosem Computing und GPU-Beschleunigung bieten wir die kosteneffizienten Tools, die Sie benötigen, um Ihr KI-gesteuertes Geschäft schnell aufzubauen und zu skalieren. Beseitigen Sie Infrastruktur-Herausforderungen und starten Sie kostenlos – Novita AI macht Ihre KI-Träume wahr.
Empfohlene Lektüre:
