Einführung und Verwendung von fünf Controllern in K8S

Controllertyp von k8s

Kubernetes verfügt über viele integrierte Controller, die einer Zustandsmaschine entsprechen und zur Steuerung des spezifischen Zustands und Verhaltens des Pods verwendet werden.

Bereitstellung: Geeignet für die zustandslose Bereitstellung von Diensten

StatefullSet: Geeignet für die zustandsbehaftete Dienstbereitstellung

DaemonSet: Einmal bereitstellen, alle Knoten werden bereitgestellt, beispielsweise einige typische Anwendungsszenarien:

Führen Sie Cluster-Speicher-Daemons wie Glusterd und Ceph auf jedem Knoten aus.

Führen Sie auf jedem Knoten einen Daemon zur Protokollsammlung aus, z. B. fluentd oder logstash.

Führen Sie auf jedem Knoten einen Überwachungs-Daemon aus, beispielsweise Prometheus Node Exporter.

Job: eine einmalige Ausführungsaufgabe

Cronjob: Periodische Ausführung von Aufgaben

Im Allgemeinen verfügt K8S über fünf Controller, die der Verarbeitung zustandsloser Anwendungen, zustandsbehafteter Anwendungen, geschützter Anwendungen und Batch-Anwendungen entsprechen.

Beziehung zwischen Pods und Controllern

Controller: Objekte, die Container in einem Cluster verwalten und ausführen, werden über Label-Selektoren verknüpft.

Pod verwendet Controller, um Anwendungsvorgänge und -wartung, wie beispielsweise Skalierung und Aktualisierung, zu implementieren.

Bereitstellung (zustandslose Anwendung)

Anwendungsszenario: Webservice

Bereitstellung bedeutet auf Chinesisch Bereitstellung und Planung. Durch Bereitstellung können wir RS (ReplicaSet) betreiben. Sie können es einfach als Deklaration durch eine YML-Datei verstehen. In der Bereitstellungsdatei können Sie die Anzahl der Pods, die Aktualisierungsmethode, das verwendete Image, das Ressourcenlimit usw. definieren. Zustandslose Anwendungen werden mit Deployment erstellt

Mit dem Bereitstellungsobjekt können Sie ganz einfach Folgendes tun:

• Erstellen Sie ein Replikatset und einen Pod
• Rolling Upgrade (Upgrade ohne Anhalten des alten Dienstes) und Rollback (Zurücksetzen der Anwendung auf die vorherige Version)
• Sanftes Ausdehnen und Reduzieren
• Anhalten und Fortsetzen einer Bereitstellung

Bereitstellung erstellen [root@master shuai]# vim nginx-delpoy.yaml

API-Version: Apps/v1
Art: Bereitstellung „Definition ist Bereitstellung“
Metadaten:
  Name: nginx-Bereitstellung
  Beschriftungen:
    App: nginx
Spezifikation:
  Replikate: 3 „Die Anzahl der Replikate beträgt 3“
  Wähler:
    Übereinstimmungsetiketten:
      App: nginx
  Vorlage:
    Metadaten:
      Beschriftungen:
        App: nginx
    Spezifikation:
      Behälter:
      - Bezeichnung: nginx
        Bild: nginx:1.15.4
        Häfen:
        - ContainerPort: 80


„Ressourcen erstellen“
[root@master shuai]# kubectl apply -f nginx-delpoy.yaml 
deployment.apps/nginx-deployment erstellt

//Replicaset steuert die Version und Anzahl der Replikate. Dadurch wird ein Rollback erreicht. '//Alle Ressourcen anzeigen'
[root@master shuai]# kubectl hol alles
NAME BEREIT STATUS NEUSTART ALTER
pod/nginx-deployment-d55b94fd-cndf2 1/1 Wird ausgeführt 0 3m31s
pod/nginx-deployment-d55b94fd-ghlwk 1/1 Wird ausgeführt 0 3m31s
pod/nginx-deployment-d55b94fd-tm4sw 1/1 Wird ausgeführt 0 3m31s
pod/pod-beispiel 1/1 Läuft 0 10h

NAME TYP CLUSTER-IP EXTERNE-IP PORT(S) ALTER
service/kubernetes ClusterIP 10.0.0.1 <keine> 443/TCP 3d6h

NAME GEWÜNSCHT AKTUELL AKTUELL VERFÜGBAR ALTER
Bereitstellung.apps/nginx-Bereitstellung 3 3 3 3 3m31s

NAME GEWÜNSCHT AKTUELL BEREIT ALTER
replicaset.apps/nginx-deployment-d55b94fd 3 3 3 3m31s

Controllerinformationen anzeigen kubectl deit deployment/nginx-deployment
.....Information ausgelassen.....
Strategie:
    rollingUpdate: „Die Versionsaktualisierung erfolgt über einen Rolling-Update-Mechanismus“
      maxSurge: 25 % „Die maximale Anzahl aktualisierter Kopien beträgt 25 % und die maximale Erweiterung beträgt 125 %.“ „Um die Anzahl der Kopien beizubehalten, wie viele Prozent der Erhöhung müssen gleichzeitig vernichtet werden?“
      maxUnavailable: 25 % „Die maximale Anzahl gelöschter Kopien beträgt 25 % und die maximale Reduzierung beträgt 75 %“
    Typ: RollingUpdate
...Informationen ausgelassen....


„Sie können es auch anzeigen, indem Sie kubectl describe deploy nginx-deployment ausführen.“

....Informationen ausgelassen....
RollingUpdateStrategy: 25 % max. nicht verfügbar, 25 % max. Anstieg

Historische Versionen anzeigen [root@master shuai]# kubectl rollout history deploy/nginx-deployment
Bereitstellung.Erweiterungen/nginx-Bereitstellung 
REVISION ÄNDERUNG-URSACHE
1 <keine> '//Hier gibt es nur eins, was beweist, dass es noch kein Rolling Update gibt'

Merkmale von Staat und Staatenlosigkeit

Merkmale zustandsloser Dienste:

1) Bei der Bereitstellung wird davon ausgegangen, dass alle Pods gleich sind

2) Keine Notwendigkeit, die Bestellanforderungen zu berücksichtigen

3) Sie müssen nicht überlegen, auf welchem ​​Knoten ausgeführt werden soll

4) Die Kapazität kann beliebig erweitert oder reduziert werden

Merkmale zustandsbehafteter Dienste:

1) Es gibt Unterschiede zwischen Instanzen. Jede Instanz hat ihre eigene Einzigartigkeit und Metadaten, wie etcd und Zookeeper.

2) Asymmetrische Beziehungen zwischen Instanzen und Anwendungen, die auf externen Speicher angewiesen sind.

Bereitstellungsupdates

Wenn Sie möchten, dass der Nginx-Pod das Image nginx:1.9.1 anstelle des ursprünglichen Nginx-Images verwendet, führen Sie den folgenden Befehl aus: [root@master ~]# kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
Bereitstellungsabbild „deployment.apps/nginx-deployment“ aktualisiert

Oder wir können den Befehl „edit“ verwenden, um das Deployment zu bearbeiten und das Image von nginx auf nginx:1.9.1 umzuschreiben.
kubectl edit deployment/nginx-deployment

Update-Fortschritt anzeigen[root@master ~]# kubectl rollout status deployment/nginx-deployment
Warten auf die Fertigstellung des Rollouts „nginx-deployment“: 1 alte Replikate stehen zur Beendigung an …
Warten auf die Fertigstellung des Rollouts „nginx-deployment“: 1 alte Replikate stehen zur Beendigung an …
Deployment „nginx-deployment“ erfolgreich ausgerollt

Wenn eine Bereitstellung aktualisiert wird, wird ein neues Replikatset erstellt. Anschließend werden die Pods im neuen Replikatset langsam auf die angegebene Anzahl von Replikaten erweitert und das alte Replikatset langsam auf 0 reduziert. Somit kann bei einem Update immer sichergestellt werden, dass der alte Dienst nicht gestoppt wird, es handelt sich also um ein Rolling Update.

Rollback einer Bereitstellung

Nachdem wir das Deployment wie oben beschrieben aktualisiert hatten, stellten wir fest, dass das Image nginx:1.9.1 nicht sehr stabil war, daher wollten wir es wieder auf nginx:1.7.9 ändern. Zu diesem Zeitpunkt müssen wir die Deployment-Datei nicht manuell ändern, sondern können die Rollback-Funktion des Deployments verwenden.

Verwenden Sie den Befehl „Rollout-Verlauf“, um die Revision der Bereitstellung anzuzeigen:

[root@master ~]# kubectl Rollout-Verlauf Bereitstellung/nginx-Bereitstellung
Bereitstellung.apps/nginx-Bereitstellung 
REVISION ÄNDERUNG-URSACHE
1 kubectl erstellen --filename=deploy.yml --record=true
2 kubectl erstellen --filename=deploy.yml --record=true

Da wir beim Erstellen der Bereitstellung den Parameter --recorded zum Aufzeichnen von Befehlen verwendet haben, können wir die Änderungen in jeder Revision problemlos anzeigen.

So zeigen Sie detaillierte Informationen zu einer einzelnen Revision an:

[root@master ~]# kubectl Rollout-Verlauf Bereitstellung/nginx-Bereitstellung --revision=2
deployment.apps/nginx-deployment mit Revision Nr. 2
Pod-Vorlage:
  Beschriftungen: app=nginx
        pod-template-hash=658d7f4b4b
  Anmerkungen: kubernetes.io/change-cause: kubectl create --filename=deploy.yml --record=true
  Behälter:
   nginx:
    Bild: nginx:1.9.1
    Anschluss: 80/TCP
    Host-Port: 0/TCP
    Umgebung: <keine>
    Reittiere: <keine>
  Bände: <keine>

Mit dem Befehl „Rollout rückgängig machen“ können Sie zur vorherigen Revision zurückkehren
[root@master ~]# kubectl rollout undo Bereitstellung/nginx-Bereitstellung
deployment.apps/nginx-deployment zurückgesetzt

[root@master ~]# kubectl beschreibt die Bereitstellung/nginx-Bereitstellung
Name: nginx-Bereitstellung
Namespace: Standard
Erstellungszeitstempel: Fr, 24. Dez. 2021 22:24:10 +0800
Beschriftungen: <keine>
Anmerkungen: deployment.kubernetes.io/revision: 3
                        kubernetes.io/change-cause: kubectl erstellen --filename=deploy.yml --record=true
Selektor: app=nginx
Replikate: 3 erwünscht | 3 aktualisiert | 3 insgesamt | 3 verfügbar | 0 nicht verfügbar
Strategietyp: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25 % max. nicht verfügbar, 25 % max. Anstieg
Pod-Vorlage:
  Beschriftungen: app=nginx
  Behälter:
   nginx:
    Bild: nginx
    Anschluss: 80/TCP
    Host-Port: 0/TCP
    Umgebung: <keine>
    Reittiere: <keine>
  Bände: <keine>

Sie können auch den Parameter –to-revision verwenden, um eine historische Version anzugeben:

[root@master ~]# kubectl rollout undo Bereitstellung/nginx-Bereitstellung --to-revision=2
deployment.apps/nginx-deployment zurückgesetzt

[root@master ~]# kubectl beschreibt die Bereitstellung/nginx-Bereitstellung
Name: nginx-Bereitstellung
Namespace: Standard
Erstellungszeitstempel: Fr, 24. Dez. 2021 22:24:10 +0800
Beschriftungen: <keine>
Anmerkungen: deployment.kubernetes.io/revision: 4
                        kubernetes.io/change-cause: kubectl erstellen --filename=deploy.yml --record=true
Selektor: app=nginx
Replikate: 3 erwünscht | 3 aktualisiert | 4 insgesamt | 3 verfügbar | 1 nicht verfügbar
Strategietyp: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25 % max. nicht verfügbar, 25 % max. Anstieg
Pod-Vorlage:
  Beschriftungen: app=nginx
  Behälter:
   nginx:
    Bild: nginx:1.9.1
    Anschluss: 80/TCP
    Host-Port: 0/TCP
    Umgebung: <keine>
    Reittiere: <keine>
  Bände: <keine>

Sie können die Option .spec.revisonHistoryLimit festlegen, um anzugeben, wie viele Revisionsverläufe eine Bereitstellung beibehalten soll. Standardmäßig werden alle Revisionen beibehalten. Wenn diese Option auf 0 gesetzt ist, ist kein Rollback der Bereitstellung zulässig.

Eine Revision wird nur erstellt, wenn ein Deployment-Rollout ausgelöst wird! Beachten! Ein Rollout wird genau dann ausgelöst, wenn die Pod-Vorlage einer Bereitstellung geändert wird, z. B. durch Aktualisieren der Bezeichnung und des Container-Image in der Vorlage, wodurch eine neue Revision für die Bereitstellung erstellt wird.

Weitere Verwendung des Rollout-Befehls:

• Verlauf (historische Versionen anzeigen)
• Pause
• fortsetzen (eine unterbrochene Bereitstellung fortsetzen)
• Status (Ressourcenstatus prüfen)
• Rückgängig machen (Rollback-Version)

Der Job Controller ist dafür verantwortlich, Pods entsprechend der Job-Spezifikation zu erstellen und den Status der Pods kontinuierlich zu überwachen, bis sie erfolgreich abgeschlossen sind. Wenn dies fehlschlägt, wird die Neustartrichtlinie (nur „OnFailure“ und „Never“ werden unterstützt, „Always“ wird nicht unterstützt) verwendet, um zu entscheiden, ob ein neuer Pod erstellt und die Aufgabe erneut versucht werden soll.

Ein Job ist für die Batch-Verarbeitung kurzlebiger, einmaliger Aufgaben zuständig, also Aufgaben, die nur einmal ausgeführt werden. Er stellt sicher, dass ein oder mehrere Pods der Batch-Aufgabe erfolgreich abgeschlossen werden.

Kubernetes unterstützt die folgenden Jobtypen:

• Nicht paralleler Job: Erstellt normalerweise einen Pod, bis er erfolgreich abgeschlossen wird.
• Job mit einer festen Anzahl von Abschlüssen: Setzen Sie .spec.completions und erstellen Sie mehrere Pods, bis .spec.completions Pods erfolgreich abgeschlossen sind
• Paralleler Job mit Arbeitswarteschlange: Legen Sie .spec.Parallelism fest, aber nicht .spec.completions. Der Job gilt als erfolgreich, wenn alle Pods abgeschlossen sind und mindestens einer erfolgreich ist.
• Entsprechend den Einstellungen von .spec.completions und .spec.Parallelism können Jobs in die folgenden Muster unterteilt werden:

.job-Nutzung [root@master ~]# vi job.yml 
---
API-Version: batch/v1
Art: Arbeit
Metadaten:
  Name: meinJob
Spezifikation:
  Vorlage:
    Spezifikation:
      Behälter:
      - Name: meinJob
        Bild: busybox
        Befehl: ["Echo", "Hallo K8s-Job"]
      restartPolicy: Niemals


[root@master ~]# kubectl apply -f job.yml 
job.batch/myjob erstellt
[root@master ~]# kubectl get pods
NAME BEREIT STATUS NEUSTART ALTER
myjob-gq27p 0/1 Abgeschlossen 0 37s

#Aufgaben dieses Pods anzeigen [root@master ~]# kubectl get job
NAME FERTIGSTELLUNGEN DAUER ALTER
meinJob 1/1 19s 5m11s

#Protokoll dieses Pods anzeigen [root@master ~]# kubectl logs myjob-gq27p
hallo k8s job

CronJob Controller

CronJob kann verwendet werden, um geplante Aufgaben basierend auf einem Zeitplan auszuführen, ähnlich wie Crontable (öffnet neues Fenster) in Linux/Unix-Systemen.

CronJob ist sehr nützlich für die Ausführung regelmäßig wiederkehrender Aufgaben, wie etwa das Sichern von Daten, das Senden von E-Mails usw. Mit CronJob können Sie außerdem einen zukünftigen Zeitpunkt für die Ausführung einer einzelnen Aufgabe festlegen. So können Sie beispielsweise die Ausführung einer Aufgabe planen, wenn die Systemlast relativ gering ist.

Ein CronJob-Objekt ist wie eine Zeile in einer Crontab-Datei (Cron-Tabelle). Es ist im Cron-Format geschrieben und führt den Job regelmäßig zu einem bestimmten geplanten Zeitpunkt aus.

Beachten:

• Alle CronJob-Zeitpläne: Die Zeiten basieren auf der Zeitzone des Kube-Controller-Managers.
• Wenn Ihre Steuerebene den Kube-Controller-Manager in einem Pod oder Bare-Container ausführt, bestimmt die für diesen Container festgelegte Zeitzone die vom Controller des Cron-Jobs verwendete Zeitzone.
• Stellen Sie beim Erstellen eines Manifests für eine CronJob-Ressource sicher, dass der angegebene Name ein gültiger DNS-Subdomänenname ist. Der Name darf nicht länger als 52 Zeichen sein. Dies liegt daran, dass der CronJob-Controller automatisch 11 Zeichen an den angegebenen Jobnamen anhängt und die Beschränkung besteht, dass die maximale Länge eines Jobnamens 63 Zeichen nicht überschreiten darf.
• CronJob wird zum Durchführen regelmäßiger Aktionen wie beispielsweise Backups, Berichterstellung usw. verwendet. Jede dieser Aufgaben sollte so konfiguriert werden, dass sie regelmäßig wiederholt wird (z. B. täglich/wöchentlich/monatlich). Sie können das Zeitintervall definieren, in dem mit der Ausführung der Aufgabe begonnen werden soll.

Die folgende CronJob-Beispielliste druckt jede Minute die aktuelle Uhrzeit und eine Begrüßungsnachricht aus:

[root@master kubenetres]# vi cronjob.yml
---
API-Version: batch/v1beta1
Art: CronJob
Metadaten:
  Name: Hallo
Spezifikation:
  Zeitplan: "*/1 * * * *"
  Jobvorlage:
    Spezifikation:
      Vorlage:
        Spezifikation:
          Behälter:
          - Name: Hallo
            Bild: busybox
            imagePullPolicy: IfNotPresent
            Befehl:
            - /bin/sh
            - -C
            - Datum; Echo Hallo nihao
          Neustartrichtlinie: Bei Fehler

Pod-Ansicht erstellen [root@master ~]# kubectl apply -f cronjob.yml 
Warnung: batch/v1beta1 CronJob ist in v1.21+ veraltet, in v1.25+ nicht verfügbar; verwenden Sie batch/v1 CronJob
cronjob.batch/hello erstellt

#Warten Sie eine Minute, um [root@master ~] zu überprüfen. # kubectl get pods
NAME BEREIT STATUS NEUSTART ALTER
hallo-27339330-kkfxv 0/1 Abgeschlossen 0 2s

#Protokolle anzeigen [root@master ~]# kubectl logs hello-27339330-kkfxv
Fr., 24. Dezember 2021, 15:30:00 UTC
Hallo Nihao

Zusammenfassen

Dies ist das Ende dieses Artikels über die fünf Controller und ihre Verwendung in K8S. Weitere Informationen zur Verwendung von K8S-Controllern finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!