Deployments ohne Bauchschmerzen: Argo Rollouts als Sicherheitsnetz für Kubernetes

Argo Rollouts ist ein leistungsstarker Kubernetes-Controller mit einem Set an CRDs, das die Deployment-Möglichkeiten in Kubernetes deutlich erweitert – inklusive Blue-Green, Canary-Analysen, Experimenten und Progressive Delivery.

Argo Rollouts lässt sich mit Ingress-Controllern und Service Meshes integrieren, um Traffic während eines Updates schrittweise auf neue Versionen umzuleiten. Darüber hinaus erfasst und analysiert Rollouts Metriken aus verschiedenen Quellen, um zentrale KPIs zu prüfen und Updates automatisch zu promoten oder zurückzurollen.

Ähnlich wie das Deployment-Objekt verwaltet der Argo-Rollouts-Controller das Anlegen, Skalieren und Löschen von ReplicaSets. Diese ReplicaSets werden über das Feld spec.template in der Rollout-Ressource definiert, das dasselbe Pod-Template wie das Deployment-Objekt verwendet. Für StatefulSet oder DaemonSet wird Argo Rollouts nicht unterstützt.

Wird spec.template geändert, signalisiert das dem Argo-Rollouts-Controller, dass ein neues ReplicaSet eingeführt wird. Anhand der im Feld spec.strategy festgelegten Strategie entscheidet der Controller, wie das Rollout vom alten ReplicaSet auf das neue voranschreitet. Sobald das neue ReplicaSet hochskaliert ist (und optional eine Analyse bestanden hat), markiert der Controller es als "stable".

Mit spec.WorkoadRef können Sie zudem bestehende Deployments in Argo Rollouts verwalten, ohne Ihr aktuelles Setup löschen zu müssen.

Voraussetzungen

• Eingerichteter Kubernetes-Cluster sowie installiertes und konfiguriertes kubectl.
• Installieren Sie das Argo Rollouts kubectl-Plugin auf Ihrem Rechner.

Argo Rollouts installieren

• Führen Sie die folgenden Befehle aus, um Argo Rollouts im Cluster zu installieren. Weitere Optionen finden Sie in der offiziellen Dokumentation.

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

Blue-Green-Deployment-Strategie

Bei einem Blue-Green-Deployment laufen zwei identische Umgebungen parallel. Die Blue-Umgebung bildet die aktuelle Produktion ab, die Green-Umgebung die neue Version, die Sie ausrollen möchten. In dieser Phase erhält ausschließlich die alte Version den Produktions-Traffic. Entwickler können die neue Version also gründlich testen, bevor der Live-Traffic auf die neue Umgebung umgeschaltet wird.

Visuelle Darstellung des Blue-Green-Deployments

Sehen wir uns anhand eines einfachen Beispiels an, wie Sie Argo Rollouts für die Blue-Green-Deployment-Strategie nutzen.

• Deployen Sie mit dem folgenden Befehl eine nginx-Beispielanwendung im Cluster, die als Blue-Umgebung fungiert.

kubectl create deployment nginx --image nginx:1.19.10 --replicas 2

Pods der Beispielanwendung

• Legen Sie zwei Kubernetes-Services für das Deployment an. Einen für die aktuelle Umgebung (Blue) und einen für die neue Umgebung (Green).

kubectl expose deployment nginx --name nginx-active --port 80 --target-port 80
kubectl expose deployment nginx --name nginx-preview --port 80 --target-port 80

Beispiel-Service und Endpoints

• Erstellen Sie eine Argo-Rollout-Ressource mit den nötigen Konfigurationen für die Blue-Green-Strategie. Alle Optionen finden Sie in der offiziellen Dokumentation.

cat <<EOF | kubectl apply -f -
---
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: nginx
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  strategy:
    blueGreen: #Indicates that the rollout should use the Blue-Green strategy
      activeService: nginx-active # Reference to service that the rollout modifies as the active service.
      previewService: nginx-preview # Name of the service that the rollout modifies as the preview service.
      previewReplicaCount: 1 #The number of replicas to run under the preview service before the switchover.
      # Indicates if the rollout should automatically promote the new ReplicaSet
      # to the active service or enter a paused state. If not specified, the
      # default value is true. +optional
      autoPromotionEnabled: false
  # WorkloadRef holds a references to a workload that provides Pod template
  workloadRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
EOF

• Prüfen Sie das neue ReplicaSet und die Argo-Rollout-Konfiguration wie unten gezeigt.

Status von Pods, ReplicaSets und Argo Rollout

• Die vom ursprünglichen ReplicaSet verwalteten Pods werden nicht automatisch entfernt. Da nun das Argo Rollout die Verwaltung übernimmt, sollten Sie die Deployment-Replicas manuell auf 0 skalieren. Mit dem folgenden Befehl fahren Sie die nicht mehr verwalteten Pods herunter.

kubectl scale deployment nginx --replicas 0

• Ändern wir nun die Image-Version auf latest – das löst eine neue Revision aus.

kubectl set image deployment/nginx nginx=nginx:latest

Status des Blue-Green-Deployments vor der Promotion

• Die Green-Umgebung ist nun bereit. Über den Service nginx-preview testen Sie die Änderungen, ohne den Live-Traffic des nginx-active-Services zu beeinträchtigen.
• Den Rollout-Status können Sie auch im Argo-Rollouts-Dashboard verfolgen. Mit dem folgenden Befehl öffnen Sie das Dashboard.

kubectl argo rollouts dashboard -n default

Rollout-Status im Argo-Rollouts-Dashboard

• Mit dem folgenden Befehl promoten Sie die neue Version in die Produktion.

kubectl argo  rollouts promote nginx

Status des Blue-Green-Deployments nach der Promotion

Ein Canary-Deployment ist ein phasenweises Deployment, das den Traffic zwischen einer bereits laufenden und einer neuen Version aufteilt. Die neue Version wird zunächst an einen Teil der Nutzer ausgerollt, bevor sie vollständig live geht.

Ingress-Controller und Service Meshes wie NGINX und Istio ermöglichen ein noch ausgefeilteres Traffic-Shaping für Canary-Releases – etwa feingranulare Traffic-Splits oder Splits auf Basis von HTTP-Headern.

Visuelle Darstellung des Canary-Deployments

Sehen wir uns an, wie Sie Argo Rollouts für ein Canary-Deployment einsetzen.

• Deployen Sie eine Beispielanwendung im Cluster.

kubectl create deployment nginx-canary --image nginx:1.19.10 --replicas 5

• Legen Sie einen Kubernetes-Service für das Deployment an. Anders als beim Blue-Green-Deployment benötigt Canary keine zwei separaten Kubernetes-Services für dasselbe Deployment, da neue Pod-Endpoints je nach Canary-Anteil zum bestehenden Service hinzugefügt werden.

kubectl expose deployment nginx-canary --port 80 --target-port 80

Pods und Service der Beispielanwendung

• Erstellen Sie eine Argo-Rollout-Ressource für die Canary-Strategie. Alle Optionen finden Sie in der offiziellen Dokumentation.

cat <<EOF | kubectl apply -f -
---
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: nginx-canary
spec:
  replicas: 5
  selector:
    matchLabels:
      app: nginx-canary
  workloadRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-canary
  strategy:
    canary: #Indicates that the rollout should use the Canary strategy
      maxSurge: "25%"
      maxUnavailable: 0
      steps:
      - setWeight: 10
      - pause:
          duration: 1h #Pause for 1 hour and wait promote to next canary stage
      - setWeight: 30
      - pause: {} # pause indefinitely and requires manual promote action
      - setWeight: 100
      - pause: {} # pause indefinitely and requires manual promote action
EOF

Status von Pods, ReplicaSet und Argo Rollout

• Wie beim Blue-Green-Deployment skalieren wir die aktuellen Deployment-Replicas auf null herunter, damit das Argo Rollout alle neuen Pods des neuen ReplicaSets verwalten kann.

kubectl scale deployment nginx-canary --replicas 0

• Deployen wir nun eine neue Anwendungsversion und beobachten das Canary-Deployment.

kubectl set image deployment/nginx-canary nginx=nginx:latest

Status des initialen Canary-Deployments (10 %)

Status des Canary-Rollouts im Argo-Dashboard

• Promoten Sie das Rollout manuell in die nächsten Canary-Stufen.

kubectl argo rollouts promote nginx-canary

Status des Canary-Rollouts bei 30 %

Status des Canary-Rollouts im Argo-Dashboard

Status des Canary-Rollouts bei 100 %

Status des Canary-Rollouts im Argo-Dashboard

Argo Rollouts bietet außerdem eine Analyse-Funktion, mit der Sie verschiedene Checks und Tests während oder nach einem Deployment definieren und ausführen. So validieren Sie Stabilität und Performance der neuen Version, bevor sie den vollen Produktions-Traffic erhält.