Progressive Delivery meistern – mit Gateway API und Argo Rollouts

• Ein GKE-Cluster mit aktivierter Gateway API.
• Argo Rollouts im Cluster installiert.
• Das kubectl-Plugin installieren, um Rollouts über die Kommandozeile zu verwalten und zu visualisieren.

• Das Argo Rollouts Gateway API-Plugin unterstützt keine Blue/Green-Deployment-Strategie.
• Diese Funktion steht in GCP nur für Envoy-basierte Application Load Balancer zur Verfügung. Classic Application Load Balancer und Network Load Balancer werden nicht direkt unterstützt.

• Wenden Sie das folgende Manifest auf den Cluster an, um eine ConfigMap zu erstellen. Verfügbare Versionen finden Sie auf der Releases-Seite; passen Sie die Architektur bei Bedarf an.

cat <<EOF | kubectl apply -f -
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: argo-rollouts-config # must be so name
  namespace: argo-rollouts # must be in this namespace
data:
  trafficRouterPlugins: |-
    - name: "argoproj-labs/gatewayAPI"
      location: "https://github.com/argoproj-labs/rollouts-plugin-trafficrouter-gatewayapi/releases/download/v0.3.0/gateway-api-plugin-linux-amd64"
EOF

• Starten Sie den Argo-Rollouts-Pod neu – das Plugin wird beim Pod-Start heruntergeladen.

Beispielhaftes Pod-Log mit der Plugin-Installation

• Eine Gateway-Ressource steht für eine Data Plane, die Traffic in Kubernetes routet. Je nach verwendeter GatewayClass kann ein Gateway sehr unterschiedliche Arten von Load Balancing und Routing abbilden.
• Wenden Sie das folgende Manifest an, um einen globalen externen Application Load Balancer zu erstellen.

cat <<EOF | kubectl apply -f -
---
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: argo-rollouts-demo-external-http
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: http
    protocol: HTTP
    port: 80
EOF

Beispielhafte Gateway-API-Ressource

• Wenden Sie das folgende Manifest an, damit Argo Rollouts HTTP-Routes-Ressourcen bearbeiten darf.

cat <<EOF | kubectl apply -f -
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: gateway-controller-role
  namespace: argo-rollouts
rules:
  - apiGroups:
      - gateway.networking.k8s.io
    resources:
      - httproutes
    verbs:
      - get
      - patch
      - update
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: gateway-controller-role
subjects:
  - namespace: argo-rollouts
    kind: ServiceAccount
    name: argo-rollouts
EOF

• Legen Sie eine Beispiel-HTTPRoute an und verbinden Sie sie mit der zuvor erstellten Gateway-Ressource.

cat <<EOF | kubectl apply -f -
---
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: argo-rollouts-demo-http-route
spec:
  parentRefs:
  - kind: Gateway
    name: argo-rollouts-demo-external-http
  hostnames:
  - "argo-rollouts-demo.example.com"
  rules:
    - backendRefs:
        - name: argo-rollouts-demo-stable-service
          port: 80
        - name: argo-rollouts-demo-canary-service
          port: 80
EOF

• Legen Sie den Canary-Service an.

cat <<EOF | kubectl apply -f -
---
apiVersion: v1
kind: Service
metadata:
  name: argo-rollouts-demo-canary-service
spec:
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app: argo-rollouts-demo
EOF

• Legen Sie den Stable-Service an.

cat <<EOF | kubectl apply -f -
---
apiVersion: v1
kind: Service
metadata:
  name: argo-rollouts-demo-stable-service
spec:
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app: argo-rollouts-demo
EOF

Externer Load Balancer mit Routing-Konfiguration

• Ein Rollout ist eine Kubernetes Custom Resource und das Pendant zu einem Kubernetes-Deployment-Objekt. Es ersetzt ein Deployment, sobald erweiterte Deployment- oder Progressive-Delivery-Funktionen gefragt sind.
• Sie können entweder ein neues Rollout anlegen oder bestehende Deployments in eine Rollout-Ressource überführen. Das Argo Rollouts Gateway API-Plugin unterstützt ausschließlich Canary Deployments. Alle verfügbaren Optionen finden Sie in der Rollout-Spezifikation.
• Wenden Sie das folgende Manifest auf den Cluster an, warten Sie, bis die Anwendung bereit ist, und rufen Sie anschließend die Gateway-IP im Browser auf.

cat <<EOF | kubectl apply -f -
---
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: argo-rollouts-demo
  namespace: default
spec:
  replicas: 5
  strategy:
    canary:
      canaryService: argo-rollouts-demo-canary-service # canary service
      stableService: argo-rollouts-demo-stable-service # stable service
      trafficRouting:
        plugins:
          argoproj-labs/gatewayAPI:
            httpRoute: argo-rollouts-demo-http-route # httproute
            namespace: default
      steps:
      - setWeight: 50
      - pause: {}
      - setWeight: 100
      - pause: {}
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: argo-rollouts-demo
  template:
    metadata:
      labels:
        app: argo-rollouts-demo
    spec:
      containers:
        - name: argo-rollouts-demo
          image: argoproj/rollouts-demo:blue
          ports:
            - name: http
              containerPort: 8080
              protocol: TCP
          resources:
            requests:
              memory: 32Mi
              cpu: 5m
EOF

• Lassen Sie sich die HTTPRoute-Ressource ausgeben und prüfen Sie in den Logs des Argo-Rollouts-Pods, ob das Rollout erfolgreich ausgerollt wurde. Argo Rollouts passt den Weight-Wert in der HTTPRoute an, der anschließend mit dem Load Balancer synchronisiert wird.

Initiale Routing-Konfiguration des Load Balancers

Beispielhafte Antwort der Anwendung. Der benutzerdefinierte Host-Header wurde mit dem Chrome-Plugin ModHeader gesetzt.

• Führen Sie folgenden Befehl aus, um das Image zu wechseln und damit ein neues Rollout anzustoßen.

kubectl argo rollouts set image argo-rollouts-demo argo-rollouts-demo=argoproj/rollouts-demo:yellow

• Argo Rollouts erzeugt so viele Pods, wie für den jeweiligen Traffic-Anteil nötig sind. In diesem Fall werden 3 neue Pods gestartet, um die 50 % Traffic auf die neue Version abzudecken.
• Mit folgendem Befehl verfolgen Sie den Fortschritt des Rollouts. Das Argo-Rollouts-kubectl-Plugin kann zudem ein lokales UI Dashboard bereitstellen, um Ihre Rollouts zu visualisieren.

kubectl argo rollouts get rollout rollouts-demo

Beispielhafter initialer Rollout-Status

• Sehen Sie sich die HTTPRoute an und prüfen Sie, ob Argo Rollouts die Gewichtungen der Backend-Services angepasst hat.

Beispielhafte HTTPRoute

Routing-Regeln des Load Balancers

• An diesem Punkt sollte jede Version 50 % der Anfragen erhalten. Im Browser lässt sich das direkt nachvollziehen.

Initiales Canary Rollout

• Promoten Sie das Rollout mit folgendem Befehl, um den Traffic-Anteil auf die neue Version weiter zu erhöhen. Prüfen Sie anschließend die HTTPRoute und die Routing-Regeln des Load Balancers.

kubectl argo rollouts promote rollouts-demo

• Führen Sie den Promote-Befehl ein zweites Mal aus, um das Rollout abzuschließen, und warten Sie, bis die Pods der alten Version entfernt sind. Sobald Sie das Rollout-Image erneut ändern, beginnt der Prozess von vorn.

Rollout-Status nach Abschluss

Aktualisierte Routing-Regeln des Load Balancers

Abgeschlossenes Canary Rollout