apiVersion: apps/v1

Art: Bereitstellung

Metadaten:

Etiketten:

ausführen: nginx

Name: nginx

spezifikation:

Repliken: 3

Wähler:

matchLabels:

ausführen: nginx

Vorlage:

Metadaten:

Etiketten:

ausführen: nginx

spezifikation:

Behälter:

- Name: nginx

Bild: nginx:1.16

Aktualisierungen der Pod-Vorlage der Bereitstellung lösen eine schrittweise Aktualisierung aus. Wenn die Pod-Vorlage einer Bereitstellung aktualisiert wird, wird ein neues ReplicaSet erstellt, das dann basierend auf der aktualisierten Pod-Spezifikation neue Pods erstellt. Wenn die neuen Pods erstellt werden, wird das ReplicaSet der vorherigen Version auf Null skaliert, um die alten Pods zu entfernen. Diese Strategie wird als Rolling Update bezeichnet.

Im folgenden Beispiel wird eine Bereitstellung von nginx-Pods mit 3 Replikaten erstellt. Die Option --record versieht den kubectl-Befehl mit Anmerkungen und speichert ihn zum späteren Nachschlagen. Rollout-Status und Verlauf der Bereitstellung werden mit kubectl rollout überprüft.

$ kubectl Create Deployment nginx --image=nginx:1.16 --replicas=3 --record

Bereitstellung.apps/nginx erstellt

$ kubectl Rollout-Status Bereitstellen von nginx

Deployment "nginx" erfolgreich ausgerollt

$ kubectl Rollout-Verlauf stellt nginx bereit

Bereitstellung.apps/nginx

REVISION ÄNDERUNG-URSACHE

1 kubectl Create Deployment nginx --image=nginx:1.16 --replicas=3 --record=true

$

Da die Option --record zum Erstellen des Deployments verwendet wurde, wird die Anmerkung in der Spalte CHANGE-CAUSE aufgeführt. Wenn --record nicht zum Annotieren verwendet wurde, würde keiner unter CHANGE-CAUSE für Revision 1 erscheinen.



Aktualisieren Sie als Nächstes die Bereitstellung, um das nginx-Image der Version 1.17 zu verwenden. Dieses Update löst ein rollierendes Update aus. Ein neues ReplicaSet wird erstellt und die Pods unter alten ReplicaSets werden beendet (skaliert auf 0). Überprüfen Sie nach dem Aktualisieren der Bereitstellung sofort den Rollout-Status, um das rollierende Update zu erfassen.

$ kubectl set image deploy nginx nginx=nginx:1.17 --record

Bereitstellung.apps/nginx-Image aktualisiert

$ kubectl Rollout-Status Bereitstellen von nginx

Warten auf den Abschluss der Bereitstellung von "nginx"-Rollout: 2 von 3 neuen Replikaten wurden aktualisiert ...

Warten auf den Abschluss der Bereitstellung von "nginx"-Rollout: 2 von 3 neuen Replikaten wurden aktualisiert ...

Warten auf den Abschluss der Bereitstellung von "nginx"-Rollout: 2 von 3 neuen Replikaten wurden aktualisiert ...

Warten auf den Abschluss der Bereitstellung von "nginx"-Rollout: 1 alte Replikate stehen vor der Beendigung...

Warten auf den Abschluss der Bereitstellung von "nginx"-Rollout: 1 alte Replikate stehen vor der Beendigung...

Deployment "nginx" erfolgreich ausgerollt

$

Kubernetes ermöglicht es Benutzern, Bereitstellungsupdates rückgängig zu machen. Bereitstellungen können mit kubectl rollout undo deploy auf eine frühere Version zurückgesetzt werden, oder Sie können eine bestimmte Revision angeben.

Betrachten wir anhand des vorherigen Beispiels die verfügbaren Revisionen.

$ kubectl Rollout rückgängig machen nginx bereitstellen --to-revision=1

Bereitstellung.apps/nginx wurde zurückgesetzt

$ kubectl Rollout-Status Bereitstellen von nginx

Warten auf den Abschluss der Bereitstellung von "nginx"-Rollout: 2 von 3 neuen Replikaten wurden aktualisiert ...

Warten auf den Abschluss der Bereitstellung von "nginx"-Rollout: 2 von 3 neuen Replikaten wurden aktualisiert ...

Warten auf den Abschluss der Bereitstellung von "nginx"-Rollout: 2 von 3 neuen Replikaten wurden aktualisiert ...

Warten auf den Abschluss der Bereitstellung von "nginx"-Rollout: 1 alte Replikate stehen vor der Beendigung...

Warten auf den Abschluss der Bereitstellung von "nginx"-Rollout: 1 alte Replikate stehen vor der Beendigung...

Deployment "nginx" erfolgreich ausgerollt

$ kubectl Rollout-Verlauf stellt nginx bereit

Bereitstellung.apps/nginx

REVISION ÄNDERUNG-URSACHE

2 kubectl set image deploy nginx nginx=nginx:1.17 --record=true

3 kubectl Create Deployment nginx --image=nginx:1.16 --replicas=3 --record=true

$

Das Deployment verwendet wieder das nginx 1.16-Image.

Jobs und CronJobs

Jobs erledigen Aufgaben von Anfang bis Ende. Ein Job ist abgeschlossen, wenn der Pod die Aufgabe beendet und der Pod nach Abschluss erfolgreich beendet wird. Es gibt drei Arten von Jobs:

Nicht parallele Jobs – ein Job, der einen Pod ausführtParallele Jobs mit festem Abschluss – Jobs führen mehrere Pods parallel aus und definiert die Anzahl der Abschlüsse, wenn der Job beendet istParallele Jobs ohne festen Abschluss – Jobs führen mehrere Pods parallel aus und wenn ein Pod ist erfolgreich, dann ist der Job abgeschlossen und alle anderen Pods werden beendet; dies wird auch als Arbeitswarteschlange bezeichnet

Das folgende Manifest beschreibt einen parallelen Job mit einer festen Anzahl von Abschlüssen. Der Job gibt das Datum an die Standardausgabe des Containers aus. Der Job führt 5 Pods parallel aus und wird nach 20 erfolgreichen Abschlüssen beendet.

apiVersion: Batch/v1

Art: Job

Metadaten:

Name: Datum-Job

spezifikation:

Parallelität: 5

Fertigstellungen: 20

Vorlage:

Metadaten:

Name: Datum-Job

spezifikation:

Behälter:

- Name: Busybox

Bild: Busybox

Befehl:

- /bin/sh

- -C

- Datum

restartPolicy: OnFailure

Am Ende dieses Jobs wären 20 fertige Kapseln. Beim Abrufen des Containerprotokolls für einen der 20 Pods wird das Datum ausgegeben, an dem der Container ausgeführt wurde. CronJobs führen Jobs nach einem Zeitplan aus und werden verwendet, um Aufgaben zu automatisieren. Das folgende CronJob-Manifest erstellt einen CronJob, der jede Minute ausgeführt wird und das Datum an die Standardausgabe des Containers ausgibt.

apiVersion: Batch/v1beta1

Art: CronJob

Metadaten:

Name: Cron-Job

spezifikation:

Anhang 1 * * * *"

JobVorlage:

spezifikation:

Vorlage:

spezifikation:

Behälter:

- Name: Busybox

Bild: Busybox

Argumente:

- /bin/sh

- -C

- Datum

restartPolicy: OnFailure

Beschriftungen, Selektoren, Anmerkungen

JLabels sind Schlüssel/Wert-Paare, die an Kubernetes-Objekte wie Pods, persistente Volumes und Cluster-Knoten angehängt sind. Labels helfen bei der Verwaltung und Organisation von Kubernetes-Objekten in logischen Gruppen und können auch verwendet werden, um Kubernetes-Objekte für die Ausführung von Ressourcen zu qualifizieren. Eine Netzwerkrichtlinie zielt beispielsweise auf Pods im selben Namespace ab, indem sie Labels auf Pods verwendet. Einige Befehle verwenden Selektoren, um Kubernetes-Objekte anhand ihrer Labels zu identifizieren und auszuwählen. Selektoren werden mit dem Flag -l oder --selector verwendet, das nach Labels filtert. Es gibt zwei Selektortypen:

Gleichheits-/Ungleichheitsbasiert = oder == für Gleichheit != für Ungleichheit.Set-basiert in für Labels, die Schlüssel mit Werten in diesem Set haben notin für Labels, die Schlüssel nicht in diesem Set haben key_name für Labels mit dem Schlüsselnamen

Sehen Sie sich die Verwendung von Labels und Selektoren an. Führen Sie die folgenden Bereitstellungen und Jobs aus, um Pods mit einer Umgebung und einem Release-Label zu starten. Die Pods können ein Umgebungslabel von prod , dev oder qa und ein Release - Label mit stable oder edg haben . Verwenden Sie dann Selektoren, um mithilfe von Labels nach Pods zu filtern. Hinweis: Beim Erstellen von Bereitstellungen bezeichnet die erste Option -l die Bereitstellung und die zweite Option -l bezeichnet Pods.

$ kubectl run nginx-deploy --image=nginx:1.9 --replicas=5 \

-l Umgebung=Prod -l Umgebung=Prod,Release=Stable

kubectl run --generator=deployment/apps.v1 ist DEPRECATED und wird in einer zukünftigen Version entfernt. Verwenden Sie stattdessen kubectl run --generator=run-pod/v1 oder kubectl create.

Bereitstellung.apps/nginx-deploy erstellt

$ kubectl run nginx-pod --generator=run-pod/v1 --image=nginx:latest \

-l Umgebung=dev,release=edge

pod/nginx-pod erstellt

$ kubectl run nginx-qa --image=nginx:latest --replicas=3 \

-l Umgebung=qa -l Umgebung=qa,release=Kante

kubectl run --generator=deployment/apps.v1 ist DEPRECATED und wird in einer zukünftigen Version entfernt. Verwenden Sie stattdessen kubectl run --generator=run-pod/v1 oder kubectl create.

Bereitstellung.apps/nginx-qa erstellt

$

Jetzt haben wir 9 Pods am Laufen.

$ kubectl Pods erhalten

NAME BEREIT STATUS NEU STARTET ALTER

nginx-deploy-86f8b8c8d4-8j78k 1/1 Läuft 0 21s

nginx-deploy-86f8b8c8d4-cbsbz 1/1 Läuft 0 21s

nginx-deploy-86f8b8c8d4-jq2cb 1/1 Läuft 0 21s

nginx-deploy-86f8b8c8d4-l8ck8 1/1 Läuft 0 21s

nginx-deploy-86f8b8c8d4-smfmf 1/1 Läuft 0 21s

nginx-pod 1/1 Läuft 0 14s

nginx-qa-55d6b56d5c-fssmn 1/1 Läuft 0 8s

nginx-qa-55d6b56d5c-mmsp9 1/1 Läuft 0 8s

nginx-qa-55d6b56d5c-xlks7 1/1 Läuft 0 8s

$

Lassen Sie uns Selektoren verwenden, um Labels zu filtern, um die entsprechenden Pods zu identifizieren, nach denen wir suchen. Holen wir uns Pods, die nicht in Produktion sind

$ kubectl get pod -l Umgebung!=prod --show-labels

NAME BEREIT STATUS NEU STARTET ALTERETIKETTEN

nginx-pod 1/1 Läuft 0 67s environment=dev,release=edge

nginx-qa-55d6b56d5c-fssmn 1/1 Wird ausgeführt 0 61s environment=qa,pod-template-hash=55d6b56d5c,release=edge

nginx-qa-55d6b56d5c-mmsp9 1/1 Wird ausgeführt 0 61s environment=qa,pod-template-hash=55d6b56d5c,release=edge

nginx-qa-55d6b56d5c-xlks7 1/1 Wird ausgeführt 0 61s environment=qa,pod-template-hash=55d6b56d5c,release=edge

$

Wir können auch Nicht-Produktions-Pods mit satzbasierten Anforderungen abrufen:

$ kubectl get pods -l "environment notin (prod)" --show-labels

NAME BEREIT STATUS NEU STARTET ALTERETIKETTEN

nginx-pod 1/1 Läuft 0 84s environment=dev,release=edge

nginx-qa-55d6b56d5c-fssmn 1/1 Läuft 0 78s environment=qa,pod-template-hash=55d6b56d5c,release=edge

nginx-qa-55d6b56d5c-mmsp9 1/1 Läuft 0 78s environment=qa,pod-template-hash=55d6b56d5c,release=edge

nginx-qa-55d6b56d5c-xlks7 1/1 Läuft 0 78s environment=qa,pod-template-hash=55d6b56d5c,release=edge

$

Die Verwendung des Kommas als Trennzeichen verhält sich wie ein logischer und ( && ) Operator. Das folgende Beispiel listet Pods in der Entwicklungsumgebung und mit einem Edge-Release auf:

$ kubectl get pods -l environment=dev,release=edge --show-labels

NAME BEREIT STATUS NEU STARTET ALTERETIKETTEN

nginx-pod 1/1 Läuft 0 108s environment=dev,release=edge

$

Anmerkungen ähneln Labels insofern, als es sich um Metadaten-Schlüssel/Wert-Paare handelt. Anmerkungen unterscheiden sich von Beschriftungen dadurch, dass sie nicht für die Objektauswahl verwendet werden, sondern in der Regel von externen Anwendungen verwendet werden. Anmerkungen können von API-Clients, Tools und Bibliotheken abgerufen werden. Anmerkungen werden im Manifest erstellt. Das folgende Beispiel ist ein Pod-Manifest mit Anmerkungen für Build- und Image-Informationen.

apiVersion: v1

Art: Pod

Metadaten:

Name: hostinfo

Anmerkungen:

bauen auf

Builder: rxmllc

Bildregister: „https://hub.docker.com/r/rxmllc/hostinfo“

spezifikation:

Behälter:

- Name: Hostinfo

Bild: rxmllc/hostinfo

Neustart-Richtlinie: Nie

Ansprüche auf dauerhaftes Volumen

Ein persistentes Kubernetes-Volume existiert außerhalb des Lebenszyklus eines Pods, der es mountet. Persistente Volumes sind Speicherobjekte, die vom Kubernetes-Cluster verwaltet und von der Infrastruktur des Clusters (wie dem Dateisystem des Hosts) bereitgestellt werden. Persistente Volumes beschreiben Details einer Speicherimplementierung für den Cluster, einschließlich:

Zugriffsmodi für das VolumeDie Gesamtkapazität des VolumesWas mit den Daten passiert, nachdem das Volume nicht beansprucht wurdeDie Art des SpeichersEine optionale, benutzerdefinierte Speicherklassen-ID

Ansprüche auf persistente Volumes sind eine Abstraktion von persistenten Volumes. Ein Anspruch auf ein persistentes Volume ist eine Speicheranforderung. Ansprüche auf persistente Volumes binden an vorhandene persistente Volumes aufgrund einer Reihe von Faktoren wie Label-Selektoren, Speicherklassenname, Speicherkapazität und Zugriffsmodus. Ansprüche auf persistente Datenträger können unter Verwendung einer vorhandenen Speicherklasse dynamisch persistente Datenträger erstellen. Pods binden über den Namen im Manifest des Pods an persistente Volume-Ansprüche. Sehen wir uns an, wie Pods an einen persistenten Volume-Anspruch und wie ein persistenter Volume-Anspruch an ein persistentes Volume binden. Das folgende Manifest gilt für ein persistentes Volume mit den folgenden Merkmalen:

Label von k8scluster: masterStorage-Klassenname ist localStorage-Kapazität ist 200MiOne-Knoten können das Volume als Lese-/Schreibzugriff mounten (Zugriffsmodus = ReadWriteOnce) Das persistente Volume wird freigegeben, wenn ein begrenzter persistenter Volume-Anspruch gelöscht wird, aber nicht verfügbar, bis das persistente Volume gelöscht wird ( persistentVolumeReclaimPolicy = Retain) Auf einem Hostpfad von /home/ubuntu/persistentvolume eingehängt.

apiVersion: v1

Art: PersistentVolume

Metadaten:

Name: lokales Volumen

Etiketten:

k8scluster: Meister

spezifikation:

storageClassName: local

Kapazität:

Lagerung: 200Mi

Zugriffsmodi:

- ReadWriteOnce

persistentVolumeReclaimPolicy: Beibehalten

hostPfad:

Pfad: /home/ubuntu/persistentvolume

Im obigen Beispiel kann ein Anspruch auf einen persistenten Datenträger eines oder mehrere der folgenden Elemente verwenden, um sich an den persistenten Datenträger zu binden: Label, Name der Speicherklasse, Speicherkapazität und Zugriffsmodus. Das folgende Beispiel beschreibt einen persistenten Datenträgeranspruch, der an den persistenten Datenträger 'local-volume' bindet, indem ein Selektor verwendet wird, um das Label k8scluster:master , den lokalen Speicherklassennamen und die passende Speicherkapazität und den Zugriffsmodus auszuwählen.

apiVersion: v1

Art: PersistentVolumeClaim

Metadaten:

Name: local-pvc

spezifikation:

Zugriffsmodi:

- ReadWriteOnce

Ressourcen:

Anfragen:

Lagerung: 200Mi

storageClassName: local

Wähler:

matchLabels:

k8scluster: Meister

Lassen Sie uns nun einen Pod erstellen, der an den persistenten Volume-Anspruch bindet. Das folgende Pod-Manifest bindet sich namentlich an den persistenten Volume-Anspruch und stellt das Volume im Verzeichnis /usr/share/nginx/html des Containers bereit.

apiVersion: v1

Art: Pod

Metadaten:

Name: nginx

spezifikation:

Behälter:

- Name: nginx

Bild: nginx:neueste

volumeMounts:

- Name: Daten

mountPath: /usr/share/nginx/html

Bände:

- Name: Daten

persistentVolumeClaim:

ClaimName: local-pvc

Nachdem Sie diesen Pod erstellt haben. Überprüfen Sie die Bindung, indem Sie den persistenten Volume-Anspruch und das grep für „Mounted By“ beschreiben und dann den Pod und das grep für „Volumes“ beschreiben.

$ kubectl beschreiben pvc local-pvc | grep „Bereitet von“

Montiert von: nginx

$ kubectl beschreiben pod nginx | grep -A3-Bände

Volumen:

Daten:

Typ: PersistentVolumeClaim (ein Verweis auf einen PersistentVolumeClaim im gleichen Namespace)

ClaimName: local-pvc

$

Übungsübung

Erstellen Sie ein Deployment, das 2 Pod-Replikate mit dem nginx:1.9-Image erstellt.