Alibaba Cloud Service Mesh:Configure recuperação de desastres multicluster com uma arquitetura multi-master do ASM

Contexto

A arquitetura de plano de controle multi-master é um modelo para gerenciar vários clusters Kubernetes por meio de uma service mesh. Nesse modelo, cada instância do Service Mesh (ASM) gerencia os componentes do plano de dados do cluster Kubernetes correspondente e distribui configurações para os proxies da mesh dentro desse cluster. Ao compartilhar um certificado raiz comum, essas instâncias permitem a descoberta e a comunicação de serviços entre clusters.

Em relação à abordagem de adicionar vários clusters a uma única instância do ASM, a arquitetura de plano de controle multi-master apresenta as seguintes vantagens:

• Menor latência na entrega de configurações: Clusters múltiplos frequentemente abrangem diferentes regiões, zonas ou VPCs. Nesse cenário, o uso de várias instâncias do ASM, geograficamente mais próximas de seus respectivos clusters Kubernetes, garante uma entrega mais rápida das configurações aos proxies da mesh.

• Maior isolamento de configurações e ambiente: Cada cluster é gerenciado por uma instância distinta do ASM. Isso permite implantar recursos diferentes no plano de controle, viabilizando canary releases ou isolamento de configurações e versões. Durante atualizações das instâncias do ASM, é possível atualizar os planos de controle em lotes, o que aumenta a disponibilidade do ambiente de produção.

• Estabilidade aprimorada: Em situações extremas, como falhas em uma zona ou região inteira, um único plano de controle conectado a todos os clusters pode se tornar um ponto único de falha, impedindo a sincronização de configurações. Na arquitetura multi-master, os proxies da mesh em regiões ou zonas saudáveis continuam conectados aos seus planos de controle locais, assegurando que a entrega de configurações e a inicialização dos proxies não sejam afetadas.

Para construir uma arquitetura de plano de controle multi-master, crie várias instâncias do ASM que compartilhem o mesmo certificado raiz do ASM. O plano de controle utiliza esse certificado raiz para assinar certificados de identidade dos proxies da mesh. Com o uso de um certificado raiz compartilhado, os proxies conectados a diferentes instâncias do ASM estabelecem confiança mútua e se comunicam via mTLS.

Pré-requisitos

São necessários dois clusters gerenciados ACK, denominados cluster-1 e cluster-2. Ambos devem ter a opção Expose API server with EIP ativada. Para mais informações, consulte Criar um cluster gerenciado ACK.

Etapa 1: Crie duas instâncias do ASM com um certificado raiz compartilhado

1. Faça login no console do ASM. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.

2. Na página Mesh Management, clique em Create ASM Instance. A tabela a seguir descreve os principais parâmetros.

   Parâmetro	Valor
   Service mesh name	mesh-1.
   Region	Selecione a mesma região do cluster-1.
   Istio version	Selecione v1.22.6.71-g7d67a80b-aliyun ou uma versão posterior.
   Kubernetes clusters	Selecione cluster-1. Os parâmetros de VPC e vSwitch são preenchidos automaticamente.

   Para mais detalhes sobre outros parâmetros, consulte Criar uma instância do ASM. Após a criação da instância, aguarde de 2 a 3 minutos até que o status da instância mesh-1 mude para Running.

3. Ainda na página Mesh Management, clique novamente em Create ASM Instance. A tabela abaixo detalha os parâmetros essenciais.

   Parâmetro	Valor
   Service mesh name	mesh-2.
   Region	Selecione a mesma região do cluster-2.
   Istio version	Selecione v1.22.6.71-g7d67a80b-aliyun ou uma versão posterior.
   Kubernetes clusters	Selecione cluster-2. Os parâmetros de VPC e vSwitch são preenchidos automaticamente.
   ASM root certificate	Clique em Show Advanced Settings, selecione Reuse an Existing Root Certificate of ASM Instance e, em seguida, escolha mesh-1 na lista suspensa.

   Mantenha os mesmos valores da mesh-1 para os demais parâmetros não especificados na tabela. Depois de criar a instância, aguarde de 2 a 3 minutos até que o status da instância mesh-2 seja alterado para Running.

Etapa 2: Adicionar clusters no modo apenas para descoberta de serviços

Após concluir a Etapa 1, a mesh-1 gerencia o cluster-1 e a mesh-2 gerencia o cluster-2. Para habilitar a descoberta de serviços entre os clusters, adicione o outro cluster a cada instância do ASM no modo apenas para descoberta de serviços. Isso permite que cada instância descubra os serviços e endpoints do outro cluster.

1. Adicione o cluster-2 à instância mesh-1 no modo apenas para descoberta de serviços.

   1. Faça login no console do ASM. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.

   2. Na página Mesh Management, clique em Cluster & Workload Management (Data Plane) > Kubernetes Clusters e clique em Add.

   3. Na página Add Kubernetes Cluster, localize o cluster-2 e clique em Add (For Service Discovery Only) na coluna Actions do cluster. Na caixa de diálogo exibida, clique em OK. Após a adição do cluster, na página Instance Information > Basic Information, o status da instância do ASM muda para Updating. Após alguns segundos (o tempo varia conforme a quantidade de clusters adicionados), clique em no canto superior direito da página para que o status retorne a Running. As informações do cluster adicionado ficam disponíveis na página Kubernetes Clusters.

2. Adicione o cluster-1 à instância mesh-2 no modo apenas para descoberta de serviços.

   1. Faça login no console do ASM. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.

   2. Na página Mesh Management, clique em Cluster & Workload Management (Data Plane) > Kubernetes Clusters e clique em Add.

   3. Na página Add Kubernetes Cluster, localize o cluster-1 e clique em Add (For Service Discovery Only) na coluna Actions. Na caixa de diálogo de confirmação, clique em OK. Após adicionar o cluster, acesse a página Instance Information > Basic Information. O status da instância do ASM mudará para Updating. Aguarde alguns segundos e clique em no canto superior direito. O status da instância retornará para Running. É possível visualizar as informações do cluster adicionado na página Kubernetes Clusters.

      Na página Kubernetes Clusters, o status do cluster-1 aparece como For Service Discovery Only, Synced, enquanto o status do cluster-2 mostra Running, Synced. Isso confirma que ambos os clusters foram adicionados com sucesso à instância do ASM.

Etapa 3 (Opcional): Configure rede multicluster

Se os clusters Kubernetes cluster-1 e cluster-2 estiverem em redes diferentes, como VPCs ou regiões distintas, e essas redes não estiverem conectadas via Cloud Enterprise Network (CEN), configure a rede multicluster em ambas as instâncias do ASM. Também é necessário implantar um proxy da mesh entre clusters tanto no cluster-1 quanto no cluster-2 para garantir a conectividade entre eles. Para mais detalhes sobre o proxy da mesh entre clusters, consulte Recuperação de desastres para vários clusters ACK em diferentes VPCs (usando um proxy da mesh entre clusters do ASM).

1. Na instância mesh-1, defina as configurações de rede para o cluster-1 e o cluster-2.

   1. Faça login no console do ASM. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.

   2. Na página Mesh Management, clique em Cluster & Workload Management (Data Plane) > Kubernetes Clusters.

   3. Clique em Multi-cluster Network Configurations e ajuste as configurações de rede da seguinte forma:

      1. Para o cluster-1, defina a rede lógica como network1 e ative o acesso pelo proxy da mesh entre clusters.

      2. Para o cluster-2, defina a rede lógica como network2.

   Serviços na mesma rede lógica se comunicam diretamente. Já os serviços em redes lógicas diferentes precisam se comunicar através do proxy da mesh entre clusters. Ao ativar o acesso via proxy da mesh entre clusters, um Serviço LoadBalancer é criado automaticamente, o que gera custos de CLB.

1. Na instância mesh-2, defina as configurações de rede para o cluster-1 e o cluster-2.

   1. Faça login no console do ASM. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.

   2. Na página Mesh Management, clique em Cluster & Workload Management (Data Plane) > Kubernetes Clusters.

   3. Clique em Multi-cluster Network Configurations e ajuste as configurações de rede conforme abaixo:

      1. Para o cluster-1, defina a rede lógica como network1.

      2. Para o cluster-2, defina a rede lógica como network2 e ative o acesso pelo proxy da mesh entre clusters.

   Serviços na mesma rede lógica se comunicam diretamente. Serviços em redes lógicas distintas exigem comunicação via proxy da mesh entre clusters. A ativação do acesso pelo proxy da mesh entre clusters cria automaticamente um Serviço LoadBalancer, gerando taxas de CLB.

Etapa 4: Implantar o aplicativo de exemplo

Esta seção explica como implantar o serviço sleep e a versão v1 do serviço helloworld no cluster-1, além da versão v2 do serviço helloworld no cluster-2, conforme ilustrado na figura a seguir. Os serviços nos dois clusters conseguem acessar uns aos outros por meio do proxy da mesh entre clusters.

1. Tanto na instância mesh-1 quanto na mesh-2, ative a injeção automática de sidecar para o namespace padrão. Para mais informações, consulte Gerenciar namespaces globais.

2. Utilize o manifesto YAML a seguir para criar o aplicativo sleep e a versão v1 do aplicativo helloworld.

   YAML

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: sleep
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: sleep
     labels:
       app: sleep
       service: sleep
   spec:
     ports:
     - port: 80
       name: http
     selector:
       app: sleep
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: sleep
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: sleep
     template:
       metadata:
         labels:
           app: sleep
       spec:
         terminationGracePeriodSeconds: 0
         serviceAccountName: sleep
         containers:
         - name: sleep
           image: registry.cn-hangzhou.aliyuncs.com/acs/curl:8.1.2
           command: ["/bin/sleep", "infinity"]
           imagePullPolicy: IfNotPresent
           volumeMounts:
           - mountPath: /etc/sleep/tls
             name: secret-volume
         volumes:
         - name: secret-volume
           secret:
             secretName: sleep-secret
             optional: true
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: helloworld
     labels:
       app: helloworld
   spec:
     ports:
     - port: 5000
       name: http
     selector:
       app: helloworld
   ---
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: helloworld
     labels:
       account: helloworld
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: helloworld-v1
     labels: 
       apps: helloworld
       version: v1
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: helloworld
         version: v1
     template:
       metadata:
         labels:
           app: helloworld
           version: v1
       spec:
         serviceAccount: helloworld
         serviceAccountName: helloworld
         containers:
         - name: helloworld
           image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/examples-helloworld-v1:1.0
           imagePullPolicy: IfNotPresent 
           ports:
           - containerPort: 5000

3. Implante este manifesto no cluster-1. Para mais informações, consulte Criar um Deployment sem estado.

4. Use o manifesto YAML abaixo para criar a versão v2 do aplicativo helloworld.

   YAML

   apiVersion: v1
   kind: Service
   metadata:
     name: helloworld
     labels:
       app: helloworld
   spec:
     ports:
     - port: 5000
       name: http
     selector:
       app: helloworld
   ---
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: helloworld
     labels:
       account: helloworld
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: helloworld-v2
     labels: 
       apps: helloworld
       version: v2
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: helloworld
         version: v2
     template:
       metadata:
         labels:
           app: helloworld
           version: v2
       spec:
         serviceAccount: helloworld
         serviceAccountName: helloworld
         containers:
         - name: helloworld
           image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/examples-helloworld-v2:1.0
           imagePullPolicy: IfNotPresent 
           ports:
           - containerPort: 5000

5. Implante este manifesto no cluster-2. Para mais informações, consulte Criar um Deployment sem estado.

Etapa 5: Verifique a comunicação entre clusters

1. Utilize o arquivo kubeconfig do cluster-1 para executar o comando a seguir:

    kubectl exec -it deploy/sleep -- sh -c 'for i in $(seq 1 10); do curl helloworld:5000/hello; done;'

   Saída esperada:

   Hello version: v1, instance: helloworld-v1-7b888xxxxx-xxxxx
   Hello version: v1, instance: helloworld-v1-7b888xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v1, instance: helloworld-v1-7b888xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v1, instance: helloworld-v1-7b888xxxxx-xxxxx

   A saída indica que as requisições estão sendo balanceadas entre as versões v1 e v2 do serviço helloworld.

2. Execute o comando abaixo para reduzir o número de réplicas do aplicativo sleep no cluster-1 para 0:

   kubectl scale deploy sleep --replicas=0

3. Utilize o manifesto YAML a seguir para criar o aplicativo sleep.

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: sleep
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: sleep
     labels:
       app: sleep
       service: sleep
   spec:
     ports:
     - port: 80
       name: http
     selector:
       app: sleep
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: sleep
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: sleep
     template:
       metadata:
         labels:
           app: sleep
       spec:
         terminationGracePeriodSeconds: 0
         serviceAccountName: sleep
         containers:
         - name: sleep
           image: registry.cn-hangzhou.aliyuncs.com/acs/curl:8.1.2
           command: ["/bin/sleep", "infinity"]
           imagePullPolicy: IfNotPresent

4. Implante o manifesto anterior no cluster-2. Para mais informações, consulte Criar um Deployment sem estado.

5. No cluster-2, execute novamente o seguinte comando:

    kubectl exec -it deploy/sleep -- sh -c 'for i in $(seq 1 10); do curl helloworld:5000/hello; done;'

   Saída esperada:

   Hello version: v1, instance: helloworld-v1-7b888xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v1, instance: helloworld-v1-7b888xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v1, instance: helloworld-v1-7b888xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx

   A saída demonstra que as requisições continuam sendo balanceadas entre as versões v1 e v2 do serviço helloworld.