Detaillierte Erläuterung der Verwendung der Cloud-native-Technologie Kubernetes Scheduling Unit Pod

Die kleinste Planungseinheit in k8s --- pod

Im vorherigen Artikel haben wir kurz die Probleme vorgestellt, die k8s lösen kann. Kurz gesagt, das Problem, das es löst, ist die Orchestrierung und Planung von Containern. Sein Kernwert liegt darin: Es gibt tatsächlich verschiedene Beziehungen zwischen Aufgaben, die in großen Clustern ausgeführt werden. Die Verarbeitung dieser Beziehungen ist der schwierigste Teil der Aufgabenorchestrierung und des Systemmanagements. k8s wurde für dieses Problem geboren.

Dieser Satz ist schwer zu verstehen. Wir beginnen mit dem vorhandenen Wissen, entschlüsseln es und verstehen es langsam. Wir wissen bereits, dass das Wesen eines Containers ein Prozess ist, der aus drei Teilen besteht:

Wenn ein Container ein Prozess in einer Cloud-Umgebung ist, können Sie sich k8s als ein Betriebssystem in einer Cloud-Umgebung vorstellen.

In einem Betriebssystem werden Prozesse nicht immer isoliert ausgeführt, sondern häufig als Prozessgruppe. Beim tatsächlichen Deployment von Anwendungen werden unsere Anwendungen häufig nicht isoliert in Docker-Containern ausgeführt. Es bestehen verschiedene Beziehungen zwischen Anwendungen. Manchmal müssen sie auf derselben Maschine ausgeführt werden und aufeinander zugreifen, ähnlich wie bei einer Bündelung. Zum Beispiel, wenn zwei Container Dateien austauschen oder bestimmte Linux-Namespaces gemeinsam nutzen müssen usw. Wir nennen diese Art von Beziehung eine „super-intime Beziehung“.

Basierend auf der obigen Prämisse hat k8s dies zu Beginn seines Entwurfs berücksichtigt. Daher wurden bei der Entwicklung keine Container als kleinste Planungseinheit verwendet, sondern das neue Konzept von Pods als kleinste Planungseinheit von k8s. Jeder Pod kann mehrere Container enthalten. Auf diese Weise werden die in den Containern bereitgestellten Anwendungen gebündelt, d. h. sie können nur auf einer Maschine bereitgestellt werden und die Bereitstellung ist entweder erfolgreich oder fehlgeschlagen, und es besteht keine Möglichkeit eines Zwischenzustands.

Welche Beziehung besteht zwischen Pod und Container?

Es ist zu beachten, dass Pod ein logisches Konzept ist und im Wesentlichen aus einer Gruppe von Containern besteht, die bestimmte Ressourcen gemeinsam nutzen. Genauer gesagt teilen sich Container im selben Pod denselben Netzwerk-Namespace und können natürlich auch Ressourcen wie gemountete Volumes gemeinsam nutzen.

Das sogenannte Teilen ist keine Abhängigkeit, sondern Gleichheit.

Wenn wir zwei Container A und B haben und A von B abhängt, muss A nach B gestartet werden. Wenn der Status von A und B gleich ist, gibt es keine strengen Anforderungen an die Startreihenfolge von A und B. Dies ist echtes Teilen. Wer erstellt also im Voraus die gemeinsam genutzten Netzwerkressourcen?

Wenn in einem Pod mehrere Anwendungscontainer enthalten sind, ist ein Infracontainer erforderlich, um diese Anwendungscontainer zu verknüpfen. Es sieht so aus:

In K8S nimmt der Infra-Container nur sehr wenige Ressourcen in Anspruch. Er führt nur ein Image namens Pause aus, daher wird er auch Pausencontainer genannt. Die von ihm belegte Festplattengröße liegt zwischen 100 und 200 KB. Der Zweck der Infrastruktur besteht darin, einen Netzwerk-Namespace zu erstellen. Anschließend können Anwendungscontainer A und Anwendungscontainer B zu diesem Netzwerk-Namespace hinzugefügt werden.

Für Container A und Container B im Pod:
1. Sie können direkt über localhost kommunizieren;
2. Die Netzwerkgeräte, die sie sehen, sind genau dieselben, die der Infra-Container sieht.
3. Ein Pod hat nur eine IP-Adresse, nämlich die IP-Adresse, die dem Netzwerk-Namespace des Pods entspricht.
4. Natürlich werden alle anderen Netzwerkressourcen von einem Pod und allen Containern im Pod gemeinsam genutzt.
5. Der Lebenszyklus des Pods stimmt nur mit dem Infra-Container überein und hat nichts mit den Containern A und B zu tun.
6. Für alle Benutzercontainer im selben Pod kann davon ausgegangen werden, dass ihr eingehender und ausgehender Datenverkehr auch über den Infra-Container abgeschlossen wird

In diesem Entwurfsmodus ist es sehr einfach, dasselbe Volume zu mounten. Sie müssen nur die Volume-Parameter in der Initialisierungs-YAML-Datei des Pods konfigurieren. Der spezifische Inhalt wird später freigegeben.

Bei Containern gilt, dass ein Container nur einen Prozess, keine Anwendung verwalten kann. Wenn wir Anwendungen in die Cloud migrieren, müssen wir die Anwendung in mehrere Prozesse aufteilen und dann prüfen, ob die Anwendungsmodule eine „super-intime Beziehung“ haben. Prozesse mit super-intimen Beziehungen können in einem Pod bereitgestellt werden, und andere Prozesse können in einem anderen Pod bereitgestellt werden. Die Verwendung dieser Idee zum Aufteilen der Anwendung entspricht der ursprünglichen Absicht des Containerdesigns.

Oben finden Sie den ausführlichen Inhalt der ausführlichen Erklärung zur Verwendung des Kubernetes-Planungseinheits-Pods der Cloud-nativen Technologie. Weitere Informationen zur Verwendung des Kubernetes-Planungseinheits-Pods finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!