Container Service for Kubernetes:Perform canary releases with ALB Ingresses in an ACK cluster

Requisitos previos

Complete a continuación los siguientes pasos:

• Dos vSwitches en distintas zonas de disponibilidad dentro de la misma VPC que el clúster de ACK. Consulte Crear y gestionar un vSwitch.

• El controlador de ALB Ingress instalado en el clúster. Consulte Manage the ALB Ingress controller.

  En los clústeres dedicados de ACK, otorgue permisos al clúster para acceder a ALB Ingress. Consulte Autorizar a un clúster dedicado de ACK el acceso al controlador de ALB Ingress .

• Un AlbConfig creado. Consulte Crear un AlbConfig.

• kubectl conectado al clúster de ACK. Consulte Obtener el archivo kubeconfig de un clúster y usar kubectl para conectarse al clúster.

Anotaciones canary

Todo Ingress canary requiere la anotación alb.ingress.kubernetes.io/canary: "true". Sin ella, el Ingress canary entra en conflicto con el entorno de producción en lugar de enrutar junto a él.

Las siguientes anotaciones controlan la división del tráfico:

Prioridad de las reglas: basadas en encabezado > basadas en cookie > basadas en peso.

Notas de uso

• Las reglas basadas en encabezado o cookie no pueden compartir un Ingress con las reglas basadas en peso. Utilice Ingresses independientes o consulte custom routing rules para condiciones complejas.

• El host del Ingress canary debe coincidir exactamente con el host del Ingress de producción.

• Cuando varios Ingresses canary comparten un mismo host, establezca la prioridad de manera explícita con alb.ingress.kubernetes.io/order en lugar de depender del orden lexicográfico.

Paso 1: Desplegar el Service de producción

Despliegue el Deployment, el Service y el Ingress de producción.

1. Cree el archivo tea-deploy.yaml y aplíquelo:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: tea
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: tea
     template:
       metadata:
         labels:
           app: tea
       spec:
         containers:
         - name: tea
           image: registry.cn-hangzhou.aliyuncs.com/acs-sample/old-nginx:latest
           ports:
           - containerPort: 80

   kubectl apply -f tea-deploy.yaml

2. Cree el archivo tea-svc.yaml y aplíquelo:

   apiVersion: v1
   kind: Service
   metadata:
     name: tea-svc
   spec:
     ports:
     - port: 80
       targetPort: 80
       protocol: TCP
     selector:
       app: tea
     type: NodePort

   kubectl apply -f tea-svc.yaml

3. Cree el archivo tea-ingress.yaml y aplíquelo:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: tea-ingress
   spec:
     ingressClassName: alb
     rules:
      - host: demo.domain.ingress.top  # Replace with your domain name, resolved to the load balancer IP.
        http:
         paths:
         - path: /
           pathType: Prefix
           backend:
             service:
               name: tea-svc
               port:
                 number: 80

   kubectl apply -f tea-ingress.yaml

Paso 2: Desplegar el Service canary y las reglas de enrutamiento

Despliegue el Service canary con dos Ingresses canary: uno enruta por encabezado y el otro divide el tráfico restante por peso.

Antes de aplicar los Ingresses canary, tenga en cuenta lo siguiente:

• Establezca alb.ingress.kubernetes.io/canary: "true" en cada Ingress canary. Sin esta anotación, el Ingress canary entra en conflicto con el entorno de producción.

• El campo host debe coincidir exactamente con el host del Ingress de producción (demo.domain.ingress.top en este ejemplo).

• Las reglas basadas en encabezado y las basadas en peso deben configurarse en Ingresses distintos.

1. Cree el archivo canary-deploy.yaml y aplíquelo:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: canary
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: canary
     template:
       metadata:
         labels:
           app: canary
       spec:
         containers:
         - name: canary
           image: registry.cn-hangzhou.aliyuncs.com/acs-sample/new-nginx:latest
           ports:
           - containerPort: 80

   kubectl apply -f canary-deploy.yaml

2. Cree el archivo canary-svc.yaml y aplíquelo:

   apiVersion: v1
   kind: Service
   metadata:
     name: canary-svc
   spec:
     ports:
     - port: 80
       targetPort: 80
       protocol: TCP
     selector:
       app: canary
     type: NodePort

   kubectl apply -f canary-svc.yaml

3. Cree un Ingress canary basado en encabezado. Las solicitudes con location: hz se dirigen a canary-svc; otros encabezados pasan a la siguiente regla. Cree el archivo canary-header-ingress.yaml y aplíquelo:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     annotations:
       alb.ingress.kubernetes.io/canary: "true"
       alb.ingress.kubernetes.io/canary-by-header: "location"
       alb.ingress.kubernetes.io/canary-by-header-value: "hz"
     name: canary-header-ingress
     namespace: default
   spec:
     ingressClassName: alb
     rules:
       - host: demo.domain.ingress.top  # Must match the production Ingress host exactly.
         http:
           paths:
             - backend:
                 service:
                   name: canary-svc
                   port:
                     number: 80
               path: /
               pathType: Prefix

   kubectl apply -f canary-header-ingress.yaml

4. Cree un Ingress canary basado en peso. Las solicitudes sin coincidencia se dividen en partes iguales entre los Services de producción y canary. Cree el archivo canary-weight-ingress.yaml y aplíquelo:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     annotations:
       alb.ingress.kubernetes.io/canary: "true"
       alb.ingress.kubernetes.io/canary-weight: "50"
     name: canary-weight-ingress
     namespace: default
   spec:
     ingressClassName: alb
     rules:
       - host: demo.domain.ingress.top  # Must match the production Ingress host exactly.
         http:
           paths:
             - backend:
                 service:
                   name: canary-svc
                   port:
                     number: 80
               path: /
               pathType: Prefix

   kubectl apply -f canary-weight-ingress.yaml

Comprobar la versión canary

1. Obtenga la dirección de la instancia de ALB:

   kubectl get ing

   Resultado esperado:

   NAME                    CLASS   HOSTS                     ADDRESS                                              PORTS   AGE
   canary-header-ingress   alb     demo.domain.ingress.top   alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com   80      8m23s
   canary-weight-ingress   alb     demo.domain.ingress.top   alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com   80      8m16s
   tea-ingress             alb     demo.domain.ingress.top   alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com   80      7m5s

2. Compruebe que las solicitudes con el encabezado location: hz siempre lleguen a la versión canary:

   for i in $(seq 1 10); do curl -s -H "Host:demo.domain.ingress.top" -H "location:hz" http://alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com; done

   Las 10 respuestas devuelven new. La regla de encabezado tiene la prioridad más alta y dirige todas las solicitudes coincidentes a la versión canary.

3. Compruebe que las solicitudes sin un encabezado coincidente se dividan aproximadamente en proporción 50/50:

   for i in $(seq 1 10); do curl -s -H "Host:demo.domain.ingress.top" http://alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com; done

   Las respuestas alternan entre new (canary) y old (producción), con una proporción cercana a la mitad para cada una. Los encabezados sin coincidencia (por ejemplo, location: bj) siguen la misma división basada en peso.

Paso 3: Promover la nueva versión

Una vez que la versión canary se estabilice, redirija todo el tráfico de producción al nuevo Service y elimine los Ingresses canary.

1. Actualice tea-ingress.yaml para que apunte a canary-svc:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: tea-ingress
   spec:
     ingressClassName: alb
     rules:
      - host: demo.domain.ingress.top
        http:
         paths:
         - path: /
           pathType: Prefix
           backend:
             service:
               name: canary-svc  # Changed from tea-svc.
               port:
                 number: 80

   kubectl apply -f tea-ingress.yaml

2. Elimine los Ingresses canary:

   kubectl delete ing canary-weight-ingress canary-header-ingress

3. Compruebe que todo el tráfico llegue a la nueva versión:

   for i in $(seq 1 10); do curl -s -H "Host:demo.domain.ingress.top" http://alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com; done

   Las 10 respuestas devuelven new. La versión anterior del Service queda completamente obsoleta.

Siguientes pasos

• Consulte Advanced ALB Ingress configurations para conocer las redirecciones de HTTP a HTTPS, las reglas de enrutamiento personalizadas y más información.

• Consulte Ingress FAQ para solucionar problemas.