Anwendungen aktualisieren und zurücksetzen

Einführung

In diesem Lab erfahren Sie, wie Sie auf einem Kubernetes-Cluster bereitgestellte Anwendungen aktualisieren und zurücksetzen können. Sie beginnen damit, einen lokalen Kubernetes-Cluster mit Minikube einzurichten und stellen dann eine Beispiel-NGINX-Anwendung bereit. Anschließend aktualisieren Sie das Anwendungsimage und überprüfen die erfolgreiche Aktualisierung. Um Aktualisierungsfehler zu simulieren, diagnostizieren Sie Probleme und setzen dann auf eine stabile Version zurück. Abschließend passen Sie die Strategie für die schrittweise Aktualisierung in der Deployment-YAML-Datei an.

Starten Sie den Kubernetes-Cluster

In diesem Schritt erfahren Sie, wie Sie einen lokalen Kubernetes-Cluster mit Minikube starten und überprüfen können. Dies ist ein entscheidender erster Schritt bei der Einrichtung Ihrer Kubernetes-Entwicklungsumgebung.

Stellen Sie zunächst sicher, dass Sie sich im Projektverzeichnis befinden:

cd ~/project

Starten Sie den Minikube-Cluster:

minikube start

Beispielausgabe:

😄  minikube v1.29.0 on Ubuntu 22.04
✨  Automatically selected the docker driver
📌  Using Docker driver with root permissions
🔥  Creating kubernetes in kubernetes cluster
🔄  Restarting existing kubernetes cluster
🐳  Preparing Kubernetes v1.26.1 on Docker 20.10.23...
🚀  Launching Kubernetes...
🌟  Enabling addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace

Überprüfen Sie den Status des Clusters:

minikube status

Beispielausgabe:

minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

Prüfen Sie die Clusterknoten:

kubectl get nodes

Beispielausgabe:

NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   1m    v1.26.1

Wichtige Punkte zu diesem Schritt:

minikube start erstellt einen lokalen Ein-Knoten-Kubernetes-Cluster.
Der Cluster verwendet Docker als Standardtreiber.
Kubernetes v1.26.1 wird automatisch konfiguriert.
minikube status und kubectl get nodes bestätigen die Betriebsbereitschaft des Clusters.

Eine Beispielanwendung bereitstellen

In diesem Schritt erfahren Sie, wie Sie eine einfache Webanwendung mithilfe eines Kubernetes-Deployments erstellen und bereitstellen können. Wir verwenden ein NGINX-Image als Beispielanwendung, um den Bereitstellungsprozess zu veranschaulichen.

Navigieren Sie zunächst zum Projektverzeichnis:

cd ~/project
mkdir -p k8s-manifests
cd k8s-manifests

Erstellen Sie ein neues Deployment-Manifest für eine Webanwendung:

nano nginx-deployment.yaml

Fügen Sie der Datei den folgenden Inhalt hinzu:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.23.3-alpine
          ports:
            - containerPort: 80

Speichern Sie die Datei und verlassen Sie den nano-Editor.

Stellen Sie die Anwendung mit kubectl bereit:

kubectl apply -f nginx-deployment.yaml

Beispielausgabe:

deployment.apps/web-app created

Überprüfen Sie das Deployment:

kubectl get deployments

Beispielausgabe:

NAME      READY   UP-TO-DATE   AVAILABLE   AGE
web-app   3/3     3            3           30s

Prüfen Sie die erstellten Pods:

kubectl get pods -l app=web

Beispielausgabe:

NAME                      READY   STATUS    RESTARTS   AGE
web-app-xxx-yyy           1/1     Running   0          45s
web-app-xxx-zzz           1/1     Running   0          45s
web-app-xxx-www           1/1     Running   0          45s

Wichtige Punkte zu dieser Bereitstellung:

Wir haben ein Deployment mit 3 Replikaten eines NGINX-Webservers erstellt.
Wir haben eine bestimmte, stabile Version von NGINX (1.23.3-alpine) verwendet.
Wir haben den Containerport 80 freigegeben.
Wir haben Labels verwendet, um die Pods zu identifizieren und zu verwalten.

Aktualisieren Sie das Anwendungsimage in der Deployment-YAML-Datei

In diesem Schritt erfahren Sie, wie Sie das Container-Image in einem Kubernetes-Deployment aktualisieren können, um ein reales Szenario für die Aktualisierung einer Anwendung zu simulieren.

Stellen Sie zunächst sicher, dass Sie sich im richtigen Verzeichnis befinden:

cd ~/project/k8s-manifests

Öffnen Sie das vorhandene Deployment-Manifest:

nano nginx-deployment.yaml

Aktualisieren Sie das Image von nginx:1.23.3-alpine auf eine neuere Version:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.24.0-alpine
          ports:
            - containerPort: 80

Wenden Sie das aktualisierte Deployment an:

kubectl apply -f nginx-deployment.yaml

Beispielausgabe:

deployment.apps/web-app configured

Beobachten Sie den Aktualisierungsprozess des Deployments:

kubectl rollout status deployment web-app

Beispielausgabe:

Waiting for deployment "web-app" to roll out...
Waiting for deployment spec update to be applied...
Waiting for available replicas to reach desired number...
deployment "web-app" successfully rolled out

Überprüfen Sie die neue Image-Version:

kubectl get pods -l app=web -o jsonpath='{.items[*].spec.containers[0].image}'

Beispielausgabe:

nginx:1.24.0-alpine nginx:1.24.0-alpine nginx:1.24.0-alpine

Wichtige Punkte zur Image-Aktualisierung:

Verwenden Sie kubectl apply, um Deployments zu aktualisieren.
Kubernetes führt standardmäßig eine schrittweise Aktualisierung (rolling update) durch.
Pods werden schrittweise ersetzt, um die Verfügbarkeit der Anwendung aufrechtzuerhalten.
Der Aktualisierungsprozess gewährleistet eine wartungsfreie (zero-downtime) Bereitstellung.

Überprüfen Sie die erfolgreiche Aktualisierung

In diesem Schritt erfahren Sie, wie Sie die erfolgreiche Aktualisierung Ihres Kubernetes-Deployments überprüfen können, indem Sie die Pod-Versionen, den Status und weitere Details des Deployments untersuchen.

Listen Sie zunächst die Pods mit detaillierten Informationen auf:

kubectl get pods -l app=web -o wide

Beispielausgabe:

NAME                      READY   STATUS    RESTARTS   AGE   IP           NODE       NOMINATED NODE   READINESS GATES
web-app-xxx-yyy           1/1     Running   0          3m    10.244.0.5   minikube   <none>           <none>
web-app-xxx-zzz           1/1     Running   0          3m    10.244.0.6   minikube   <none>           <none>
web-app-xxx-www           1/1     Running   0          3m    10.244.0.7   minikube   <none>           <none>

Prüfen Sie die spezifischen Image-Versionen der Pods:

kubectl get pods -l app=web -o jsonpath='{range.items[*]}{.metadata.name}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

Beispielausgabe:

web-app-xxx-yyy    nginx:1.24.0-alpine
web-app-xxx-zzz    nginx:1.24.0-alpine
web-app-xxx-www    nginx:1.24.0-alpine

Beschreiben Sie das Deployment, um detailliertere Informationen zu erhalten:

kubectl describe deployment web-app

Beispielausgabe:

Name:                   web-app
Namespace:              default
CreationTimestamp:      [current timestamp]
Labels:                 app=web
Annotations:            deployment.kubernetes.io/revision: 2
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=web
  Containers:
   nginx:
    Image:        nginx:1.24.0-alpine
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable

Überprüfen Sie die Rollout-Geschichte:

kubectl rollout history deployment web-app

Beispielausgabe:

REVISION  CHANGE-CAUSE
1         <none>
2         <none>

Wichtige Punkte zur Überprüfung:

Alle Pods verwenden die neue Image-Version.
Das Deployment hat 3 verfügbare Replikate.
Die Rollout-Strategie gewährleistet wartungsfreie (zero-downtime) Aktualisierungen.
Die Deployment-Revision wurde erhöht.

Simulieren und diagnostizieren von Aktualisierungsfehlern

In diesem Schritt erfahren Sie, wie Sie potenzielle Fehler bei der Aktualisierung eines Deployments diagnostizieren können, indem Sie eine problematische Image-Aktualisierung simulieren und Kubernetes-Diagnosetools verwenden.

Navigieren Sie zunächst zum Projektverzeichnis:

cd ~/project/k8s-manifests

Erstellen Sie ein Deployment-Manifest mit einem ungültigen Image:

nano problematic-deployment.yaml

Fügen Sie den folgenden Inhalt hinzu:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: troubleshoot-app
  labels:
    app: troubleshoot
spec:
  replicas: 3
  selector:
    matchLabels:
      app: troubleshoot
  template:
    metadata:
      labels:
        app: troubleshoot
    spec:
      containers:
        - name: nginx
          image: nginx:non-existent-tag
          ports:
            - containerPort: 80

Wenden Sie das problematische Deployment an:

kubectl apply -f problematic-deployment.yaml

Beispielausgabe:

deployment.apps/troubleshoot-app created

Überprüfen Sie den Status des Deployments:

kubectl rollout status deployment troubleshoot-app

Beispielausgabe:

Waiting for deployment "troubleshoot-app" to roll out...

Drücken Sie Ctrl+C, um den Rollout-Status zu beenden.

Überprüfen Sie die Pod-Ereignisse und den Status:

kubectl get pods -l app=troubleshoot

Beispielausgabe:

NAME                              READY   STATUS             RESTARTS   AGE
troubleshoot-app-6b8986c555-gcjj9   0/1     ImagePullBackOff   0          2m56s
troubleshoot-app-6b8986c555-p29dp   0/1     ImagePullBackOff   0          2m56s
troubleshoot-app-6b8986c555-vpv5q   0/1     ImagePullBackOff   0          2m56s

Untersuchen Sie die Pod-Details und die Logs:

## Replace 'xxx-yyy' with your actual pod name
POD_NAME=$(kubectl get pods -l app=troubleshoot -o jsonpath='{.items[0].metadata.name}')
kubectl describe pod $POD_NAME
kubectl logs $POD_NAME

Sie werden den Pod-Status und die Logs sehen, die auf ein fehlgeschlagenes Image-Pull hinweisen.

Failed to pull image "nginx:non-existent-tag"

Beheben Sie das Problem, indem Sie das Image korrigieren:

nano problematic-deployment.yaml

Aktualisieren Sie das Image auf einen gültigen Tag:

image: nginx:1.24.0-alpine

Wenden Sie das korrigierte Deployment erneut an:

kubectl apply -f problematic-deployment.yaml

Überprüfen Sie erneut den Pod-Status:

kubectl get pods -l app=troubleshoot

Beispielausgabe:

NAME                                READY   STATUS    RESTARTS   AGE
troubleshoot-app-5dc9b58d57-bvqbr   1/1     Running   0          5s
troubleshoot-app-5dc9b58d57-tdksb   1/1     Running   0          8s
troubleshoot-app-5dc9b58d57-xdq5n   1/1     Running   0          6s

Wichtige Punkte zur Diagnose von Fehlern:

Verwenden Sie kubectl describe, um Deployment- und Pod-Ereignisse anzuzeigen.
Überprüfen Sie den Pod-Status auf ImagePullBackOff oder andere Fehlerzustände.
Untersuchen Sie die Pod-Logs für detaillierte Fehlerinformationen.
Vergewissern Sie sich, dass das Image verfügbar ist und der Tag korrekt ist.

Rückgängig machen auf eine stabile Version

In diesem Schritt erfahren Sie, wie Sie ein Kubernetes-Deployment mithilfe des Befehls kubectl rollout undo auf eine frühere stabile Version zurücksetzen können.

Navigieren Sie zunächst zum Projektverzeichnis:

cd ~/project/k8s-manifests

Überprüfen Sie die Rollout-Geschichte der Webanwendung:

kubectl rollout history deployment web-app

Beispielausgabe:

REVISION  CHANGE-CAUSE
1         <none>
2         <none>

Verifizieren Sie die aktuellen Deployment-Details:

kubectl describe deployment web-app | grep Image

Beispielausgabe:

    Image:        nginx:1.24.0-alpine

Führen Sie die Rücksetzung auf die vorherige Revision durch:

kubectl rollout undo deployment web-app

Beispielausgabe:

deployment.apps/web-app rolled back

Verifizieren Sie die Rücksetzung:

kubectl rollout status deployment web-app

Beispielausgabe:

Waiting for deployment "web-app" to roll out...
deployment "web-app" successfully rolled out

Überprüfen Sie die aktualisierte Image-Version:

kubectl get pods -l app=web -o jsonpath='{range.items[*]}{.metadata.name}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

Beispielausgabe:

web-app-xxx-yyy    nginx:1.23.3-alpine
web-app-xxx-zzz    nginx:1.23.3-alpine
web-app-xxx-www    nginx:1.23.3-alpine

Bestätigen Sie die Rollout-Geschichte:

kubectl rollout history deployment web-app

Beispielausgabe:

REVISION  CHANGE-CAUSE
2         <none>
3         <none>

Wichtige Punkte zur Rücksetzung:

kubectl rollout undo setzt das Deployment auf die vorherige Revision zurück.
Kubernetes behält eine Geschichte der Deployment-Änderungen bei.
Die Rücksetzung erfolgt ohne Ausfallzeit (zero downtime).
Die Rücksetzung erstellt eine neue Revision in der Geschichte.

Anpassen der Rolling-Update-Strategie in der Deployment-YAML-Datei

In diesem Schritt erfahren Sie, wie Sie die Rolling-Update-Strategie in einem Kubernetes-Deployment anpassen können, um zu steuern, wie Anwendungen aktualisiert und skaliert werden.

Navigieren Sie zunächst zum Projektverzeichnis:

cd ~/project/k8s-manifests

Erstellen Sie ein neues Deployment-Manifest mit einer benutzerdefinierten Rolling-Update-Strategie:

nano custom-rollout-deployment.yaml

Fügen Sie den folgenden Inhalt hinzu:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app-custom-rollout
  labels:
    app: web
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 2
      maxSurge: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.24.0-alpine
          ports:
            - containerPort: 80

Wenden Sie das Deployment an:

kubectl apply -f custom-rollout-deployment.yaml

Beispielausgabe:

deployment.apps/web-app-custom-rollout created

Überprüfen Sie den Status des Deployments:

kubectl rollout status deployment web-app-custom-rollout

Beispielausgabe:

Waiting for deployment "web-app-custom-rollout" to roll out...
deployment "web-app-custom-rollout" successfully rolled out

Beschreiben Sie das Deployment, um die Strategie zu bestätigen:

kubectl describe deployment web-app-custom-rollout

Die Beispielausgabe wird Folgendes enthalten:

StrategyType:           RollingUpdate
RollingUpdateStrategy:  2 max unavailable, 3 max surge

Aktualisieren Sie das Image, um ein Rolling Update auszulösen:

kubectl set image deployment/web-app-custom-rollout nginx=nginx:1.25.0-alpine

Überwachen Sie den Aktualisierungsprozess:

kubectl rollout status deployment web-app-custom-rollout

Wichtige Punkte zur Rolling-Update-Strategie:

maxUnavailable: Maximale Anzahl von Pods, die während der Aktualisierung nicht verfügbar sein dürfen.
maxSurge: Maximale Anzahl von Pods, die über die gewünschte Anzahl hinaus erstellt werden können.
Hilft bei der Steuerung der Aktualisierungsgeschwindigkeit und der Anwendungsverfügbarkeit.
Ermöglicht die Feinabstimmung des Deployment-Verhaltens.

Zusammenfassung

In diesem Lab haben Sie gelernt, wie Sie einen lokalen Kubernetes-Cluster mit Minikube starten und überprüfen können. Dies ist ein entscheidender erster Schritt bei der Einrichtung Ihrer Kubernetes-Entwicklungsumgebung. Sie haben auch gelernt, wie Sie eine einfache Webanwendung mithilfe eines Kubernetes-Deployments erstellen und bereitstellen können, wobei ein NGINX-Image als Beispielanwendung verwendet wurde. Der Bereitstellungsprozess umfasste das Erstellen einer Deployment-Manifestdatei und das Anwenden dieser auf den Cluster.

Nach der Bereitstellung der ersten Version der Anwendung haben Sie gelernt, wie Sie das Anwendungsimage in der Deployment-YAML-Datei aktualisieren, die erfolgreiche Aktualisierung überprüfen, Aktualisierungsfehler simulieren und diagnostizieren, auf eine stabile Version zurücksetzen und die Rolling-Update-Strategie in der Deployment-YAML-Datei anpassen können.