Detaillierte Erläuterung der Kubernetes-Pod-Orchestrierung und des Lebenszyklus

K8S Master Grundlegende Architektur

Der Betrieb des K8S-Clusters hängt von der Kommunikation zwischen dem Master-Knoten und dem Node-Knoten ab. Um den Pod-Lebenszyklus in Teil 4 besser zu verstehen, geben wir zunächst ein einfaches Architekturdiagramm des K8S-Masters. In den folgenden Artikeln werden wir die Beziehung zwischen Master, Node und Pod analysieren.

Master-Architekturdiagramm:

In:

Der API-Server bietet eine HTTP-REST-Schnittstelle, die der einzige Einstiegspunkt zum Hinzufügen, Löschen, Ändern und Überprüfen aller Ressourcen in k8s und auch der Einstiegspunkt für die Clustersteuerung ist.

Der Scheduler ist der Prozess, der für die Ressourcenplanung verantwortlich ist;

Controller Manager ist das Automatisierungskontrollzentrum für alle Ressourcenobjekte;

Etcd bietet Datenspeicherdienste für Ressourcenobjekte

Jede Komponente hat viele Wissenspunkte. Hier müssen wir nur einen Makroeindruck haben. In den nachfolgenden Artikeln werden wir sie einzeln analysieren.

Pod-Orchestrierungskonzept

Am Ende des vorherigen Artikels haben wir die Vorsichtsmaßnahmen bei der Migration von Anwendungen zu k8s erwähnt. Lassen Sie mich hier noch einmal betonen, dass wir Pod zum Erstellen unserer Anwendungsmodule verwenden müssen, wenn wir Anwendungen auf virtuellen Maschinen zu k8s migrieren möchten. An diesem Punkt ist es wichtiger, unsere Anwendungsmodule aufzuteilen, da Container und virtuelle Maschinen unterschiedliche Entwurfsmuster aufweisen. Um jedoch die Beziehung zwischen beiden besser zu verstehen und zu vergleichen, können wir uns die folgende Entsprechung vorstellen:

k8s-----Betriebssystem

Pod – Virtuelle Maschine

Container-Prozess

1. k8s entspricht dem Betriebssystem einer physischen Maschine, und die k8s-Verwaltung von Pod entspricht dem Betriebssystem einer physischen Maschine, die eine virtuelle Maschine verwaltet

2. Pod entspricht einer virtuellen Maschine. Ein Pod kann mehrere Container enthalten, die vielen Prozessen in der virtuellen Maschine entsprechen.

3. Ein Container entspricht einem Prozess. Das Wesen eines Containers ist eigentlich ein Prozess.

Mit diesem Konzept ist Pod möglicherweise leichter zu verstehen. Kehren wir zu unserer Anwendungsmigration zurück. Angenommen, unsere Anwendung existiert:

Webservice, Loganalyse, MySQL-Datenbank

Drei Schlüsselmodule, darunter:

Webdienste und Protokollanalyse haben eine „sehr enge Beziehung“, da das Protokollanalysemodul die vom Webdienstmodul generierten Protokolle verwendet und daher auf demselben Server bereitgestellt werden müssen. Im Gegenteil, auf den Webdienst und die MySQL-Datenbank kann über TCP-IP zugegriffen werden, sodass sie nicht auf derselben Maschine bereitgestellt werden müssen. Wenn wir diese Anwendung in einem Container ausführen, muss der Webdienst im selben Pod wie das Protokollanalysemodul verpackt werden, und der MySQL-Datenbankdienst kann in einem separaten Pod bereitgestellt werden. Wenn unsere Anwendung auf k8s migriert wird, kann sie die folgende Struktur haben:

Das Anordnen verschiedener Prozesse oder Aufgaben im selben Pod ist im Wesentlichen ein Pod-Anordnungskonzept.

Was sind die Eigenschaften des Pod-Objekts und die Eigenschaften des Containers?

Aus der obigen Analyse ist nicht schwer zu erkennen, dass der Container ein zum Pod gehörendes Element ist. Aus der YAML-Datei geht hervor, dass der Container ein Feld in der gesamten YAML-Datei des Pods ist. Sehen wir uns nun die wichtigen Eigenschaften von Pods und Containern an.

Schauen wir uns zunächst die Eigenschaften des Pods an:

1. Alle Attribute im Zusammenhang mit Planung, Netzwerk, Speicher und Sicherheit beziehen sich grundsätzlich auf Pod.

Die Planung ist natürlich selbstverständlich. Pod ist die kleinste Planungseinheit von k8s; Netzwerk, Container im selben Pod teilen sich das Netzwerk des Pods; Speicher, verschiedene Container können den Speicher des Pods teilen, indem sie Volumes auf dem Pod mounten; die Sicherheit wird auch basierend auf der Pod-Dimension gesteuert.

2. Alle Attribute, die sich auf den Linux-Namespace des Containers beziehen, befinden sich auch auf der Pod-Ebene.

Die ursprüngliche Absicht des Pod-Designs besteht darin, Namespaces zwischen Containern zu teilen.

3. Alle Container in einem Pod müssen den Namespace des Hosts auf Pod-Ebene gemeinsam nutzen.

Dies ist einfacher zu verstehen. Da der Pod den Namespace des Hosts gemeinsam nutzen muss, müssen die Container im Pod denselben Namespace gemeinsam nutzen. Daher muss diese Einstellung auf Pod-Ebene erfolgen.

Schauen wir uns zwei wichtige Eigenschaften von Container an:

1. ImagePullPolicy: Dieses Attribut definiert die Richtlinie zum Abrufen von Images. Der Standardwert ist „always“, was bedeutet, dass bei jeder Erstellung eines Pods ein Image abgerufen wird. Es hat zwei weitere Werte: „never“ und „ifnotpresent“. Diese beiden sind leichter zu verstehen. Der eine Wert bedeutet, dass das Image niemals abgerufen wird, und der andere Wert bedeutet, dass das Image nur abgerufen wird, wenn es nicht vorhanden ist. Zu beachten ist hierbei, dass ImagePullPolicy immer auf den Standardwert gesetzt wird, wenn unsere Versionsnummer als „neueste“ konfiguriert ist.

2. Lebenszyklus: Wie der Name schon sagt, führt es während des Lebenszyklus des Containers bestimmte Aktionen aus. Es verfügt über zwei allgemeine Parameter, postStart und preStop, bei denen es sich um bestimmte Vorgänge handelt, die nach dem Start oder vor dem Ende des Containers ausgeführt werden.

Pod-Lebenszyklus

Der Lebenszyklus eines Pods spiegelt sich hauptsächlich im Statusteil der Pod-API wider. Der Lebenszyklus eines Pods umfasst von Anfang bis Ende die folgenden Prozesse:

1. Ausstehend, was bedeutet, dass die YAML-Datei des Pods an k8s übergeben und in etcd gespeichert wurde (etcd ist das Metainformations-Repository in k8s). Aus Gründen wie beispielsweise einer erfolglosen Planung konnte es jedoch nicht erstellt werden.

2. Wird ausgeführt. Dieses Wort ist irreführend. Es bedeutet, dass der Pod erfolgreich geplant und an einen bestimmten Knotenserver gebunden wurde. Nicht alle Container im Pod werden normal ausgeführt, aber mindestens einer wird ausgeführt.

3. Erfolgreich: Dieser Status bedeutet, dass alle Container gestartet und beendet wurden.

4. Fehlgeschlagen: Dies ist leicht zu verstehen. Es bedeutet, dass mindestens einer der Container im Pod mit einem Status ungleich Null beendet wurde, d. h., er wurde abnormal beendet.

5.Unwissen. Dies ist ein abnormaler Zustand, der darauf hinweist, dass der aktuelle Pod-Status nicht normal an den Kube-API-Server gemeldet werden kann. Dies kann ein Problem mit der Kommunikation zwischen den Master- und Slave-Knoten sein.

Das Folgende ist ein Pod im laufenden Zustand:

[root@VM-16-13-centos ~]# kubectl get pod
NAME BEREIT STATUS NEUSTART ALTER
mysql-pd7jr 1/1 Wird ausgeführt 0 118d
myweb-60r22 1/1 Wird ausgeführt 0 80d

[root@VM-16-13-centos ~]#
 [root@VM-16-13-centos ~]# kubectl get pod mysql-pd7jr -o yaml
API-Version: v1
Art: Pod
Metadaten:
  ...
Spezifikation:
  ...
Status:
  ...
  HostIP: 127.0.0.1
  Phase: Laufen
  PodIP: 172.17.0.2
  Startzeit: 2020-11-20T09:01:39Z

Oben finden Sie eine ausführliche Erläuterung der Orchestrierung und des Lebenszyklus von Kubernetes Pod. Weitere Informationen zur Orchestrierung und zum Lebenszyklus von Kubernetes Pod finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!