Alibaba Cloud Service Mesh:Use a service mesh for service-level disaster recovery

Mecanismo de failover: failover consciente de la localidad en una service mesh

ASM proporciona un mecanismo de failover consciente de la localidad. El proxy sidecar de cada carga de trabajo monitorea continuamente si la carga de trabajo de destino devuelve errores de respuesta consecutivos dentro de una ventana de tiempo configurable. Cuando el proxy sidecar detecta que una carga de trabajo presenta fallas, la elimina del pool de balanceo de carga y redirige el tráfico a otras cargas de trabajo sanas.

El siguiente ejemplo utiliza dos clústeres en dos regiones diferentes, con dos conjuntos pares de una aplicación desplegados entre ellos. En cada clúster, las cargas de trabajo de cada servicio se distribuyen uniformemente en distintas zonas mediante restricciones de distribución de topología.

• Topología de tráfico normal: cuando todos los servicios están sanos, la service mesh mantiene el tráfico dentro de la misma zona para minimizar el impacto de la ubicación de destino en la latencia de las solicitudes.

Topologías de despliegue de aplicaciones: topologías de clúster compatibles y comparación

El mecanismo de failover consciente de la localidad de ASM se aplica a múltiples topologías de despliegue de aplicaciones. Cada topología cubre un rango diferente de dimensiones de falla y difiere en costos de recursos y complejidad de operación y mantenimiento.

Despliegue de clúster único, multizona

Este es el modo de despliegue más sencillo para la recuperación ante desastres. Configure un node pool multizona, seleccione vSwitches de múltiples zonas para el node pool y elija la directiva de distribución equilibrada al configurar la directiva de escalado. Las instancias ECS se distribuirán entonces uniformemente en las zonas especificadas para el grupo de escalado.

Despliegue de región única, multizona, multiclúster

Este modo extiende el clúster único de un despliegue de clúster único, multizona a múltiples clústeres, cada uno con su propia configuración. Cuando ocurre un failover, ASM busca primero otras cargas de trabajo en la misma zona y luego selecciona una de las cargas de trabajo sanas en una zona diferente dentro de la misma región como destino del failover. Seleccione zonas separadas para los dos clústeres. Si las zonas de los dos clústeres se superponen, las cargas de trabajo en la misma zona pueden tener prioridad sobre las cargas de trabajo en el mismo clúster, lo cual podría resultar inesperado para su negocio.

Despliegue multirregión, multiclúster

Este modo convierte el despliegue de región única de una arquitectura multiclúster en un despliegue multirregión. Mantiene el despliegue de cada servicio disperso en todas las dimensiones: zonas, regiones, clústeres y dependencias. De esta manera, las cargas de trabajo sanas continúan atendiendo el tráfico cuando ocurre una falla por cualquier motivo posible.

Despliegue multirregión, multiclúster en un entorno multinube

Esta es la topología de despliegue más avanzada. ASM admite completamente la gestión de clústeres de Kubernetes de cualquier proveedor de nube y de centros de datos locales. Ejecute dos entornos de clústeres de Kubernetes en diferentes proveedores de nube, o ejecute uno en la nube y otro localmente. Si una infraestructura falla, la otra continúa proporcionando sus servicios.

Paso 1: Preparar el entorno

Complete los siguientes subpasos para preparar el entorno para la demostración de recuperación ante desastres.

1. Cree un clúster de Kubernetes en cada una de dos regiones y asígneles los nombres cluster-1 y cluster-2. Configure múltiples zonas para ambos clústeres y habilite Expose API server with EIP. Para obtener más información, consulte Create an ACK managed cluster.

2. En las mismas dos regiones que los clústeres ACK, cree las instancias de ASM mesh-1 y mesh-2. Al crear las instancias, asegúrese de seleccionar vSwitches en las mismas zonas que los clústeres ACK. Para obtener más información, consulte el Paso 1, Paso 2 y Paso 3 en Implement multi-cluster disaster recovery with an ASM multi-master control plane architecture.

3. En mesh-1 y mesh-2, cree un gateway de entrada de tipo NLB llamado ingressgateway. Para las zonas del NLB, seleccione las mismas dos zonas que las instancias de ASM y los clústeres ACK. Para obtener más información, consulte Use an NLB instance for an ASM ingress gateway.

4. En mesh-1 y mesh-2, habilite la inyección automática de sidecar para el namespace default de los dos clústeres. Esto se configura como parte de la gestión global de namespaces en ASM. Para obtener más información, consulte Manage global namespaces.

5. Despliegue la aplicación de muestra como pares en los dos clústeres ACK. Este ejemplo utiliza dos zonas: cn-hangzhou-h y cn-hangzhou-k. Ajuste las zonas en el YAML según su entorno real.

   Nota

   Las imágenes de contenedor en el siguiente YAML se extraen del registro de China (Hangzhou) (registry-cn-hangzhou.ack.aliyuncs.com). Si realiza el despliegue en varias regiones, asegúrese de que las imágenes estén disponibles en todas las regiones de destino. Es posible que deba configurar la sincronización de imágenes interregional a través de Container Registry.

   Expanda para ver el comando

   kubectl apply -f- <<EOF apiVersion: v1 kind: Service metadata: name: mocka labels: app: mocka service: mocka spec: ports: - port: 8000 name: http selector: app: mocka --- apiVersion: apps/v1 kind: Deployment metadata: name: mocka-cn-hangzhou-h labels: app: mocka spec: replicas: 1 selector: matchLabels: app: mocka template: metadata: labels: app: mocka locality: cn-hangzhou-h spec: nodeSelector: topology.kubernetes.io/zone: cn-hangzhou-h containers: - name: default image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing imagePullPolicy: IfNotPresent env: - name: version value: cn-hangzhou-h - name: app value: mocka - name: upstream_url value: "http://mockb:8000/" ports: - containerPort: 8000 --- apiVersion: apps/v1 kind: Deployment metadata: name: mocka-cn-hangzhou-k labels: app: mocka spec: replicas: 1 selector: matchLabels: app: mocka template: metadata: labels: app: mocka locality: cn-hangzhou-k spec: nodeSelector: topology.kubernetes.io/zone: cn-hangzhou-k containers: - name: default image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing imagePullPolicy: IfNotPresent env: - name: version value: cn-hangzhou-k - name: app value: mocka - name: upstream_url value: "http://mockb:8000/" ports: - containerPort: 8000 --- apiVersion: v1 kind: Service metadata: name: mockb labels: app: mockb service: mockb spec: ports: - port: 8000 name: http selector: app: mockb --- apiVersion: apps/v1 kind: Deployment metadata: name: mockb-cn-hangzhou-h labels: app: mockb spec: replicas: 1 selector: matchLabels: app: mockb template: metadata: labels: app: mockb locality: cn-hangzhou-h spec: nodeSelector: topology.kubernetes.io/zone: cn-hangzhou-h containers: - name: default image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing imagePullPolicy: IfNotPresent env: - name: version value: cn-hangzhou-h - name: app value: mockb - name: upstream_url value: "http://mockc:8000/" ports: - containerPort: 8000 --- apiVersion: apps/v1 kind: Deployment metadata: name: mockb-cn-hangzhou-k labels: app: mockb spec: replicas: 1 selector: matchLabels: app: mockb template: metadata: labels: app: mockb locality: cn-hangzhou-k spec: nodeSelector: topology.kubernetes.io/zone: cn-hangzhou-k containers: - name: default image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing imagePullPolicy: IfNotPresent env: - name: version value: cn-hangzhou-k - name: app value: mockb - name: upstream_url value: "http://mockc:8000/" ports: - containerPort: 8000 --- apiVersion: v1 kind: Service metadata: name: mockc labels: app: mockc service: mockc spec: ports: - port: 8000 name: http selector: app: mockc --- apiVersion: apps/v1 kind: Deployment metadata: name: mockc-cn-hangzhou-h labels: app: mockc spec: replicas: 1 selector: matchLabels: app: mockc template: metadata: labels: app: mockc locality: cn-hangzhou-h spec: nodeSelector: topology.kubernetes.io/zone: cn-hangzhou-h containers: - name: default image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing imagePullPolicy: IfNotPresent env: - name: version value: cn-hangzhou-h - name: app value: mockc ports: - containerPort: 8000 --- apiVersion: apps/v1 kind: Deployment metadata: name: mockc-cn-hangzhou-k labels: app: mockc spec: replicas: 1 selector: matchLabels: app: mockc template: metadata: labels: app: mockc locality: cn-hangzhou-k spec: nodeSelector: topology.kubernetes.io/zone: cn-hangzhou-k containers: - name: default image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing imagePullPolicy: IfNotPresent env: - name: version value: cn-hangzhou-k - name: app value: mockc ports: - containerPort: 8000 --- apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: mocka namespace: default spec: selector: istio: ingressgateway servers: - hosts: - '' port: name: test number: 80 protocol: HTTP --- apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: demoapp-vs namespace: default spec: gateways: - mocka hosts: - '' http: - name: test route: - destination: host: mocka port: number: 8000 EOFAfter you run the preceding commands in both clusters, the services mocka, mockb, and mockc are deployed as peers in both clusters. Each service contains two stateless deployments that have one replica each. Different nodeSelector settings distribute the deployments to nodes in different zones, and environment variables make each deployment return the zone that it resides in.

   Para una demostración sencilla, este ejemplo utiliza el campo nodeSelector para seleccionar manualmente la zona de cada pod. Cuando construya un entorno real de alta disponibilidad, configure restricciones de distribución de topología para distribuir los pods en diferentes zonas tanto como sea posible. Para obtener más información, consulte Configure high availability for workloads.

6. Configure Global Traffic Manager (GTM) con las instancias NLB para implementar la recuperación ante desastres activo-activo para el gateway de entrada. Para obtener más información, consulte How GTM implements active-active disaster recovery.

Paso 2: Habilitar el failover consciente de la localidad

ASM habilita el failover consciente de la localidad de forma predeterminada, pero la función solo surte efecto junto con las reglas de circuit breaking a nivel de host que se configuran en las destination rules.

1. Despliegue reglas de circuit breaking a nivel de host en los clústeres cluster-1 y cluster-2.

   kubectl apply -f- <<EOF apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: mocka spec: host: mocka trafficPolicy: outlierDetection: splitExternalLocalOriginErrors: true consecutiveLocalOriginFailures: 1 baseEjectionTime: 5m consecutive5xxErrors: 1 interval: 30s maxEjectionPercent: 100 --- apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: mockb spec: host: mockb trafficPolicy: outlierDetection: splitExternalLocalOriginErrors: true consecutiveLocalOriginFailures: 1 baseEjectionTime: 5m consecutive5xxErrors: 1 interval: 30s maxEjectionPercent: 100 --- apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: mockc spec: host: mockc trafficPolicy: outlierDetection: splitExternalLocalOriginErrors: true consecutiveLocalOriginFailures: 1 baseEjectionTime: 5m consecutive5xxErrors: 1 interval: 30s maxEjectionPercent: 100 EOF outlierDetection es el mecanismo que utiliza la service mesh para la detección de fallas de servicio y la expulsión de endpoints defectuosos. La siguiente tabla describe los elementos de configuración:

   Elemento de configuración	Descripción
   interval	El intervalo en el que se realiza la detección de fallas.
   baseEjectionTime	El tiempo de espera antes de expulsar un endpoint del pool de balanceo de carga después de determinar que está defectuoso.
   maxEjectionPercent	El porcentaje máximo de endpoints que se pueden expulsar.
   consecutive5xxErrors	El número de errores 5xx consecutivos que devuelve un endpoint antes de determinar que está defectuoso.
   splitExternalLocalOriginErrors	Especifica si se deben contar las fallas de conexión y los tiempos de espera de conexión como fallas.
   consecutiveLocalOriginFailures	El número de errores consecutivos que no son 5xx, como fallas de conexión y tiempos de espera de conexión, que produce un endpoint antes de determinar que está defectuoso.

2. Compruebe el estado del servicio.

   Envíe una solicitud al nombre de dominio del servicio.

   curl mock.asm-demo.work/mock -v

   Host mock.asm-demo.work:80 was resolved. IPv6: (none) IPv4: 8.xxx.xxx.47, 8.xxx.xxx.42 Trying 8.xxx.xxx.47:80... Connected to mock.asm-demo.work (8.209.XXX.XX) port 80 > GET /mock HTTP/1.1 > Host: mock.asm-demo.work > User-Agent: curl/8.7.1 > Accept: / > Request completely sent off < HTTP/1.1 200 OK < date: Wed, 11 Dec 2024 12:10:56 GMT < content-length: 153 < content-type: text/plain; charset=utf-8 < x-envoy-upstream-service-time: 3 < server: istio-envoy < * Connection #0 to host mock.asm-demo.work left intact -> mocka(version: cn-hangzhou-k, ip: 10.1.225.40)-> mockb(version: cn-hangzhou-k, ip: 10.1.225.31)-> mockc(version: cn-hangzhou-k, ip: 10.1.225.32)%

   La cadena de llamadas del servicio permanece en las cargas de trabajo de la misma zona.

Paso 3: Realizar un simulacro de falla

El siguiente ejemplo simula una falla de carga de trabajo reemplazando manualmente la imagen del contenedor del servicio mockb en una zona.

1. Reemplace la imagen de mockb-cn-hangzhou-h en cluster-2 para simular una falla.

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

   2. En la página Clusters, haga clic en el nombre de su clúster. En el panel de navegación izquierdo, haga clic en Workloads > Deployments.

   3. En la lista, busque la carga de trabajo mockb-cn-hangzhou-h. En la columna Actions de la derecha, haga clic en Edit. Cambie la imagen a registry.cn-hangzhou.aliyuncs.com/acs/curl:8.1.2 y agregue ["sleep","3600"] al comando en el campo Start para que el contenedor pueda iniciarse correctamente. Haga clic en Update.

2. Acceda continuamente al nombre de dominio de la aplicación para ver la ruta de la solicitud después de que ocurra la falla.

   curl mock.asm-demo.work/mock -vResultado esperado 1: La solicitud se envía a una zona distinta de cn-hangzhou-h.

   Host mock.asm-demo.work:80 was resolved. IPv6: (none) IPv4: 8.209.XXX.XX, 8.221.XXX.XX Trying 8.209.247.47:80... Connected to mock.asm-demo.work (8.209.247.47) port 80 > GET /mock HTTP/1.1 > Host: mock.asm-demo.work > User-Agent: curl/8.7.1 > Accept: / > Request completely sent off < HTTP/1.1 200 OK < date: Wed, 11 Dec 2024 12:10:56 GMT < content-length: 153 < content-type: text/plain; charset=utf-8 < x-envoy-upstream-service-time: 3 < server: istio-envoy < * Connection #0 to host mock.asm-demo.work left intact -> mocka(version: cn-hangzhou-k, ip: 10.1.225.40)-> mockb(version: cn-hangzhou-k, ip: 10.1.225.31)-> mockc(version: cn-hangzhou-k, ip: 10.1.225.32)%

   La solicitud permanece dentro de una zona sana.

   Resultado esperado 2: La solicitud se envía a la zona cn-hangzhou-h por primera vez.

   Host mock.asm-demo.work:80 was resolved. IPv6: (none) IPv4: 112.124.XX.XXX, 121.41.XXX.XXX Trying 112.124.65.120:80... Connected to mock.asm-demo.work (112.124.65.120) port 80 > GET /mock HTTP/1.1 > Host: mock.asm-demo.work > User-Agent: curl/8.7.1 > Accept: / > Request completely sent off < HTTP/1.1 200 OK < date: Wed, 11 Dec 2024 12:08:45 GMT < content-length: 220 < content-type: text/plain; charset=utf-8 < x-envoy-upstream-service-time: 48 < server: istio-envoy < * Connection #0 to host mock.asm-demo.work left intact -> mocka(version: cn-hangzhou-h, ip: 192.168.122.135)upstream connect error or disconnect/reset before headers. reset reason: remote connection failure, transport failure reason: delayed connect error: Connection refused%Se rechaza la conexión cuando la solicitud llega al servicio mockb.

   Resultado esperado 3: La solicitud se envía nuevamente a la zona cn-hangzhou-h después de que el proxy sidecar detecta la falla.

   Host mock.asm-demo.work:80 was resolved. IPv6: (none) IPv4: 8.209.XXX.XX, 8.221.XXX.XX Trying 8.209.247.47:80... Connected to mock.asm-demo.work (8.209.247.47) port 80 > GET /mock HTTP/1.1 > Host: mock.asm-demo.work > User-Agent: curl/8.7.1 > Accept: / > Request completely sent off < HTTP/1.1 200 OK < date: Wed, 11 Dec 2024 12:10:59 GMT < content-length: 154 < content-type: text/plain; charset=utf-8 < x-envoy-upstream-service-time: 4 < server: istio-envoy < * Connection #0 to host mock.asm-demo.work left intact -> mocka(version: cn-hangzhou-h, ip: 10.0.239.141)-> mockb(version: cn-hangzhou-k, ip: 10.1.225.31)-> mockc(version: cn-hangzhou-k, ip: 10.1.225.32)%El tráfico de mockb se redirige a cn-hangzhou-k, una zona diferente en la misma región.

(Opcional) Paso 4: Configurar alertas para fallas a nivel de servicio

1. Configure el proxy sidecar para reportar métricas de circuit breaking a través de proxyStatsMatcher. Al configurar proxyStatsMatcher, seleccione Regular Expression Match y establezca el valor en .*outlier_detection.*. Para obtener más información, consulte proxyStatsMatcher.

   La siguiente tabla describe algunas de las métricas de circuit breaking:

   Métrica	Tipo de métrica	Descripción
   envoy_cluster_outlier_detection_ejections_active	Gauge	El número de hosts que están actualmente expulsados.
   envoy_cluster_outlier_detection_ejections_enforced_total	Counter	El número de eventos de expulsión de hosts.
   envoy_cluster_outlier_detection_ejections_overflow	Counter	El número de veces que se omitió una expulsión de host porque se excedió el porcentaje máximo de expulsión.
   ejections_detected_consecutive_5xx	Counter	El número de veces que se detectó que un host devolvía errores 5xx consecutivos.

2. Vuelva a desplegar las cargas de trabajo sin estado (mocka, mockb y mockc) para aplicar la configuración actualizada de proxyStatsMatcher. Para obtener más información, consulte Redeploy the workload.

3. Cree una regla de alerta para el circuit breaking a nivel de host.

   1. Integre el componente Alibaba Cloud ASM con el clúster del plano de datos o actualice el componente a la versión más reciente, para que Managed Service for Prometheus pueda recopilar las métricas de circuit breaking expuestas. Para obtener más información sobre cómo actualizar el componente de integración, consulte Manage integrations. (Si ya recopila métricas de service mesh con una instancia de Prometheus autogestionada como se describe en Integrate a self-managed Prometheus instance for mesh monitoring, omita este paso).

   2. Cree una regla de alerta para el circuit breaking a nivel de host. Para obtener más información, consulte Create an alert rule for a Prometheus instance. La siguiente tabla proporciona ejemplos de los parámetros clave de la regla de alerta: Configure los demás parámetros según sus necesidades consultando los documentos anteriores.

   Parámetro	Ejemplo	Descripción
   Declaración PromQL personalizada	(sum (envoy_cluster_outlier_detection_ejections_active) by (cluster_name, namespace)) > 0	El ejemplo consulta la métrica envoy_cluster_outlier_detection_ejections_active para determinar si hay hosts actualmente expulsados en el clúster y agrupa los resultados de la consulta por namespace y nombre del servicio.
   Contenido de la alerta	Se activó el circuit breaking a nivel de host. ¡Una carga de trabajo devolvió errores consecutivos y fue expulsada del pool de balanceo de carga del servicio! Namespace: {{$labels.namespace}}. Servicio donde ocurrió la expulsión: {{$labels.cluster_name}}. Número de expulsioness: {{ $value }}	El mensaje de alerta de ejemplo muestra el namespace y el nombre del servicio que activó el circuit breaking, así como el número de hosts que están actualmente expulsados para ese servicio.