$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

Rollen und ClusterRoles werden Benutzern und Prozessen mithilfe von RoleBindings und ClusterRoleBindings zugewiesen. RoleBindings verknüpfen einen Benutzer wie ein Dienstkonto mit einer Rolle. Alle von einer Rolle gewährten Berechtigungen werden über die RoleBinding an den Benutzer weitergegeben. Rollenbindungen können auch zwingend mit kubectl create rolebinding erstellt werden. Rolebindings binden Rollen mit dem Flag --user und serviceAccounts mit dem Flag --serviceaccount an Benutzer. Im folgenden Beispiel wird die Rolle default-appmanager an das Standarddienstkonto des Standard-Namespace gebunden:

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 unter CHANGE-CAUSE für Revision 1 keines erscheinen. Als nächstes aktualisieren Sie das Deployment, 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

$

Bereitstellungen und Rollbacks

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-Verlauf stellt nginx bereit

Bereitstellung.apps/nginx

REVISION ÄNDERUNG-URSACHE

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

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

$

Das Update des Deployments befindet sich jetzt in Revision 2. Wenn --record nicht zum Annotieren verwendet wurde, wird in der Spalte CHANGE-CAUSE keines aufgeführt. Als nächstes machen wir den Rollout zu einer bestimmten Revision rückgängig, beobachten den Status und überprüfen den Rollout-Verlauf.

$ 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.

Anwendungen konfigurieren

Es gibt mehrere Möglichkeiten, Anwendungen zu konfigurieren, die unter Kubernetes ausgeführt werden. Eine Möglichkeit besteht darin, den Befehl und die Argumente, die im Container ausgeführt werden, mithilfe der Befehls- und Args-Arrays in einer yaml-Datei zu ändern:

apiVersion: v1

Art: Pod

Metadaten:

Etiketten:

ausführen: busybox

Name: Busybox

spezifikation:

Behälter:

- Befehl:

- /bin/sh

Argumente:

- -C

-tail -f /dev/null

Bild: Busybox

Name: Busybox

Anwendungskonfigurationen und Anmeldeinformationen können im Cluster als ConfigMap- oder Secret-Ressourcen gespeichert werden. Container, die in Pods ausgeführt werden, können ConfigMaps und Secrets als Volumes oder Umgebungsvariablen verwenden. ConfigMaps können aus literalen Schlüssel-Wert-Paaren oder aus Dateien erstellt werden. Im Folgenden erstellen wir eine ConfigMap aus einer Redis-Konfigurationsdatei auf der Festplatte.

$ cat redis.conf

binden 127.0.0.1

geschützter Modus ja

Port 6379

TCP-Rückstand 511

Zeitüberschreitung 0

TCP-Keepalive 300

$ kubectl create configmap --from-file redis.conf redisconf

configmap/redisconf erstellt

$ kubectl beschreiben configmap redisconf

Name: redisconf

Namensraum: Standard

Etiketten:

Anmerkungen:

Daten

====

redis.conf:

----

binden 127.0.0.1

geschützter Modus ja

Port 6379

TCP-Rückstand 511

Zeitüberschreitung 0

TCP-Keepalive 300

Veranstaltungen:

$

Die Datei redis.conf kann jetzt von jedem Pod verwendet und gemountet werden. ConfigMaps sind eine gute Möglichkeit, allgemeine Konfigurationsdateien für Anwendungen verfügbar zu machen, die überall in einem Kubernetes-Cluster ausgeführt werden. Das folgende Beispiel zeigt einen Pod, der redis mit der Datei redis.conf ausführt, die als ConfigMap gespeichert ist:

piVersion: v1

Art: Pod

Metadaten:

Etiketten:

ausführen: redis-dev

Name: redis-dev

spezifikation:

Behälter:

- Befehl:

- Redis-Server

- /config/redis.conf

Bild: redis

Name: redis-dev

volumeMounts:

- Name: redis

mountPath: /config

Bände:

- Name: redis

configMap:

Name: redisconf

restartPolicy: OnFailure

Waagenanwendungen

Anwendungen, die mithilfe eines Controllers wie einem Deployment oder StatefulSet bereitgestellt werden, können durch Ändern der Anzahl der Replikate hoch- oder herunterskaliert werden. Das Ändern des Schlüsselwerts der Replikate in der Spezifikation des Controllers löst eine Aktualisierung des aktuellen Replikatsets der Anwendung aus, die die Anzahl der Pods erhöht (oder verringert), auf denen die Anwendung ausgeführt wird. Dies geschieht zwingend mit kubectl scale :

$ kubectl scale deploy redis-prod --replicas=3

Deployment.apps/redis-prod skaliert

$

Oder deklarativ, indem Sie die YAML-Datei des Controllers ändern und auf den Cluster anwenden:

$ nano redis-prod.yaml

apiVersion: apps/v1

Art: Bereitstellung

Metadaten:

Etiketten:

App: Rücksendeprodukt

Name: redis-prod

spezifikation:

Repliken: 5

Wähler:

matchLabels:

App: Rücksendeprodukt

Vorlage:

Metadaten:

Etiketten:

App: Rücksendeprodukt

spezifikation:

Behälter:

- Bild: redis: 4.0

Name: redis

$ kubectl apply -f redis-prod.yaml

Bereitstellung.apps/redis-prod konfiguriert

$

Selbstheilende Anwendungen

Eine selbstheilende Anwendung im Kontext von Kubernetes:

Stellt Container automatisch aus einem fehlerhaften Zustand wieder her Stellt sicher, dass zu jeder Zeit mindestens eine einzelne Kopie der Anwendung ausgeführt wirdBehalten Sie eine konsistente Netzwerkidentität bei

Benutzer können eine einfache selbstheilende Anwendung erstellen, indem sie einen Controller verwenden, um einen gewünschten Zustand (mindestens ein laufender Pod) und einen Dienst aufrechtzuerhalten, um eine konsistente Netzwerkidentität angesichts der Löschung/Neuerstellung von Pods aufrechtzuerhalten.

$ kubectl create deploy apache-prod --image httpd

Bereitstellung.apps/apache-prod erstellt

$ kubectl offenbaren deploy apache-prod --port 80

service/apache-prod ausgesetzt

$

Dadurch wird ein Deployment erstellt, das sicherstellt, dass zu jeder Zeit mindestens eine einzelne Kopie der Anwendung ausgeführt wird, und ein Dienst, der die konsistente Netzwerkidentität beibehält.

Ein in der Bereitstellungsspezifikation konfigurierter Liveness-Test bietet dem verwaltenden Kubelet des Pods eine Möglichkeit, zu überprüfen, ob die Anwendung aktiv ist.

apiVersion: apps/v1

Art: Bereitstellung

Metadaten:

Etiketten:

App: Apache-Produkt

Name: Apache-Prod

spezifikation:

FortschrittDeadlineSekunden: 600

Repliken: 1

Wähler:

matchLabels:

App: Apache-Produkt

Vorlage:

Metadaten:

CreationTimestamp: null

Etiketten:

App: Apache-Produkt

spezifikation:

Behälter:

- Bild: httpd

imagePullPolicy: Immer

livenessProbe:

Fehlerschwelle: 1

httpGet:

Weg: /

Hafen: 80

Schema: HTTP

PeriodeSekunden: 10

Erfolgsschwelle: 1

timeoutSekunden: 1

Name: httpd

Ressourcen: {}

TerminationMessagePath: /dev/termination-log

KündigungMessagePolicy: Datei

DNS-Richtlinie: ClusterFirst

Neustart-Richtlinie: Immer

Wenn livenessProbe dieser Probe jemals einen Fehler zurückgibt, weist das kubelet die Container-Laufzeit an, den Container neu zu starten und die Anwendung aus einem fehlerhaften Zustand zurückzubringen.