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

Mecanismo de failover: failover com reconhecimento de localidade em uma service mesh

O ASM oferece um mecanismo de failover com reconhecimento de localidade. O sidecar proxy de cada workload monitora continuamente se o workload de destino retorna erros de resposta consecutivos dentro de uma janela de tempo configurável. Ao detectar falha em um workload, o sidecar proxy o remove do pool de balanceamento de carga e redireciona o tráfego para outros workloads saudáveis.

O exemplo a seguir utiliza dois clusters em duas regiões diferentes, com dois conjuntos paritários de uma aplicação implantados entre eles. Em cada cluster, os workloads de cada serviço são distribuídos uniformemente por diferentes zonas usando restrições de distribuição de topologia.

• Topologia de tráfego normal: Quando todos os serviços estão saudáveis, a service mesh mantém o tráfego dentro da mesma zona para minimizar o impacto da localização de destino na latência da requisição.

Topologias de implantação de aplicações: topologias de cluster suportadas e comparação

O mecanismo de failover com reconhecimento de localidade do ASM aplica-se a diversas topologias de implantação de aplicações. Cada topologia cobre uma faixa diferente de dimensões de falha e varia em custos de recursos e complexidade de O&M.

Implantação com cluster único e múltiplas zonas

Este é o modo de implantação mais simples para recuperação de desastres. Configure um pool de nós multizona, selecione vSwitches de várias zonas para o pool de nós e escolha a política de distribuição equilibrada ao configurar a política de dimensionamento. As instâncias ECS serão então distribuídas uniformemente pelas zonas especificadas para o grupo de dimensionamento.

Implantação com região única, múltiplas zonas e múltiplos clusters

Este modo estende o cluster único de uma implantação com cluster único e múltiplas zonas para vários clusters, cada um com sua própria configuração. Quando ocorre um failover, o ASM busca primeiro outros workloads na mesma zona e, em seguida, seleciona um dos workloads saudáveis em uma zona diferente dentro da mesma região como destino do failover. Selecione zonas distintas para os dois clusters. Se as zonas dos dois clusters se sobrepuserem, workloads na mesma zona podem ter precedência sobre workloads no mesmo cluster, o que pode gerar comportamentos inesperados para o seu negócio.

Implantação com múltiplas regiões e múltiplos clusters

Este modo transforma a implantação de região única de uma arquitetura multicluster em uma implantação multirregião. Ele mantém a implantação de cada serviço dispersa em todas as dimensões: zonas, regiões, clusters e dependências. Dessa forma, workloads saudáveis continuam atendendo ao tráfego quando ocorre uma falha por qualquer motivo.

Implantação com múltiplas regiões e clusters em ambiente multicloud

Esta é a topologia de implantação mais avançada. O ASM suporta totalmente o gerenciamento de clusters Kubernetes de qualquer provedor de cloud e de data centers on-premises. Execute dois ambientes de clusters Kubernetes em provedores de cloud diferentes, ou execute um na cloud e outro on-premises. Se uma infraestrutura falhar, a outra continua fornecendo seus serviços.

Etapa 1: Preparar o ambiente

Conclua as subetapas a seguir em ordem para preparar o ambiente para a demonstração de recuperação de desastres.

1. Crie um cluster Kubernetes em cada uma das duas regiões e nomeie-os como cluster-1 e cluster-2. Configure múltiplas zonas para ambos os clusters e ative Expose API server with EIP. Para mais informações, consulte Create an ACK managed cluster.

2. Nas mesmas duas regiões dos clusters ACK, crie as instâncias do ASM mesh-1 e mesh-2. Ao criar as instâncias, certifique-se de selecionar vSwitches nas mesmas zonas dos clusters ACK. Para mais informações, consulte Step 1, Step 2 e Step 3 em Implement multi-cluster disaster recovery with an ASM multi-master control plane architecture.

3. Em mesh-1 e mesh-2, crie um ingress gateway do tipo NLB chamado ingressgateway. Para as zonas do NLB, selecione as mesmas duas zonas das instâncias do ASM e dos clusters ACK. Para mais informações, consulte Use an NLB instance for an ASM ingress gateway.

4. Em mesh-1 e mesh-2, ative a injeção automática de sidecar para o namespace default dos dois clusters. Essa configuração faz parte do gerenciamento global de namespaces no ASM. Para mais informações, consulte Manage global namespaces.

5. Implante a aplicação de exemplo como pares nos dois clusters ACK. Este exemplo usa duas zonas: cn-hangzhou-h e cn-hangzhou-k. Ajuste as zonas no YAML com base no seu ambiente real.

   Nota

   As imagens de contêiner no YAML a seguir são baixadas do registro da China (Hangzhou) (registry-cn-hangzhou.ack.aliyuncs.com). Se você implantar em várias regiões, certifique-se de que as imagens estejam disponíveis em todas as regiões de destino. Pode ser necessário configurar a sincronização de imagens entre regiões por meio do Container Registry.

   Expanda para visualizar o 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 uma demonstração direta, este exemplo usa o campo nodeSelector para selecionar manualmente a zona de cada pod. Ao construir um ambiente real de alta disponibilidade, configure restrições de distribuição de topologia para distribuir pods por diferentes zonas tanto quanto possível. Para mais informações, consulte Configure high availability for workloads.

6. Configure o Global Traffic Manager (GTM) com as instâncias NLB para implementar recuperação de desastres ativo-ativo para o ingress gateway. Para mais informações, consulte How GTM implements active-active disaster recovery.

Etapa 2: Ativar failover com reconhecimento de localidade

O ASM ativa o failover com reconhecimento de localidade por padrão, mas o recurso só entra em vigor junto com regras de circuit breaking no nível de host configuradas nas destination rules.

1. Implante regras de circuit breaking no nível de host nos clusters cluster-1 e 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 é o mecanismo que a service mesh usa para detecção de falhas de serviço e ejeção de endpoints defeituosos. A tabela a seguir descreve os itens de configuração:

   Item de configuração	Descrição
   interval	Intervalo de execução da detecção de falhas.
   baseEjectionTime	Tempo de espera antes da ejeção de um endpoint do pool de balanceamento de carga após a confirmação de falha.
   maxEjectionPercent	Porcentagem máxima de endpoints passíveis de ejeção.
   consecutive5xxErrors	Número de erros 5xx consecutivos retornados por um endpoint antes de ser considerado defeituoso.
   splitExternalLocalOriginErrors	Define se falhas e timeouts de conexão devem ser contabilizados como erros.
   consecutiveLocalOriginFailures	Número de erros consecutivos não-5xx, como falhas e timeouts de conexão, produzidos por um endpoint antes de ser considerado defeituoso.

2. Verifique o status do serviço.

   Envie uma requisição para o nome de domínio do serviço.

   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)%

   A cadeia de chamadas de serviço permanece nos workloads da mesma zona.

Etapa 3: Realizar um simulado de falha

O exemplo a seguir simula uma falha de workload substituindo manualmente a imagem do contêiner do serviço mockb em uma zona.

1. Substitua a imagem de mockb-cn-hangzhou-h no cluster-2 para simular uma falha.

   1. Faça login no ACK console. No painel de navegação à esquerda, clique em Clusters.

   2. Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Workloads > Deployments.

   3. Na lista, localize o workload mockb-cn-hangzhou-h. Na coluna Actions à direita, clique em Edit. Altere a imagem para registry.cn-hangzhou.aliyuncs.com/acs/curl:8.1.2 e adicione ["sleep","3600"] ao comando no campo Start para que o contêiner possa iniciar corretamente. Clique em Update.

2. Acesse continuamente o nome de domínio da aplicação para visualizar o caminho da requisição após a ocorrência da falha.

   curl mock.asm-demo.work/mock -vResultado esperado 1: A requisição é enviada para uma zona diferente 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)%

   A requisição permanece dentro de uma zona saudável.

   Resultado esperado 2: A requisição é enviada para a zona cn-hangzhou-h na primeira 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%The connection is refused when the request reaches the mockb service.

   Resultado esperado 3: A requisição é enviada novamente para a zona cn-hangzhou-h depois que o sidecar proxy detecta a falha.

   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)%mockb traffic is redirected to cn-hangzhou-k, a different zone in the same region.

(Opcional) Etapa 4: Configurar alertas para falhas no nível de serviço

1. Configure o sidecar proxy para reportar métricas de circuit breaking por meio de proxyStatsMatcher. Ao configurar proxyStatsMatcher, selecione Regular Expression Match e defina o valor como .*outlier_detection.*. Para mais informações, consulte proxyStatsMatcher.

   A tabela a seguir descreve algumas das métricas de circuit breaking:

   Métrica	Tipo de métrica	Descrição
   envoy_cluster_outlier_detection_ejections_active	Gauge	Número de hosts atualmente ejetados.
   envoy_cluster_outlier_detection_ejections_enforced_total	Counter	Número de eventos de ejeção de host.
   envoy_cluster_outlier_detection_ejections_overflow	Counter	Número de vezes que uma ejeção de host foi ignorada porque a porcentagem máxima de ejeção foi excedida.
   ejections_detected_consecutive_5xx	Counter	Número de vezes que um host retornou erros 5xx consecutivos.

2. Reimplante os workloads stateless (mocka, mockb e mockc) para aplicar a configuração atualizada de proxyStatsMatcher. Para mais informações, consulte Redeploy the workload.

3. Crie uma regra de alerta para circuit breaking no nível de host.

   1. Integre o componente Alibaba Cloud ASM ao cluster do plano de dados ou atualize-o para a versão mais recente, permitindo que o Managed Service for Prometheus colete as métricas de circuit breaking expostas. Para mais informações sobre como atualizar o componente de integração, consulte Manage integrations. (Se você já coleta métricas da service mesh com uma instância Prometheus autogerenciada conforme descrito em Integrate a self-managed Prometheus instance for mesh monitoring, pule esta etapa.)

   2. Crie uma regra de alerta para circuit breaking no nível de host. Para mais informações, consulte Create an alert rule for a Prometheus instance. A tabela a seguir fornece exemplos dos parâmetros-chave da regra de alerta. Configure os demais parâmetros conforme seus requisitos, consultando os documentos anteriores.

   Parâmetro	Exemplo	Descrição
   Instrução PromQL personalizada	(sum (envoy_cluster_outlier_detection_ejections_active) by (cluster_name, namespace)) > 0	Consulta a métrica envoy_cluster_outlier_detection_ejections_active para determinar se há hosts atualmente ejetados no cluster e agrupa os resultados por namespace e nome do serviço.
   Conteúdo do alerta	Circuit breaking no nível de host acionado. Um workload retornou erros consecutivos e foi ejetado do pool de balanceamento de carga do serviço! Namespace: {{$labels.namespace}}. Serviço onde ocorreu a ejeção: {{$labels.cluster_name}}. Número de ejeções: {{ $value }}	Mensagem de alerta de exemplo mostrando o namespace e o nome do serviço que acionou o circuit breaking, além do número de hosts atualmente ejetados para esse serviço.