Microservices Engine:Use Kruise Rollouts to implement MSE-based end-to-end canary releases

Ciclo de vida del canary release

Cuando cambia la imagen de un Deployment, Kruise Rollouts sigue esta secuencia:

1. Pausa la actualización continua nativa del Deployment.

2. Crea pods canary con la nueva versión de la imagen.

3. Configura el enrutamiento de tráfico para que las solicitudes coincidentes lleguen a los pods canary.

4. Espera la aprobación manual (o comprobaciones automáticas de métricas).

5. Tras la aprobación, promueve la versión canary a todos los pods mediante una actualización continua.

6. Elimina los pods canary y restaura el enrutamiento de tráfico nativo.

Instalación de ack-kruise

1. Inicie sesión en la ACK console. En el panel de navegación izquierdo, haga clic en Clusters.

2. En la página Clusters, localice su clúster objetivo y haga clic en su nombre. En el panel de navegación izquierdo, elija Operations > Add-ons.

3. En la página Manage Components, haga clic en la pestaña Manage Applications.

4. Localice la tarjeta ack-kruise y haga clic en Install.

5. En el cuadro de diálogo de confirmación, haga clic en OK.

Instalación del MSE Ingress Controller

Cree un recurso MseIngressConfig y un recurso IngressClass para habilitar el ingress basado en MSE en su clúster. Para obtener instrucciones detalladas, consulte Use MSE Ingresses to access applications in ACK clusters.

Habilitación de Microservices Governance

Habilite Microservices Governance para sus aplicaciones objetivo. Para obtener instrucciones detalladas, consulte Enable Microservices Governance for microservice applications in an ACK cluster.

Creación de los recursos de la aplicación

1. Cree un archivo llamado mse-demo.yaml con el siguiente contenido:

   View the mse-demo.yaml file

       # Service for application A
       apiVersion: v1
       kind: Service
       metadata:
         name: spring-cloud-a
       spec:
         ports:
           - name: http
             port: 20001
             protocol: TCP
             targetPort: 20001
         selector:
           app: spring-cloud-a
       ---
       # Deployment for application A (base version)
       apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: spring-cloud-a
       spec:
         replicas: 2
         selector:
           matchLabels:
             app: spring-cloud-a
         template:
           metadata:
             annotations:
               msePilotCreateAppName: spring-cloud-a
             labels:
               app: spring-cloud-a
           spec:
             containers:
               - env:
                   - name: JAVA_HOME
                     value: /usr/lib/jvm/java-1.8-openjdk/jre
                 image: registry.cn-hangzhou.aliyuncs.com/mse-demo-hz/spring-cloud-a:mse-2.0.0
                 imagePullPolicy: Always
                 name: spring-cloud-a
                 ports:
                   - containerPort: 20001
       ---
       # Deployment for application B (base version)
       apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: spring-cloud-b
       spec:
         replicas: 2
         selector:
           matchLabels:
             app: spring-cloud-b
         template:
           metadata:
             annotations:
               msePilotCreateAppName: spring-cloud-b
             labels:
               app: spring-cloud-b
           spec:
             containers:
               - env:
                   - name: JAVA_HOME
                     value: /usr/lib/jvm/java-1.8-openjdk/jre
                 image: registry.cn-hangzhou.aliyuncs.com/mse-demo-hz/spring-cloud-b:mse-2.0.0
                 imagePullPolicy: Always
                 name: spring-cloud-b
       ---
       # Deployment for application C (base version)
       apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: spring-cloud-c
       spec:
         replicas: 2
         selector:
           matchLabels:
             app: spring-cloud-c
         template:
           metadata:
             annotations:
               msePilotCreateAppName: spring-cloud-c
             labels:
               app: spring-cloud-c
           spec:
             containers:
               - env:
                   - name: JAVA_HOME
                     value: /usr/lib/jvm/java-1.8-openjdk/jre
                 image: registry.cn-hangzhou.aliyuncs.com/mse-demo-hz/spring-cloud-c:mse-2.0.0
                 imagePullPolicy: Always
                 name: spring-cloud-c
       ---
       # Nacos service discovery server
       apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: nacos-server
       spec:
         replicas: 1
         selector:
           matchLabels:
             app: nacos-server
         template:
           metadata:
             labels:
               app: nacos-server
           spec:
             containers:
             - env:
               - name: MODE
                 value: standalone
               image: registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/nacos-server:v2.1.2
               imagePullPolicy: Always
               name: nacos-server
             dnsPolicy: ClusterFirst
             restartPolicy: Always
       ---
       apiVersion: v1
       kind: Service
       metadata:
         name: nacos-server
       spec:
         type: ClusterIP
         ports:
           - name: nacos-server-8848-8848
             port: 8848
             protocol: TCP
             targetPort: 8848
           - name: nacos-server-9848-9848
             port: 9848
             protocol: TCP
             targetPort: 9848
         selector:
           app: nacos-server
       ---
       # MySQL database
       apiVersion: v1
       kind: Service
       metadata:
         labels:
           app: demo-mysql
         name: demo-mysql
       spec:
         ports:
           - port: 3306
             targetPort: 3306
         selector:
           app: demo-mysql
       ---
       apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: demo-mysql
       spec:
         selector:
           matchLabels:
             app: demo-mysql
         replicas: 1
         strategy:
           type: Recreate
         template:
           metadata:
             labels:
               app: demo-mysql
           spec:
             containers:
               - args:
                   - --character-set-server=utf8mb4
                   - --collation-server=utf8mb4_unicode_ci
                 env:
                   - name: MYSQL_ROOT_PASSWORD
                     value: root
                 image: registry.cn-hangzhou.aliyuncs.com/mse-demo-hz/demo-mysql:3.0.1
                 name: demo-mysql
                 ports:
                   - containerPort: 3306

2. Despliegue las aplicaciones:

       kubectl apply -f mse-demo.yaml

Creación del recurso Ingress

1. Cree un archivo llamado mse-ingress.yaml con el siguiente contenido:

   View the mse-ingress.yaml file

       apiVersion: networking.k8s.io/v1
       kind: Ingress
       metadata:
         annotations:
           mse.ingress.kubernetes.io/service-subset: ""
         name: spring-cloud-a
       spec:
         ingressClassName: mse
         rules:
           - http:
               paths:
                 - backend:
                     service:
                       name: spring-cloud-a
                       port:
                         number: 20001
                   path: /
                   pathType: Prefix

2. Aplique la configuración del Ingress:

       kubectl apply -f mse-ingress.yaml

Verificación del despliegue

1. Obtenga la dirección IP externa del Ingress: Salida esperada:

       kubectl get ingress

       NAME              CLASS    HOSTS   ADDRESS        PORTS   AGE
       spring-cloud-a    <none>   *       EXTERNAL_IP    80      12m

2. Envíe una solicitud de prueba. Reemplace <EXTERNAL_IP> con la dirección IP obtenida en la salida anterior: Salida esperada: Esta salida confirma que la cadena de llamadas A -> B -> C funciona correctamente y que los tres servicios ejecutan la versión base.

       curl http://<EXTERNAL_IP>/a

       A[192.168.42.115][config=base] -> B[192.168.42.118] -> C[192.168.42.101]

Definición de los recursos Rollout y TrafficRouting

En esta demostración, el canary release se realiza en tres lotes:

1. Se realizan pruebas A/B. Las solicitudes que contienen header[User-Agent]=xiaoming se reenvían a la versión canary. Las demás solicitudes se dirigen a la versión base.

2. La mitad de los pods ejecutan la versión canary y la mitad de las solicitudes se reenvían a dicha versión.

3. Todos los pods ejecutan la versión canary y todas las solicitudes se reenvían a dicha versión.

Cree y aplique los recursos Rollout de la siguiente manera:

1. Cree un archivo llamado rollout.yaml con el siguiente contenido:

   View the rollout.yaml file

       # Rollout configuration for application A
       apiVersion: rollouts.kruise.io/v1alpha1
       kind: Rollout
       metadata:
         name: rollout-a
         annotations:
           rollouts.kruise.io/trafficrouting: mse-traffic
       spec:
         objectRef:
           workloadRef:
             apiVersion: apps/v1
             kind: Deployment
             name: spring-cloud-a
         strategy:
           canary:
             steps:
             - pause: {}
               replicas: 1
             patchPodTemplateMetadata:
               labels:
                 alicloud.service.tag: gray
                 opensergo.io/canary-gray: gray
       ---
       # Rollout configuration for application B
       apiVersion: rollouts.kruise.io/v1alpha1
       kind: Rollout
       metadata:
         name: rollout-b
         annotations:
           rollouts.kruise.io/trafficrouting: mse-traffic
       spec:
         objectRef:
           workloadRef:
             apiVersion: apps/v1
             kind: Deployment
             name: spring-cloud-b
         strategy:
           canary:
             steps:
               - pause: {}
                 replicas: 1
             patchPodTemplateMetadata:
               labels:
                 alicloud.service.tag: gray
                 opensergo.io/canary-gray: gray
       ---
       # Rollout configuration for application C
       apiVersion: rollouts.kruise.io/v1alpha1
       kind: Rollout
       metadata:
         name: rollout-c
         annotations:
           rollouts.kruise.io/trafficrouting: mse-traffic
       spec:
         objectRef:
           workloadRef:
             apiVersion: apps/v1
             kind: Deployment
             name: spring-cloud-c
         strategy:
           canary:
             steps:
               - pause: {}
                 replicas: 1
             patchPodTemplateMetadata:
               labels:
                 alicloud.service.tag: gray
                 opensergo.io/canary-gray: gray
       ---
       # TrafficRouting: defines how canary traffic is identified and routed
       apiVersion: rollouts.kruise.io/v1alpha1
       kind: TrafficRouting
       metadata:
         name: mse-traffic
       spec:
         objectRef:
         - service: spring-cloud-a
           ingress:
             classType: mse
             name: spring-cloud-a
         strategy:
           matches:
           # Route requests with User-Agent: xiaoming to the canary version
           - headers:
             - type: Exact
               name: User-Agent
               value: xiaoming
           requestHeaderModifier:
             set:
             - name: x-mse-tag
               value: gray

   Qué ocurre al aplicar esta configuración:

   Cada recurso Rollout monitorea un Deployment. Cuando cambia la imagen del Deployment, Kruise Rollouts realiza lo siguiente:

   1. Pausa la actualización continua nativa.

   2. Crea un pod canary (replicas: 1) con la nueva versión de la imagen.

   3. Aplica las etiquetas patchPodTemplateMetadata al pod canary:

      • alicloud.service.tag: gray: indica a Microservices Governance de MSE que reconozca este pod como parte del grupo canary (gray).

      • opensergo.io/canary-gray: gray: habilita el enrutamiento de carriles de tráfico compatible con OpenSergo a lo largo de la cadena de llamadas.

   4. Pausa el proceso y espera la aprobación manual antes de promover la versión.

   El recurso TrafficRouting define las reglas de división de tráfico:

   • Las solicitudes con el encabezado User-Agent: xiaoming coinciden con la regla canary.

   • El modificador requestHeaderModifier inyecta un encabezado x-mse-tag: gray en las solicitudes coincidentes. MSE propaga este encabezado por toda la cadena de llamadas, lo que permite el enrutamiento canary de extremo a extremo. Cada servicio de la cadena comprueba este encabezado y enruta la solicitud a su pod canary si existe alguno.

2. Despliegue los recursos Rollout:

       kubectl apply -f rollout.yaml

3. Compruebe el estado del Rollout: Si la salida muestra STATUS=Healthy, los recursos Rollout están listos.

       kubectl get rollout

Activación de un canary release

Kruise Rollouts requiere una configuración única. Una vez desplegados los recursos Rollout, active un canary release actualizando la imagen de su Deployment; no se necesita configuración adicional de Rollout. Además de kubectl, puede usar Helm o Vela para desplegar los deployments en su clúster.

1. En mse-demo.yaml, actualice las versiones de imagen para spring-cloud-a y spring-cloud-c de mse-2.0.0 a mse-2.0.1: La aplicación B permanece en mse-2.0.0. Dado que B no tiene versión canary, las solicitudes enrutadas al carril canary pasan por la versión base de B, pero continúan hacia la versión canary de C. Esto demuestra el funcionamiento del carril de tráfico de extremo a extremo: incluso cuando un servicio intermedio en la cadena carece de despliegue canary, la etiqueta canary se conserva y los servicios posteriores siguen enrutando correctamente.

       # In the spring-cloud-a Deployment
       image: registry.cn-hangzhou.aliyuncs.com/mse-demo-hz/spring-cloud-a:mse-2.0.1
   
       # In the spring-cloud-c Deployment
       image: registry.cn-hangzhou.aliyuncs.com/mse-demo-hz/spring-cloud-c:mse-2.0.1

2. Aplique los Deployments actualizados:

       kubectl apply -f mse-demo.yaml

3. Revise el progreso del Rollout: Salida esperada:

   Campo	Valor	Significado
   STATUS	Progressing	El canary release está en curso
   CANARY_STATE	StepPaused	El lote canary está desplegado y el rollout espera aprobación manual

       kubectl get rollouts rollout-a -n default
       kubectl get rollouts rollout-c -n default

       NAME         STATUS        CANARY_STEP   CANARY_STATE   MESSAGE                                                                        AGE
       rollout-a    Progressing   1             StepPaused     Rollout is in step(1/1), and you need manually confirm to enter the next step   41m
       rollout-c    Progressing   1             StepPaused     Rollout is in step(1/1), and you need manually confirm to enter the next step   41m

Verificación y promoción de la versión canary

1. Envíe una solicitud de prueba canary incluyendo el encabezado User-Agent: xiaoming: El tráfico canary fluye a través de las versiones canary de A y C, mientras que B utiliza su versión base. Compruebe el comportamiento mediante los registros de la aplicación y las métricas de monitoreo.

       curl http://<EXTERNAL_IP>/a -H "User-Agent: xiaoming"

2. Tras confirmar que la versión canary funciona según lo esperado, apruebe el rollout para promoverla a producción. Ejecute el siguiente comando para cada Rollout que tenga una versión canary desplegada (en esta demostración, rollout-a y rollout-c). Reemplace <rollouts-demo> con el nombre del recurso Rollouts:

       rollout.rollouts.kruise.io/<rollouts-demo> approved

Reversión de un canary release

Si la versión canary no cumple con las expectativas, revierta las versiones de imagen en mse-demo.yaml a sus valores originales y vuelva a aplicarlas:

kubectl apply -f mse-demo.yaml

No es necesario modificar los recursos Rollout. Kruise Rollouts detecta el cambio en el Deployment y gestiona la reversión automáticamente.

La función de canary release de extremo a extremo de Microservices Governance proporciona carriles que facilitan enormemente la verificación durante las pruebas y los lanzamientos. Puede utilizar Microservices Governance junto con Kruise Rollouts para mejorar significativamente la estabilidad de las aplicaciones en línea dentro de un proceso DevOps.