• Home

Kubernetes Deployments

DevOps, Kubernetes, Kubernetes Deployments

Lerne in diesem Tutorial wie du Kubernetes Deployments verwenden kannst. Du lernst, wie du Deployments skalierst und was Rolling Updates sind.

Inhaltsverzeichnis

• Voraussetzungen
• Minimales Deployment
  • Schritt 1
  • Schritt 2
  • Schritt 3
• Skalierung
  • Deployment skalieren
  • Kubernetes erhält den Zustand des Deployments
  • Replikas reduzieren
• Rolling Update
  • Events
  • Neue Version des Images
  • Rollout Status und Undo
• Fazit

Voraussetzungen

1. laufender Kubernetes Cluster
2. kubectl ist installiert und mit dem Cluster verbunden

Minimales Deployment

Schritt 1

Erstelle die Datei deployment.yaml mit folgendem Inhalt:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: web
          image: nginx:1.31.0-alpine3.23
          resources:
            requests:
              cpu: "50m"
              memory: "16Mi"
            limits:
              cpu: "50m"
              memory: "16Mi"

1. .metadata.name definiert, wie das Kubernetes Deployment heißt
2. .spec.replicas definiert wieviele Pods im Deployment gestartet werden
3. .spec.selector definiert die Labels, die die Pods des Deployments mindestens haben müssen
4. .spec.template definiert die Vorlage der Pods, die gestartet werden
5. .spec.template.metadata.labels enthält die Labels der Pods, diese Labels müssen mit .spec.selector.matchLabels übereinstimmen, damit das Deployment weiß, welche Pods es verwalten soll

Schritt 2

Erstelle das Deployment mit folgendem Befehl in deinem Kubernetes Cluster:

kubectl apply -f deployment.yaml

Kubernetes meldet sich im Erfolgsfall mit deployment.apps/nginx created zurück.

Schritt 3

Überprüfe, dass das Deployment erfolgreich erstellt wurde:

kubectl get deploy/nginx

NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   1/1     1            1           113m

In der Spalte READY ist 1/1 zu sehen, das bedeutet 1 gewünschter Pod aktiv / 1 Pod läuft tatsächlich.

Skalierung

Ein Deployment kann horizontal skaliert werden, d.h. die Anzahl der Pods kann erhöht und reduziert werden.

Deployment skalieren

Skaliere das Deployment mit diesem Befehl auf 5 Replikas:

kubectl scale deploy/nginx --replicas 5

Überprüfe sofort danach, dass die Skalierung funktioniert hat:

kubectl get pods

Du solltest jetzt 5 nginx Pods sehen, die alle den Status Running haben.

Kubernetes erhält den Zustand des Deployments

Um das Self-Healing zu testen, wähle einen dieser Pods aus und lösche ihn:

kubectl get pods

NAME                     READY   STATUS    RESTARTS   AGE
nginx-5589648df4-7qck7   1/1     Running   0          80m
nginx-5589648df4-9g952   1/1     Running   0          20s
nginx-5589648df4-jvjwc   1/1     Running   0          20s
nginx-5589648df4-pvlv7   1/1     Running   0          20s
nginx-5589648df4-sjq2s   1/1     Running   0          20s

kubectl delete pod/nginx-5589648df4-7qck7

dann wird dieser Pod tatsächlich auch entfernt, aber sofort durch das Deployment mit einem neuen nginx-Pod ersetzt. Das Deployment muss den eigenen Zustand mit 5 Pods erhalten. Mit kubectl get pods kann überprüft werden, dass ein neuer Pod tatsächlich gestartet wurde und erneut 5 nginx-Pods laufen.

Replikas reduzieren

Natürlich kann die Anzahl der Replicas eines Deployments auch reduziert werden, zum Beispiel auf 2:

kubectl scale deploy/nginx --replicas 2

Rolling Update

Öffne ein neues Terminal-Fenster und gebe dort den Befehl:

kubectl events --watch

ein. Du siehst nun in diesem Fenster die Kubernetes Events, die auftreten, wenn sich zum Beispiel der Zustand des Clusters ändert. Durch die --watch-Option werden die Events laufend angezeigt.

Events

Das Deployment hat momentan 2 Replicas. Skaliere es jetzt auf 3 Pods:

kubectl scale deploy/nginx --replicas 3

Du siehst im Event-Fenster anhand der Events, die dort angezeigt werden, dass ein neuer Pod erzeugt und gestartet wurde:

0s          Normal   ScalingReplicaSet   Deployment/nginx              Scaled up replica set nginx-788f9dcfbf from 2 to 3
0s          Normal   SuccessfulCreate    ReplicaSet/nginx-788f9dcfbf   Created pod: nginx-788f9dcfbf-hrb6p
0s          Normal   Scheduled           Pod/nginx-788f9dcfbf-hrb6p    Successfully assigned tutorials/nginx-788f9dcfbf-hrb6p to k3s
0s          Normal   Pulled              Pod/nginx-788f9dcfbf-hrb6p    Container image "nginx:1.31.0-alpine3.23" already present on machine and can be accessed by the pod
0s          Normal   Created             Pod/nginx-788f9dcfbf-hrb6p    Container created
0s          Normal   Started             Pod/nginx-788f9dcfbf-hrb6p    Container started

Das nginx-Deployment hat nun 3 Replikas.

Neue Version des Images

Starte den Watch auf die Events im Cluster mit folgendem Befehl:

kubectl events --watch | grep ScalingReplicaSet

d.h. wir interessieren uns lediglich für ScalingReplicaSet Events.

Nehmen wir mal an, dass das Deployment eine neue Version der Software benötigt, also nicht mehr das Image nginx:1.31.0-alpine3.23 sondern den Patch nginx:1.31.1-alpine3.23. Wir bauen hier das typische Szenario eines Versionsupdates der Software. Das Update des Images kann mit dem Befehl:

kubectl set image deploy/nginx web=nginx:1.31.1-alpine3.23

durchgeführt werden. Beobachte parallel zum kubectl set image ...-Befehl welche Events nun auftreten:

Scaled up replica set nginx-5644799d59 from 0 to 1
Scaled down replica set nginx-5589648df4 from 3 to 2
Scaled up replica set nginx-5644799d59 from 1 to 2
Scaled down replica set nginx-5589648df4 from 2 to 1
Scaled up replica set nginx-5644799d59 from 2 to 3
Scaled down replica set nginx-5589648df4 from 1 to 0

Das Deployment erhält ein neues Replicaset, das schrittweise um einen Pod hochskaliert wird, während gleichzeitig das alte Replicaset um einen Pod herunterskaliert wird. Dieses Verhalten wird auch Rolling Update genannt. Das heißt, die neue Version der Software wird schrittweise, Pod für Pod hochgefahren, während die alte Version schrittweise heruntergefahren wird.

Tritt ein Problem beim Hochfahren der neuen Version auf, so wird dieser Prozess gestoppt und die alte Version der Software läuft wie gehabt. D.h. der Benutzer der Software merkt gar nicht, dass das Deployment der neuen Version fehlgeschlagen ist.

Rollout Status und Undo

Mit dem Befehl

kubectl rollout status deploy/nginx

kann man sich den Status des Rollouts, also des Rolling Updates anschauen. Mit kubectl describe pod/nginx-[rs id]-[pod id] sieht man unter Containers: web: Image:, dass die neuen Pods die richtige, gepatchte Version 1.31.1 des Images haben. Möchte man das Rollout des Images rückgängig machen, so hilft einem der Befehl:

kubectl rollout undo deploy/nginx

Man erhält dabei eine Warnung von Kubernetes, dass möglicherweise ein erneutes kubectl apply ... diesen Undo rückgängig machen könnte. Der Undo war aber erfolgreich und die Pods des nginx-Deployments haben nun erneut das ursprüngliche Image in der Version 1.31.0.

Fazit

Du hast in diesem Tutorial folgendes gelernt:

1. Deployments erstellen,
2. skalieren,
3. Rolling Updates durchführen und zurückrollen.

Newsletter

In meinem Newsletter teile ich regelmäßig Tipps, Ressourcen und Einblicke zu Docker, Kubernetes und DevOps. Ich spame Dich nicht zu, versprochen!