Maîtrisez le progressive delivery avec Gateway API et Argo Rollouts

• Un cluster GKE avec la Gateway API activée.
• Argo Rollouts installé sur le cluster.
• Installez le plugin kubectl pour piloter et visualiser les rollouts en ligne de commande.

• Le plugin Gateway API d'Argo Rollouts ne prend pas en charge la stratégie de déploiement blue/green.
• La fonctionnalité n'est disponible que pour les Application Load Balancers basés sur Envoy dans GCP. Les Classic Application Load Balancers et les Network Load Balancers ne la prennent pas en charge directement.

• Appliquez le manifeste ci-dessous sur le cluster pour créer un ConfigMap. Consultez la page Releases pour les versions disponibles et adaptez l'architecture si besoin.

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

• Redémarrez le pod Argo Rollouts : le plugin sera téléchargé au démarrage du pod.

Exemple de log du pod illustrant l'installation du plugin

• Une ressource Gateway représente un data plane qui route le trafic dans Kubernetes. Selon la GatewayClass utilisée, une Gateway peut couvrir de nombreux types de load balancing et de routage.
• Appliquez le manifeste ci-dessous pour créer un Application Load Balancer externe global.

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

Exemple de ressource Gateway API

• Appliquez le manifeste ci-dessous pour autoriser Argo Rollouts à modifier les ressources HTTPRoute.

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

• Créez un exemple de HTTPRoute et reliez-le à la ressource Gateway créée précédemment.

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

• Créez le service canary.

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

• Créez le service stable.

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

Load balancer externe avec configuration des routes

• Un Rollout est une ressource Kubernetes personnalisée, équivalente à un objet Deployment. Il a vocation à remplacer un Deployment lorsque l'on a besoin de fonctionnalités plus avancées de déploiement ou de progressive delivery.
• Vous pouvez créer un nouveau Rollout ou y rattacher des Deployments existants. Le plugin Gateway API d'Argo Rollouts ne prend en charge que le déploiement canary. Consultez la spécification du Rollout pour connaître les options disponibles.
• Appliquez le manifeste ci-dessous sur le cluster, attendez que l'application soit prête, puis ouvrez l'IP de la Gateway dans le navigateur.

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

• Décrivez la ressource HTTPRoute et consultez les logs du pod Argo Rollouts pour confirmer le bon déroulement du déploiement. Argo Rollouts modifie la valeur de poids dans la HTTPRoute, qui se synchronise ensuite avec le load balancer.

Configuration initiale du routage du load balancer

Exemple de réponse de l'application. Extension Chrome ModHeader utilisée pour personnaliser l'en-tête Host

• Exécutez la commande suivante pour modifier l'image et déclencher un nouveau rollout.

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

• Argo Rollouts crée le nombre de pods nécessaire pour respecter le pourcentage de trafic visé. Ici, 3 nouveaux pods seront créés pour atteindre 50 % de trafic vers la nouvelle version.
• Exécutez la commande suivante pour suivre la progression du rollout. Le plugin kubectl d'Argo Rollouts peut aussi exposer un dashboard local pour visualiser vos Rollouts.

kubectl argo rollouts get rollout rollouts-demo

Exemple de statut initial du rollout

• Inspectez la HTTPRoute et vérifiez qu'Argo Rollouts a bien ajusté les poids des services backend.

Exemple de HTTPRoute

Règles de routage du load balancer

• À ce stade, chaque version doit recevoir 50 % des requêtes. Vous pouvez le constater directement dans votre navigateur.

Rollout canary initial

• Promouvez le rollout avec la commande suivante pour augmenter la part de trafic envoyée vers la nouvelle version. Vérifiez la HTTPRoute et les règles de routage du load balancer.

kubectl argo rollouts promote rollouts-demo

• Exécutez à nouveau la commande promote pour finaliser le rollout, puis attendez la suppression des pods de l'ancienne version. Si vous changez à nouveau l'image du Rollout, le processus repart de zéro.

Statut du rollout après finalisation

Règles de routage du load balancer mises à jour

Rollout canary finalisé