How to: End-to-end canary release with MSE Ingress - Microservices Engine

Microservices Engine (MSE) permite implementar una versión canary de extremo a extremo mediante gateways MSE Ingress. De este modo, es posible aplicar un control de tráfico de extremo a extremo sin necesidad de modificar el código de negocio.

Requisitos previos

Se ha creado un clúster ACK o un clúster ACK Serverless. Para obtener más información, consulte Create an ACK managed cluster.
Se ha activado Microservices Governance Professional Edition. Para obtener más información, consulte Activate Microservices Governance.
El componente MSE Ingress Controller está instalado y cuenta con los permisos correspondientes. Para obtener más información, consulte Manage components y Authorize the MSE Ingress controller.

Límites de uso

La función de versión canary de extremo a extremo está integrada con la función de enrutamiento basado en etiquetas. Si utiliza Microservices Governance para implementar esta función en sus aplicaciones, se recomienda no configurar reglas de versión canary ni reglas de enrutamiento basado en etiquetas para dichas aplicaciones.

Para obtener más información sobre las versiones de Java y los frameworks compatibles con la versión canary de extremo a extremo, consulte Java frameworks supported by Microservices Governance.

Contexto

En escenarios de microservices con aplicaciones Spring Cloud o Dubbo, el tráfico se distribuye aleatoriamente entre las versiones de la aplicación de forma predeterminada. Esto implica que el tráfico con características específicas podría no llegar a la versión deseada. La función de versión canary de extremo a extremo resuelve este problema al aislar versiones específicas de la aplicación en lanes (entornos de ejecución independientes) y enrutar el tráfico que coincide con reglas definidas hacia la versión correspondiente. Puede crear lanes para aislar versiones de aplicaciones y configurar reglas de enrutamiento en los gateways MSE Ingress para dirigir el tráfico adecuadamente.

Escenario

Este ejemplo muestra una versión canary de extremo a extremo desde un gateway MSE Ingress hacia microservices de backend en un escenario de colocación de pedidos de comercio electrónico. La arquitectura consta de un gateway MSE Ingress y un backend Spring Cloud con tres aplicaciones: un centro de transacciones (Aplicación A), un centro de productos (Aplicación B) y un centro de inventario (Aplicación C). Un cliente o una página HTML accede a estas aplicaciones de backend, las cuales están registradas en una instancia de Nacos.

Cuando un cliente realiza un pedido, el tráfico fluye a través del gateway MSE Ingress y se enruta secuencialmente a la Aplicación A, la Aplicación B y la Aplicación C: Cliente -> gateway MSE Ingress -> Aplicación A -> Aplicación B -> Aplicación C.

Antes de publicar nuevas versiones de la Aplicación A y la Aplicación C, debe probar la nueva versión en ambas aplicaciones mediante una versión canary. Una vez comprobada la estabilidad de la versión, puede publicarla tanto para la Aplicación A como para la Aplicación C. La función de versión canary de extremo a extremo, basada en gateways MSE Ingress y Microservices Governance, garantiza que el tráfico canary con características específicas siempre se enrute a las versiones canary en múltiples aplicaciones. Si una aplicación no tiene una versión canary, el tráfico se enruta automáticamente a su entorno base.

全链路灰度场景

Términos

Lane

Entorno aislado definido para aplicaciones de la misma versión. Solo el tráfico que coincide con reglas específicas de control de tráfico se enruta a las aplicaciones dentro de un lane. Una aplicación puede pertenecer a varios lanes y un lane puede contener varias aplicaciones. Existe una relación de muchos a muchos entre las aplicaciones y los lanes.
Lane group

Conjunto de lanes utilizado para distinguir entre diferentes equipos o escenarios.
MSE Ingress gateway

Un MSE Ingress gateway gestiona el tráfico de Ingress basándose en gateways nativos de la nube de MSE. Es compatible con NGINX Ingress y admite más de 50 anotaciones de NGINX Ingress, lo que permite realizar versiones canary para múltiples versiones de servicios simultáneamente. Gracias a su gobernanza de servicios flexible y su protección de seguridad integral, satisface las demandas de gobernanza de tráfico de aplicaciones distribuidas nativas de la nube a gran escala.

Requisitos previos

Habilitar Microservices Governance para las aplicaciones

Active MSE Microservices Governance Professional Edition.

Para obtener más información, consulte Activate Microservices Governance.
Habilite Microservices Governance para las aplicaciones.
1. Inicie sesión en la consola de MSE.
2. En el panel de navegación izquierdo, seleccione Microservices Governance > O&M Center > K8s cluster list. Localice el clúster que desea gestionar y haga clic en Manage en la columna Actions.
3. En la página cluster details, localice el namespace que desea gestionar y haga clic en Activate Microservices Governance en la columna Operation. En el mensaje que aparece, haga clic en OK.

Desplegar aplicaciones de demostración

Inicie sesión en la Consola de administración de Container Service.
En el panel de navegación izquierdo, haga clic en Clusters.
En la página Cluster List, haga clic en el nombre del clúster de destino o en Details en la columna Actions.
En el panel de navegación izquierdo de la página de gestión del clúster, seleccione Workload > Deployments.
En la página Stateless, seleccione un elemento en Namespaces y haga clic en Create from YAML.

Configure la plantilla y haga clic en Create.

En este ejemplo, se despliega una aplicación Nacos Server para el descubrimiento de servicios. Se despliegan las aplicaciones A, B y C. Se despliegan versiones base y canary para las aplicaciones A y C, y una versión base para la aplicación B.

Despliegue la aplicación nacos-server.

Show YAML content

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

# The configuration of the nacos-server service.
---
apiVersion: v1
kind: Service
metadata:
  name: nacos-server
spec:
  ports:
  - port: 8848
    protocol: TCP
    targetPort: 8848
  selector:
    app: nacos-server
  type: ClusterIP

Despliegue la Aplicación A.

Código YAML para la versión base

Show the YAML code for the base version

apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-a
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-a
  template:
    metadata:
      labels:
        app: spring-cloud-a
        msePilotAutoEnable: 'on'
        msePilotCreateAppName: 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-governance-demo/spring-cloud-a:3.0.1
        imagePullPolicy: Always
        name: spring-cloud-a
        ports:
        - containerPort: 20001
        livenessProbe:
          tcpSocket:
            port: 20001
          initialDelaySeconds: 10
          periodSeconds: 30

Código YAML para la versión canary

Show the YAML code for the canary version

apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-a-gray
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-a-gray
  strategy:
  template:
    metadata:
      labels:
        app: spring-cloud-a-gray
        msePilotAutoEnable: 'on'
        alicloud.service.tag: gray
        msePilotCreateAppName: 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-governance-demo/spring-cloud-a:3.0.1
        imagePullPolicy: Always
        name: spring-cloud-a-gray
        ports:
        - containerPort: 20001
        livenessProbe:
          tcpSocket:
            port: 20001
          initialDelaySeconds: 10
          periodSeconds: 30

Despliegue la Aplicación B.

Código YAML para la versión base

Show the YAML code for the base version

apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-b
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-b
  strategy:
  template:
    metadata:
      labels:
        app: spring-cloud-b
        msePilotAutoEnable: 'on'
        msePilotCreateAppName: 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-governance-demo/spring-cloud-b:3.0.1
        imagePullPolicy: Always
        name: spring-cloud-b
        ports:
        - containerPort: 8080
        livenessProbe:
          tcpSocket:
            port: 20002
          initialDelaySeconds: 10
          periodSeconds: 30

Despliegue la Aplicación C.

Código YAML para la versión base

Show the YAML code for the base version

apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-c
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-c
  template:
    metadata:
      labels:
        app: spring-cloud-c
        msePilotAutoEnable: 'on'
        msePilotCreateAppName: 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-governance-demo/spring-cloud-c:3.0.1
        imagePullPolicy: Always
        name: spring-cloud-c
        ports:
        - containerPort: 8080
        livenessProbe:
          tcpSocket:
            port: 20003
          initialDelaySeconds: 10
          periodSeconds: 30

Código YAML para la versión canary

Show the YAML code for the canary version

apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-c-gray
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-c-gray
  template:
    metadata:
      labels:
        app: spring-cloud-c-gray
        msePilotAutoEnable: 'on'
        alicloud.service.tag: gray
        msePilotCreateAppName: 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-governance-demo/spring-cloud-c:3.0.1
        imagePullPolicy: IfNotPresent
        name: spring-cloud-c-gray
        ports:
        - containerPort: 8080
        livenessProbe:
          tcpSocket:
            port: 20003
          initialDelaySeconds: 10
          periodSeconds: 30

Configure dos servicios de Kubernetes para la Aplicación A, que funciona como aplicación de ingreso.
1. Inicie sesión en la consola de ACK.
2. En el panel de navegación izquierdo de la página de gestión del clúster, seleccione Network > Services.
3. En la página Service, seleccione un elemento en Namespaces, haga clic en Create from YAML, configure la plantilla y luego haga clic en Create.
  - Código YAML para el servicio spring-cloud-a-base desplegado para la versión base de la Aplicación A
    View YAML content
    
    apiVersion: v1 kind: Service metadata: name: spring-cloud-a-base spec: ports: - name: http port: 20001 protocol: TCP targetPort: 20001 selector: app: spring-cloud-a
  - Código YAML para el servicio spring-cloud-a-gray desplegado para la versión canary de la Aplicación A
    View YAML content
    
    apiVersion: v1 kind: Service metadata: name: spring-cloud-a-gray spec: ports: - name: http port: 20001 protocol: TCP targetPort: 20001 selector: app: spring-cloud-a-gray

Paso 1: Crear un lane group

Inicie sesión en la consola de MSE y seleccione una región en la barra de navegación superior.
En el panel de navegación izquierdo, seleccione Microservices Governance > Full link Grayscale.
En la página End-to-end Canary Release, haga clic en Create Lane Groups and Lanes. Si ya existe un lane group en el namespace de microservicios seleccionado, haga clic en +Create Lane Group.

En el panel Create Lane Group, establezca los parámetros del lane group y haga clic en OK.

Parámetro	Descripción
Name of Lane Group	Introduzca un nombre para el lane group.
Entry Type	Seleccione Other Gateways. Para otros gateways, como NGINX Ingress, APISIX o gateways Java autogestionados, debe implementar reglas de reenvío canary directamente en ellos.
Lane group involves application	Seleccione todos los servicios involucrados en su aplicación de ingreso o gateway Ingress.

Una vez creado el lane group, compruebe que la aplicación de ingreso y todas las aplicaciones involucradas sean correctas. Puede consultar el lane group en la sección Lane Groups and Involved Applications de la página End-to-end Canary Release. Para modificar la información del lane group, haga clic en el icono situado a la derecha y actualice la información.

Paso 2: Crear un lane

En la parte superior de la página de versión canary de extremo a extremo, seleccione la misma región que su lane group y luego haga clic en Create First Split Lane en la parte inferior de la página.

Si ya existe un lane en el namespace de microservicios seleccionado, haga clic en Create Lane.

Importante
Si la función de versión canary de extremo a extremo está habilitada para las aplicaciones, se recomienda no utilizar las funciones de versión canary y enrutamiento basado en etiquetas para dichas aplicaciones.

En el panel Create Lane, establezca los parámetros del lane y haga clic en OK.

Importante

Si su gateway es un Ingress gateway, debe configurar reglas de enrutamiento Ingress en la consola de ACK.

Parámetro	Descripción
Add Node Tag	Método de configuración: En la consola de ACK, agregue `alicloud.service.tag: ${tag}` a `spec.template.metadata.labels` en el archivo YAML de la aplicación. Agregar una etiqueta: Agregue los siguientes pares clave-valor a `spec.template.metadata.labels`. `msePilotCreateAppName:${AppName}` `alicloud.service.tag:{tag}`
Lane Name	Introduzca un nombre para el lane.
Lane Tag	Después de hacer clic en Add Node Tag, aparecerá una lista de las etiquetas correspondientes en la lista desplegable. Al seleccionar una etiqueta, la aplicación correspondiente se agrega automáticamente.

Una vez creado el lane, puede consultar o configurar su información en la sección Traffic Distribution de la página End-to-end Canary Release.

Haga clic en el icono para consultar el porcentaje de tráfico del lane.
Haga clic en el icono en la columna Actions de la lista de lanes para establecer el estado de la aplicación en el lane.
- Habilitar lane: Haga clic en Enable. Esto activa el lane y el tráfico se enruta según la configuración del mismo. El tráfico coincidente se enruta prioritariamente a la versión de la aplicación con la etiqueta de lane correspondiente. Si no existe una versión etiquetada, el tráfico se enruta a la versión sin etiqueta.
- Deshabilitar lane: Haga clic en Close. El tráfico para esta aplicación se enruta a la versión sin etiqueta.
- Modificar lane: Haga clic en Edit para modificar la configuración del lane.
- Eliminar lane: Haga clic en Delete para eliminar el lane.

Paso 3: Configurar reglas de Ingress para versiones base

Si el nombre de dominio del servicio es example.com y desea enrutar el tráfico únicamente a las versiones base (versiones en producción), utilice el siguiente YAML para configurar las reglas de Ingress para las versiones base.

View YAML content

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: spring-cloud-a
  namespace: default
spec:
  ingressClassName: mse
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: spring-cloud-a-base
                port:
                  number: 20001
            path: /
            pathType: Prefix

Utilice el comando curl para acceder a example.com y enrutar el tráfico a las versiones base.

curl -H "host: example.com" http://47.98.xxx.xx/a

Resultado de ejemplo:

A[192.168.0.98][config=base] -> B[192.168.0.157] -> C[192.168.0.161]

Paso 4: Configurar reglas de enrutamiento de Ingress para las versiones canary

Utilice una regla de enrutamiento basada en encabezados para distinguir el tráfico base del tráfico canary. Para enrutar solicitudes con el encabezado HTTP x-user-id: 100 a las versiones canary al acceder a example.com, configure la siguiente regla de enrutamiento de Ingress. Las solicitudes se enrutan prioritariamente a la versión canary de cada aplicación. Si una aplicación no tiene versión canary, las solicitudes se enrutan a su versión base.

Show YAML code

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: 'true'
    nginx.ingress.kubernetes.io/canary-by-header: x-user-id
    nginx.ingress.kubernetes.io/canary-by-header-value: '100'
    mse.ingress.kubernetes.io/request-header-control-update: x-mse-tag gray
  name: spring-cloud-a-gray
  namespace: default
spec:
  ingressClassName: mse
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: spring-cloud-a-gray
                port:
                  number: 20001
            path: /
            pathType: Prefix

El código anterior utiliza anotaciones para implementar la versión canary, la configuración de encabezados y el control de encabezados. Para obtener más información sobre estas anotaciones, consulte Container Service for Kubernetes:Advanced usage of MSE Ingress.

Ejecute el comando curl para acceder a example.com y enrutar las solicitudes con el encabezado HTTP x-user-id: 100 a las versiones canary.

curl -H "host: example.com" -H "x-user-id: 100" http://47.98.xxx.xx/a

Resultado de ejemplo: el tráfico canary se enruta a las versiones canary de las aplicaciones A y C. La aplicación B recibe tráfico en su versión base porque no hay ninguna versión canary disponible.

Agray[192.168.0.128][config=base] -> B[192.168.0.152] -> Cgray[192.168.0.151]

Consulta de gráficos de monitoreo de tráfico de aplicaciones en la consola de MSE

Consulte el gráfico de monitoreo de una sola aplicación.
1. En la página Full link grayscale, haga clic en la pestaña del lane group cuya información de monitoreo desea consultar.
2. En la sección Lane Groups and Involved Applications, haga clic en el nombre de la aplicación cuya información de monitoreo desea consultar. Los datos de consultas por segundo (QPS) se muestran en la sección QPS data a la derecha de la página.
Consulte los gráficos de monitoreo de todas las aplicaciones del lane group.
1. En la página Full link grayscale, haga clic en la pestaña del lane group cuya información de monitoreo desea consultar.
2. A la derecha de la sección Application QPS Monitoring, haga clic en View Traffic Details para ver los gráficos de monitoreo de tráfico de todas las aplicaciones del lane group.