Der ReplicaSet-Controller dient zur Verwaltung zustandsloser Pod-Ressourcen . Seine Kernfunktion besteht darin, im Namen des Benutzers eine bestimmte Anzahl von Pod-Kopien zu erstellen und sicherzustellen, dass die Anzahl der Pod-Kopien immer der vom Benutzer erwarteten Anzahl entspricht. Es unterstützt auch Mechanismen wie Pod Rolling Update und automatische Skalierung; es wird als eine neue Generation von ReplicationCtroller bezeichnet.

ReplicaSet besteht hauptsächlich aus drei Komponenten:

Die vom Benutzer erwartete Anzahl der Pod-Replikate;
Der Label-Selektor wird verwendet, um Pod-Kopien auszuwählen, die von ihm selbst verwaltet oder gesteuert werden. Wenn die Anzahl der über den Label-Selektor ausgewählten Pods geringer ist als die definierte Anzahl von Pod-Kopien, wird die Pod-Ressourcenvorlage verwendet, um Pod-Kopien zu erstellen, um das angegebene Ziel zu erreichen Pod-Menge;
Pod-Ressourcenvorlage.

Kubernetes empfiehlt Benutzern jedoch nicht , ReplicaSet direkt zu verwenden, sondern Deployment zu verwenden .

2. Bereitstellung

Deployment ist ebenfalls ein Pod-Controller, funktioniert aber auf ReplicaSet. Die Bereitstellung steuert den Pod durch die Steuerung von ReplicaSet. Die Bereitstellung kann leistungsfähigere Funktionen als ReplicaSet bereitstellen. Beispiel: Rollback der Pod-Version, deklarative Konfiguration (deklarative Konfiguration bedeutet, dass der erstellte Pod die Konfiguration jederzeit ändern und auf den Pod anwenden kann). Deployment ist derzeit der beste Controller für die Verwaltung zustandsloser Anwendungen.

3、DaemonSet

DaemonSet wird verwendet, um sicherzustellen, dass jeder Knoten im Cluster nur eine bestimmte Pod-Kopie ausführt , die normalerweise zum Implementieren von Hintergrundaufgaben auf Systemebene verwendet wird. Der Vorteil des Hostens einer solchen Aufgabe auf Kubernetes besteht darin, dass bei einem Ausfall der Hintergrundaufgabe automatisch ein Pod vom DaemonSet-Controller neu erstellt wird; wenn ein neuer Node-Knoten erstellt wird, erstellt er auch einen solchen Pod, der auf dem neuen Knoten ausgeführt wird .

Einschränkungen: Auf einigen Knoten im K8S-Cluster, die die Bedingungen gemäß unseren eigenen Anforderungen erfüllen, können wir auch nur eine Pod-Kopie ausführen.

Zusammenfassung: Die Dienste, die in den von Deployment und DaemonSet verwalteten Pods ausgeführt werden , sind zustandslos und daemon-ähnlich (müssen immer kontinuierlich im Hintergrund ausgeführt werden). Aber für Aufgaben, die nur einmal ausgeführt und dann beendet werden sollen, können die beiden oben genannten Controller natürlich nicht verwendet werden. Beispiel: Wir müssen die Datenbank sichern. Nach Abschluss der Sicherung sollte die Aufgabe beendet werden, anstatt sie im Hintergrund weiterlaufen zu lassen. Dann wird diese Art von Aufgabe nur einmal ausgeführt. Solange die Aufgabe abgeschlossen ist, wird sie normal beendet und neu erstellt, wenn sie nicht abgeschlossen ist. Aus diesem Grund sollten Sie sich für die Verwendung eines Controllers wie Job entscheiden .

4、Job

Der Job-Controller steuert die Aufgabe, die einen Job nur einmal ausführen kann . Er stellt sicher, dass die Aufgabe tatsächlich normal abgeschlossen wird und beendet wird. Wenn sie abnormal beendet wird, erstellt der Job-Controller die Aufgabe neu und führt sie erneut aus, bis die Aufgabe normal abgeschlossen ist.

Was ist mit regelmäßigen Aufgaben? Offensichtlich ist auch der Job-Controller nicht in der Lage. Dies erfordert CronJob .

5、CronJob

CronJob ähnelt Job, wird jedoch nach einmaliger Ausführung beendet. Der Unterschied besteht darin, dass Job nur einmal ausgeführt wird, während CronJob regelmäßig ausgeführt wird . Aber jeder Lauf hat eine normale Endzeit. Was passiert, wenn die Ausführung der vorherigen Aufgabe noch nicht abgeschlossen ist und es Zeit für die Ausführung der nächsten Aufgabe ist? CronJob kann auch solche Probleme lösen.

6、Statuensatz

Der StatufulSet-Controller kann zustandsbehaftete Pod-Kopien verwalten, und jede Pod-Kopie wird separat verwaltet, mit ihrem eigenen eindeutigen Flag und eindeutigen Datensatz. Sobald dieses Replikat ausfällt, werden viele Initialisierungsvorgänge durchgeführt, bevor der Pod neu erstellt wird.

Nehmen Sie als Beispiel den Redis-Cluster: Wenn einer der drei Knoten im Redis-Cluster ausfällt, besteht unsere traditionelle Methode darin, für jeden Knoten eine Master-Slave-Replikation durchzuführen, um sicherzustellen, dass die Daten nicht verloren gehen, nachdem jeder Knoten ausgefallen ist Nach dem Herunterfahren muss der Slave-Knoten manuell zum Master-Knoten heraufgestuft werden. Wenn Sie den Slave-Knoten wiederherstellen möchten, sind viele Betriebs- und Wartungsvorgänge erforderlich.

Wenn Sie jedoch StatufulSet zum Definieren und Verwalten von Redis, MySQL oder Zookeeper verwenden, sind ihre Konfigurationen unterschiedlich. Beispiel: Die Betriebsschritte zwischen der Redis-Master-Slave-Replikation des Konfigurationsmanagements und der MySQL-Master-Slave-Replikation des Konfigurationsmanagements sind unterschiedlich. Daher gibt es in einer solchen Konfiguration keine Regel, die befolgt werden muss. StatufulSet stellt uns ein Paket zur Verfügung. Benutzer definieren komplexe Ausführungslogik, die manuelle Vorgänge erfordert, als Skripte und platzieren sie in der Pod-Vorlage von StatufulSet. Auf diese Weise kann nach jedem Ausfall eines Pod-Knotens dieser automatisch über das Skript wiederhergestellt werden.

Zusammenfassung: Es ist immer noch ziemlich schwierig, wirklich zustandsbehaftete Anwendungen auf Kubernetes hosten zu wollen.

7、CDR

Benutzerdefinierte Ressourcen K8S 1.8+, benutzerdefinierte Ressourcen.

8、Helm

Jede App, die Benutzer nicht wie Idioten behandelt, wird wahrscheinlich keinen Erfolg haben. Die Definition der K8S-Ressourcenliste ist zu hoch und schwierig. Daraus entstand Helm. Für Kubernetes entspricht Helm yum im Linux-System . In Zukunft können Sie bei der Bereitstellung umfangreicher Anwendungen Helm zur direkten Installation und Bereitstellung verwenden. Allerdings ist Helm bisher erst seit mehr als zwei Jahren geboren. Bisher können viele große und Mainstream-Anwendungen über Helm bereitgestellt werden.

Zweitens: ReplicaSet-Ressourcenliste

Felder der ersten Ebene, wenn die ReplicaSet-Ressourcenliste definiert ist:

apiVersion: apps/v1
kind: ReplicaSet
metadata: 
spec:

Auf der unteren Spezifikationsebene gibt es drei Hauptkernfelder:

replicas    <integer>       # 定义Pod副本数量
selector    <Object>        # 选择器
template    <Object>        # 模板

Im Vorlagenfeld ist das durch die Pod-Ressourcenliste definierte Feld verschachtelt:

metadata    <Object>        # 这是定义Pod的元数据
spec        <Object>        # Pod的spec

Als Nächstes definieren wir eine Ressourcenliste für ReplicaSet: rs-demo.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myapp
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
      release: canary
  template:
    metadata:
      name: myapp-pod
      labels:
        app: myapp
        release: canary
        environment: qa
    spec:
      containers:
      - name: myapp-container
        image: ikubernetes/myapp:v1
        ports:
        - name: http
          containerPort: 80

Hinweise siehe Bild unten:

Erstellen Sie mithilfe der obigen Auflistung ein ReplicaSet namens „myapp“:

kubectl create -f rs-demo.yaml

Sehen Sie sich das erfolgreich erstellte ReplicaSet an:

ReplicaSet kann als rs abgekürzt werden.

Es ist erwähnenswert, dass der in der Pod-Vorlage definierte Pod-Name (wie im obigen Code:) name: myapp-podtatsächlich keine Auswirkung hat. Da der über die Controller-Manifestdatei erstellte Pod-Name 控制器名称-随机字符串gemäß dieser Form benannt wird. Wie nachfolgend dargestellt:

Holen Sie sich den erstellten Pod:

Nach der Aktualisierung des Pod-Container-Images wird die neue Version des Pod-Update-Diagramms angezeigt:

3. Liste der Bereitstellungsressourcen

Die Anzahl der von der Bereitstellungsverwaltung beibehaltenen ReplicaSet-Versionen kann vom Benutzer angepasst werden. Standardmäßig werden 10 historische Versionen beibehalten. Die Bereitstellung kann eine deklarative Konfiguration verwenden, und die deklarative Konfiguration verwendet kubectl apply -f demo.yamlBefehle. Für deklarativ konfigurierte Ressourcen können Sie auch patchUnterbefehle in der Befehlszeile verwenden, um in Zukunft Patches durchzuführen, um Konfigurationsänderungen und -aktualisierungen zu implementieren.

Wenn die Bereitstellung die fortlaufende Pod-Aktualisierung steuert, kann sie auch die Logik der fortlaufenden Pod-Aktualisierung konfigurieren.

Die Beziehung zwischen Deployment, ReplicaSet und Pod:

„Deployment“ kann als „Deployment“ abgekürzt werden
. Schauen Sie sich als Nächstes die Felder der ersten Ebene der Deployment-Ressourcenliste an:

apiVersion: apps/v1
kind: Deployment
metadata: 
spec:

Die Spezifikation von Deployment unterscheidet sich nicht wesentlich von der von ReplicaSet.
Das Spezifikationsfeld in der Bereitstellung:

replicas    <integer>   # Pod副本数量
selector    <Object>    # 标签选择器
template    <Object> -required-     # Pod模板
strategy    <Object>    # 定义Pod更新策略
paused      <boolean>
revisionHistoryLimit    <integer>

1. Strategie (Pod-Update-Strategie)

spec:
  strategy:
    type:                     # <string>
    rollingUpdate:            # <Object>

Der Wert des Felds strategy.type :

Recreate: Neu erstellen und aktualisieren, dh einen Pod löschen und einen Pod neu erstellen. Wenn type,recreate wird das RollingUpdate-Feld auf derselben Ebene wie der Typ ungültig. Wenn typees ist rollingUpdate, definiert das Feld auf derselben Ebene wie der Typ rollingUpdatedie fortlaufende Aktualisierungsstrategie.
RollingUpdate: fortlaufendes Update

strategy.rollingUpdate- Feld:

maxSurge: Wenn der Pod gerollt und aktualisiert wird, kann die durch Replikate definierte maximale Anzahl von Pod-Kopien überschritten werden. Es gibt zwei Möglichkeiten, den Wert zu erhalten: 1. Geben Sie direkt eine Zahl an (z. B. 5); 2. Geben Sie einen Prozentsatz an (z. B. 10 %).
maxUnavailable: Wenn der Pod fortlaufend aktualisiert wird, sind höchstens einige nicht verfügbar. Angenommen, replicasder Wert ist 5 und maxUnavailableder Wert ist 1, dann beträgt die Anzahl der verfügbaren Pods mindestens 5-1=4. In diesem Feld kann auch ein Prozentsatz als Wert angegeben werden.

Beispiel: Wenn der Pod fortlaufend aktualisiert wird, kann es nur mehr als 2 geben und nur einer weniger kann wie folgt definiert werden:

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1

2、revisionHistoryLimit

revisionHistoryLimit <integer>Gibt die Anzahl der alten ReplicaSets an, die beibehalten werden sollen, um ein Rollback zu ermöglichen. Der Standardwert ist 10. Ein Wert von 0 bedeutet, dass alte Versionen nicht gespeichert werden.

3、Pause

paused <boolean>Gibt an, ob die Bereitstellung des Pods angehalten werden soll. Normalerweise wird er nicht angehalten. Der Pod wird sofort bereitgestellt, nachdem der Befehl ausgeführt wurde.

4、Vorlage

template <Object> -required-Die Pod-Vorlage stimmt mit der Definition der Pod-Vorlage im ReplicaSet überein.

5. Beispiel für eine Bereitstellungsressourcenliste

Bearbeiten Sie die Yaml-Datei: „deploy-demo.yaml“.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deploy
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
      release: canary
  template:
    metadata:
      labels:
        app: myapp
        release: canary 
    spec:
      containers:
      - name: myapp
        image: ikubernetes/myapp:v1
        ports:
        - name: http
          containerPort: 80

Hier erstellen wir es deklarativ:

[root@k8s-master manifests]# kubectl apply -f deploy-demo.yaml 
deployment.apps/myapp-deploy created

Schauen Sie sich das erstellte Ergebnis an:

Gleichzeitig wird automatisch ein ReplicaSet erstellt, wie in der folgenden Abbildung dargestellt:

Automatisch erstellte ReplicaSet-Benennungsregeln: deploy名称-Pod模板hash值.

Sehen Sie sich den erstellten Pod an, wie unten gezeigt:

Pod-Befehlsregeln: deploy名称-Pod模板hash值-随机字符串.

Wenn wir zu diesem Zeitpunkt die Anzahl der Pod-Kopien ändern möchten, können wir sie direkt vim deploy-demo.yamländern replicas: 4und dann ausführen kubectl apply -f deploy-demo.yaml.

Hinweis: Deklarativ erstellt, kann dieselbe Yaml-Datei mehrmals ausgeführt werden kubectl apply. Stattdessen kubectl createkann es nur einmal ausgeführt werden.

In der Beispielauflistung oben gibt es viele Felder, die wir nicht definiert haben. Kubernetes trägt die Standardwerte automatisch ein. Sie können den Befehl „ kubectl get deploy myapp-deploy -o yamlAnsicht“ verwenden.

5.1. Update-Vorgang

Lassen Sie uns zuerst „deploy-demo.yaml“ ändern und die Container-Image-Version auf v2 ändern:
vim deploy-demo.yaml

Erneut bereitstellen:

[root@k8s-master manifests]# kubectl apply -f deploy-demo.yaml 
deployment.apps/myapp-deploy configured

Besuchen Sie die neue Pod-Version. Sie können sehen, dass sie auf die Version v2 aktualisiert wurde.

Scrollverlauf anzeigen:

[root@k8s-master manifests]# kubectl rollout history deployment myapp-deploy 
deployments "myapp-deploy"
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

5.2. Aktualisieren Sie die Konfiguration der Ressourcenliste durch Patchen

[root@k8s-master manifests]# kubectl patch deployment myapp-deploy -p '{"spec": {"replicas": 5}}'
deployment.extensions/myapp-deploy patched

Sie können sehen, dass die Anzahl der Pod-Replikate sofort auf 5 aktualisiert wurde.

Ändern Sie die Rolling-Update-Strategie durch Patchen:

[root@k8s-master manifests]# kubectl patch deployment myapp-deploy -p '{"spec": {"strategy": {"type": "RollingUpdate", "rollingUpdate": {"maxSurge": 1, "maxUnavailable": 0}}}}'
deployment.extensions/myapp-deploy patched

Schauen Sie sich die Rolling-Update-Strategie an, die Änderung wurde angewendet:

5.3. Pod-Update unterbrechen

Für dieses Beispiel können wir zunächst die Image-Version ändern und dann das fortlaufende Update sofort anhalten.
Um die Image-Version zu ändern, können Sie nicht nur vimBefehle zum direkten Bearbeiten der Yaml-Datei oder zum Verwenden kubectl patchvon Patches verwenden, sondern auch kubectl set imagedas Image direkt ändern. Beispiel: kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.1
Der Befehl lautet wie folgt:

[root@k8s-master ~]# kubectl set image deployment myapp-deploy myapp=ikubernetes/myapp:v3 && kubectl rollout pause deployment myapp-deploy 
deployment.extensions/myapp-deploy image updated
deployment.extensions/myapp-deploy paused

Öffnen Sie ein anderes Terminal, um app=myappden Pod mit Label zu überwachen:

Wie aus der obigen Abbildung ersichtlich ist, wird nach der Ausführung des Befehls „Rolling Update Pause“ zunächst ein neuer Pod erstellt und ausgeführt und dann angehalten, und einer der alten Pods wird nicht gelöscht. Derzeit gibt es 6 Pods, wie in der folgenden Abbildung dargestellt:

Über den Befehl: kubectl rollout status deployment myapp-deploykönnen Sie den Status des fortlaufenden Updates sehen, wie in der folgenden Abbildung dargestellt:

Die Eingabeaufforderung in der Abbildung sagt uns: Warten auf den Abschluss der Bereitstellung „myapp-deploy“: 1 von 5 neuen Kopien wurde aktualisiert ...

Als nächstes setzen wir die Pod-Updates fort...

5.4. Pod-Update fortsetzen

Um die Pod-Aktualisierung fortzusetzen, verwenden Sie den folgenden Befehl:

[root@k8s-master ~]# kubectl rollout resume deployment myapp-deploy 
deployment.extensions/myapp-deploy resumed

Überprüfen Sie den Status des fortlaufenden Updates:

Wie aus der Abbildung ersichtlich ist, ist das fortlaufende Update abgeschlossen.

Sehen Sie sich den Status des ReplicaSet an:

Aus der Abbildung oben können Sie ersehen, dass das Image auf Version v3 aktualisiert wurde und 5 Pods bereit sind.

Führen Sie als Nächstes einen Rollback-Vorgang durch. . .

5.5. Rollback-Vorgang

Wenn es ein Problem mit der neuen Version des Anwendungs-Pods gibt und Sie ein Rollback durchführen möchten, müssen Sie den folgenden Befehl verwenden:kubectl rollout undo

kubectl rollout undo deployment myapp-deploy --to-revision=1

--to-revision=1Zeigt ein Rollback auf Version 1 an. Wenn die Option --to-revision nicht angegeben ist, erfolgt standardmäßig ein Rollback auf die vorherige Version. Es kann per Befehl angezeigt werden kubectl rollout history deployment myapp-deploy.

Nach dem Rollback wird die ursprüngliche Version 1 zu Version 4, sodass die vorherige Version von Version 4 Version 3 ist. Wenn Sie eine Version von Version 4 zurücksetzen, erfolgt ein Rollback auf Version 3.

Werfen wir einen Blick auf den Status von ReplicaSet:

Wie aus der obigen Abbildung ersichtlich ist, wurde ein Rollback auf Version v1 durchgeführt, und 5 Pods in Version v1 sind bereit. Die Anzahl der Pods in der v3-Version beträgt 0.

4. DaemonSet-Ressourcenliste

Der DaemonSet-Controller kann Pods ausführen, die Verwaltungsfunktionen auf Systemebene auf bestimmten Knoten implementieren können, und jeder bestimmte Knoten führt nur eine Kopie solcher Pods aus. Sie können auch das Verzeichnis des Knotens im Pod bereitstellen und einige Verwaltungsfunktionen über den Pod implementieren.

Wenn DaemonSet eine Ressourcenliste definiert, ist es nicht mehr erforderlich, replicasein Feld zur Angabe der Anzahl der Replikate zu verwenden.

Die im Spezifikationsfeld in der DaemonSet-Ressourcenmanifestdatei enthaltenen Unterfelder:

revisionHistoryLimit    <integer>   # rs历史版本保存个数，与Deployment中的此字段意义相同。
selector    <Object>    # 标签选择器
template    <Object> -required-     # Pod模板
updateStrategy  <Object>            # Pod更新策略

Update-Strategie:

spec
  updateStrategy:
    type: RollingUpdate
    rollingUpdate: 
      maxUnavailable: 2

Es gibt zwei Pod-Aktualisierungsstrategien für DaemonSet: "RollingUpdate"und "OnDelete". Nur RollingUpdatewenn der Typ ist , rollingUpdatewerden die Felder auf derselben Ebene wie der Typ wirksam. rollingUpdateUnter Feld gibt es nur ein Feld maxUnavailable. Das heißt, wenn der Pod von DaemonSet aktualisiert wird, kann es nur weniger und nicht mehr geben.

Beispiel für eine DaemonSet-Ressourcenliste:

apiVersion: apps/v1
kind: DaemonSet
metadata: 
  name: filebeat-ds
  namespace: default
spec: 
  selector:
    matchLabels:
      app: filebeat
      release: stable
  template:
    metadata: 
      labels:
        app: filebeat
        release: stable
    spec: 
      containers:
      - name: filebeat
        image: ikubernetes/filebeat:5.6.5-alpine
        env: 
        - name: REDIS_HOST
          value: redis-svc
        - name: REDIS_LOG_LEVEL
          value: info

Beim Definieren der DaemonSet-Ressourcenliste ist es nicht erforderlich, replicasdiese anzugeben.

Erklärung des K8S Pod-Controllers

1. Pod-Controller-Kategorie

1、ReplicaSet