Progressive Delivery a otro nivel con Gateway API y Argo Rollouts

• Un cluster de GKE con la Gateway API habilitada.
• Argo Rollouts instalado en el cluster.
• Instalar el plugin de kubectl para gestionar y visualizar los rollouts desde la línea de comandos.

• El plugin de Gateway API para Argo Rollouts no es compatible con la estrategia de despliegue blue/green.
• Esta funcionalidad solo está disponible para application load balancers basados en envoy en GCP. Los Classic Application Load Balancers y los Network Load Balancers no la soportan de forma directa.

• Aplica el siguiente manifest en el cluster para crear un configmap. Revisa la página de Releases para conocer las versiones disponibles y cambia la arquitectura si fuera necesario.

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

• Reinicia el pod de Argo Rollouts y el plugin se descargará durante el arranque.

Ejemplo de log del pod donde se ve la instalación del plugin

• Un recurso Gateway representa un data plane que enruta tráfico en Kubernetes. Según la GatewayClass que use, un gateway puede representar distintos tipos de balanceo de carga y enrutamiento.
• Aplica el siguiente manifest para crear un Application Load Balancer global externo.

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

Ejemplo de recurso Gateway API

• Aplica el siguiente manifest para que Argo Rollouts pueda editar los recursos HTTP Routes.

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

• Crea un HTTPRoute de ejemplo y conéctalo al recurso Gateway que ya creaste.

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

• Crea el servicio 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

• Crea el servicio 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 externo con la configuración de rutas

• Un rollout es un custom resource de Kubernetes equivalente a un objeto Deployment. Está pensado para reemplazar al Deployment cuando se necesitan funcionalidades de despliegue más avanzadas o de progressive delivery.
• Puedes crear un rollout nuevo o vincular deployments existentes dentro de un recurso rollout. El plugin de Gateway API para Argo Rollouts solo soporta el despliegue canary. Consulta la Rollout Specification para ver las opciones disponibles.
• Aplica el siguiente manifest en el cluster, espera a que la aplicación esté lista y luego abre la IP del Gateway en el navegador.

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

• Describe el recurso httproute y revisa los logs del pod de Argo Rollouts para confirmar que el despliegue se realizó con éxito. Argo Rollouts modificará el valor de weight en el httproute, que luego se sincroniza con el load balancer.

Configuración inicial de enrutamiento del load balancer

Respuesta de la aplicación de ejemplo. Se usó el plugin ModHeader de Chrome para personalizar el header Host

• Ejecuta el siguiente comando para cambiar la imagen y disparar un nuevo proceso de rollout.

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

• Argo Rollouts creará la cantidad de pods necesaria para igualar el porcentaje de tráfico. En este caso, levantará 3 pods nuevos para alcanzar el 50% de tráfico hacia la nueva versión.
• Ejecuta el siguiente comando para monitorear el progreso del rollout. El plugin de kubectl de Argo Rollouts puede levantar un UI Dashboard local para visualizar tus rollouts.

kubectl argo rollouts get rollout rollouts-demo

Estado inicial del rollout

• Inspecciona el HttpRoute y verifica que Argo Rollouts haya cambiado los pesos de los servicios backend.

Ejemplo de HTTPRoute

Reglas de enrutamiento del load balancer

• En este punto, cada versión debería recibir el 50% de las solicitudes. Puedes comprobarlo desde tu navegador.

Rollout canary inicial

• Promueve el rollout con el siguiente comando para aumentar el porcentaje de tráfico hacia la nueva versión. Revisa la configuración del HttpRoute y de las reglas de enrutamiento del load balancer.

kubectl argo rollouts promote rollouts-demo

• Ejecuta el comando promote una vez más para completar el rollout y espera a que se destruyan los pods de la versión anterior. Si vuelves a cambiar la imagen del Rollout, el proceso comenzará de nuevo.

Estado del rollout una vez finalizado

Reglas de enrutamiento del load balancer ya actualizadas

Rollout canary completado