Alibaba Cloud Service Mesh:Use o proxy de malha entre clusters do ASM para implementar comunicação entre redes em vários clusters

Informações básicas

O ASM suporta o modo multicluster, permitindo adicionar vários clusters ACK à mesma instância do ASM, inclusive aqueles residentes em redes diferentes. Caso não seja possível estabelecer comunicação entre redes na Camada 3 devido a restrições de infraestrutura, conflitos de blocos CIDR ou custos, utilize os proxies de malha entre clusters do ASM para conectá-los. Esses proxies permitem conectar os clusters de forma flexível usando redes públicas e privadas. Assim, é possível resolver conflitos de blocos CIDR sem modificar o código do serviço, além de implementar governança de tráfego centralizada, proteção de segurança e observabilidade ponta a ponta para múltiplos clusters. Este tópico descreve como usar os proxies de malha entre clusters do ASM para configurar a comunicação entre redes para vários clusters adicionados à mesma instância. Neste exemplo, a aplicação sleep acessa a aplicação HTTPBin entre clusters.

Benefícios

Os proxies de malha entre clusters, disponíveis em instâncias do ASM V1.22 e posteriores, implementam completamente o balanceamento de carga da Camada 7. As capacidades de roteamento dos gateways leste-oeste do ASM em cenários de comunicação entre clusters são idênticas às dos cenários sem comunicação entre clusters.

Pré-requisitos

• Crie uma instância do ASM com versão 1.22 ou posterior. Para mais informações, consulte Criar uma instância do ASM.

• Adicione vários clusters à instância do ASM. Para mais informações, consulte Adicionar um cluster a uma instância do ASM. (Neste exemplo, dois clusters são adicionados.)

• Ative a injeção automática de proxy sidecar na instância do ASM. Para mais informações, consulte a seção "Ativar injeção automática de proxy sidecar" no tópico Gerenciar namespaces globais.

• O acesso entre clusters para serviços só estará disponível se uma das duas condições a seguir for atendida:

  • O recurso de proxy DNS (Domain Name System) está ativado na instância do ASM. Para mais informações, consulte Usar proxy DNS no ASM. Recomendamos este método.

  • Um serviço de destino idêntico ao existente no cluster servidor foi criado manualmente no cluster cliente.

Etapa 1: Associar um elastic IP address (EIP) ao plano de controle da instância do ASM

Se o cluster no plano de dados não conseguir se comunicar com a virtual private cloud (VPC) onde reside a instância do ASM e você desejar conectar os planos de dados e de controle pela Internet, associe um EIP à instância SLB do endpoint Istio Pilot do plano de controle para expô-lo à Internet.

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 nome da instância do ASM. No painel de navegação à esquerda, escolha ASM Instance > Base Information.

3. No lado direito da página Basic Information, selecione Istio Pilot Endpoint e clique em Bind EIP.

Etapa 2: Configurar as definições de rede para os clusters e ativar proxies de malha entre clusters

Especifique uma rede lógica para cada cluster. Serviços na mesma rede lógica podem acessar uns aos outros diretamente. Serviços em redes lógicas diferentes precisam usar proxies de malha entre clusters para se comunicarem.

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 nome da instância do ASM. No painel de navegação à esquerda, escolha Cluster & Workload Management > Kubernetes Clusters.

3. Clique em Multi-cluster Network Configurations e conclua a configuração usando os métodos a seguir:

   • Defina Homing Logical Network Name como network1 para o ACK 1.

   • Defina Homing Logical Network Name como network2 para o ACK 2 e ative Enable Access Through Cross-cluster Mesh Proxy no ACK 2.

   

Após aplicar as configurações anteriores, o ASM cria um proxy de malha entre clusters padrão no ACK 2, associado a um EIP. Os serviços no ACK 1 usam automaticamente esse proxy para acessar os serviços no ACK 2, com criptografia mutual transport layer security (mTLS) ativada por padrão para esse caminho de comunicação.

Visualize a definição do proxy de malha entre clusters no arquivo kubeconfig do cluster correspondente. O proxy segue o formato de nomenclatura: asm-cross-network-${ACK ID}. Ajuste as configurações, como recursos e número de réplicas, conforme as necessidades do seu negócio.

Etapa 3: Verificar o acesso entre clusters

As configurações de rede entram em vigor quando os pods da aplicação correspondente são iniciados. Se um pod da aplicação já estiver em execução antes da modificação das configurações de rede, reinicie-o.

1. Crie a aplicação sleep no ACK 1. Conteúdo YAML de exemplo:

   sleep.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
   ---

2. Crie a aplicação HTTPBin no ACK 2. Conteúdo YAML de exemplo:

   httpbin.yaml

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: httpbin
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: httpbin
     labels:
       app: httpbin
       service: httpbin
   spec:
     ports:
     - name: http
       port: 8000
       targetPort: 80
     selector:
       app: httpbin
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: httpbin
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: httpbin
         version: v1
     template:
       metadata:
         labels:
           app: httpbin
           version: v1
       spec:
         serviceAccountName: httpbin
         containers:
         - image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/httpbin:0.1.0
           imagePullPolicy: IfNotPresent
           name: httpbin
           ports:
           - containerPort: 80

3. Acesse a aplicação HTTPBin a partir do pod que executa a aplicação sleep. Conecte-se ao pod com base nas informações do arquivo kubeconfig do ACK 1.

   1. Obtenha o nome do pod que executa a aplicação sleep.

      kubectl get pod | grep sleep

   2. Execute o comando curl para acessar a aplicação HTTPBin a partir da aplicação sleep.

      kubectl exec ${Name of the pod running the sleep application} -- curl httpbin:8000/status/418

      A saída a seguir indica acesso bem-sucedido:

        % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                       Dload  Upload   Total   Spent    Left  Speed
      100   135  100   135    0     0  16075      0 --:--:-- --:--:-- --:--:-- 16875
      
          -=[ teapot ]=-
      
             _...._
           .'  _ _ `.
          | ."` ^ `". _,
          \_;`"---"`|//
            |       ;/
            \_     _/
              `"""`

4. Verifique se a aplicação sleep usa o proxy de malha entre clusters para acessar a aplicação HTTPBin.

   1. Verifique os logs do pod que executa a aplicação sleep. Conecte-se ao pod com base nas informações do arquivo kubeconfig do ACK 1.

      kubectl logs ${Name of the pod running the sleep application} -c istio-proxy | tail -1

      A seguinte saída de comando é retornada:

      {"authority_for":"httpbin:8000","bytes_received":"0","bytes_sent":"135","downstream_local_address":"xxx.xxx.xxx.xx:8000","downstream_remote_address":"xx.x.xxx.xxx:xxxxx","duration":"7","istio_policy_status":"-","method":"GET","path":"/status/418","protocol":"HTTP/1.1","request_id":"08dc43e9-60c8-4f2f-910a-b727172ce311","requested_server_name":"-","response_code":"418","response_flags":"-","route_name":"default","start_time":"2024-05-23T10:06:27.289Z","trace_id":"-","upstream_cluster":"outbound|8000||httpbin.default.svc.cluster.local","upstream_host":"xxx.xx.xxx.xxx:15443","upstream_local_address":"xx.x.xxx.xxx:60248","upstream_response_time":"7","upstream_service_time":"7","upstream_transport_failure_reason":"-","user_agent":"curl/8.1.2","x_forwarded_for":"-"}

      O campo upstream_host identifica o serviço de destino acessado diretamente pelo pod que executa a aplicação sleep. A saída mostra que o acesso ocorre na porta 15443, porta dedicada do proxy de malha entre clusters.

   2. Verifique os logs do proxy de malha entre clusters. Conecte-se aos pods com base nas informações do arquivo kubeconfig do ACK 2.

      Primeiro, obtenha o pod que executa o proxy de malha entre clusters.

      kubectl -n istio-system get pod | grep asm-cross-network
      
      istio-asm-cross-network-c0859be51XXX   1/1     Running   0          20h
      istio-asm-cross-network-c0859be51XXX   1/1     Running   0          20h

      A saída mostra que dois pods executam o proxy de malha entre clusters por padrão. Verifique os logs desses dois pods separadamente. Os logs são semelhantes.

       kubectl logs istio-asm-cross-network-c0859be51XXX -n istio-system  | tail -1
      
      {"authority_for":"-","bytes_received":"xxxx","bytes_sent":"xxxx","downstream_local_address":"xx.xx.x.xx:15443","downstream_remote_address":"xx.xx.xx.xx:xxxxx","duration":"1568569","istio_policy_status":"-","method":"-","path":"-","protocol":"-","request_id":"-","requested_server_name":"outbound_.8000_._.httpbin.default.svc.cluster.local","response_code":"0","response_flags":"-","route_name":"-","start_time":"2024-05-23T08:41:16.618Z","trace_id":"-","upstream_cluster":"outbound_.8000_._.httpbin.default.svc.cluster.local","upstream_host":"xx.xx.xx.xxx:80","upstream_local_address":"xx.x.xx.xx:xxxxx","upstream_response_time":"-","upstream_service_time":"-","upstream_transport_failure_reason":"-","user_agent":"-","x_forwarded_for":"-"}