Configurar uma malha de vários clusters fora do Google Cloud

Observação: este guia só oferece suporte ao Cloud Service Mesh com APIs do Istio e não é compatível com APIs Google Cloud . Para mais informações, consulte Visão geral do Cloud Service Mesh.

Neste guia, explicamos como configurar uma malha de vários clusters para as seguintes plataformas:

• Google Distributed Cloud (somente software) para VMware
• Google Distributed Cloud (somente software) em bare metal
• GKE no Azure (descontinuado)
• GKE na AWS (descontinuado)
• Clusters anexados, incluindo clusters do Amazon EKS e do Microsoft AKS (descontinuado)

Neste guia, mostramos como configurar dois clusters, mas é possível ampliar esse processo para incorporar vários clusters à malha.

Observação da plataforma: o comando asmcli create-mesh usado para ativar a descoberta de endpoints exige que todos os clusters estejam na mesma plataforma. Atualmente, asmcli create-mesh só é compatível com malha híbrida no pré-lançamento.

Antes de começar

Neste guia, presumimos que o Cloud Service Mesh foi instalado usando asmcli install. Você precisa do asmcli e do pacote de configuração que o asmcli faz o download para o diretório especificado em --output_dir quando você executou asmcli install. Se precisar de configuração, siga as etapas em Instalar ferramentas dependentes e validar o cluster para:

• Instale as ferramentas necessárias
• Fazer o download de asmcli
• Conceder permissões de administrador de cluster
• Validar o projeto e o cluster

Você precisa ter acesso aos arquivos kubeconfig de todos os clusters que está configurando na malha.

Aviso: use apenas arquivos kubeconfig de fontes confiáveis. O uso de um arquivo kubeconfig criado especialmente pode resultar na execução maliciosa de um código ou na exposição do arquivo. Se você precisar usar um arquivo kubeconfig não confiável, inspecione-o com cuidado primeiro, da mesma forma que faria com um script de shell.

Configurar variáveis de ambiente e marcadores

Você precisa das seguintes variáveis de ambiente ao instalar o gateway leste-oeste.

1. Crie uma variável de ambiente para o número do projeto. No comando a seguir, substitua FLEET_PROJECT_ID pelo ID do projeto host da frota.

   export PROJECT_NUMBER=$(gcloud projects describe FLEET_PROJECT_ID \
   --format="value(projectNumber)")
   

2. Crie uma variável de ambiente para o identificador da malha.

   export MESH_ID="proj-${PROJECT_NUMBER}"
   

3. Crie variáveis de ambiente para os nomes dos clusters no formato exigido por asmcli.

   export CLUSTER_1="cn-FLEET_PROJECT_ID-global-CLUSTER_NAME_1"
   export CLUSTER_2="cn-FLEET_PROJECT_ID-global-CLUSTER_NAME_2"
   

4. Consiga o nome do contexto para os clusters usando os valores na coluna NAME na saída deste comando:

   kubectl config get-contexts

5. Defina as variáveis de ambiente para os nomes de contexto de cluster, o que será usado por este guia em várias etapas posteriores:

   export CTX_1=CLUSTER1_CONTEXT_NAME
   export CTX_2=CLUSTER2_CONTEXT_NAME
   

Instalar o gateway leste-oeste

Nos comandos a seguir:

• Substitua CLUSTER_NAME_1 e CLUSTER_NAME_2 pelos nomes dos clusters.

• Substitua PATH_TO_KUBECONFIG_1 e PATH_TO_KUBECONFIG_2 pelos arquivos kubeconfig dos clusters.

Clusters do GKE

Mesh CA ou serviço de CA

1. Instale um gateway no cluster1 que seja dedicado ao tráfego leste-oeste para $CLUSTER_2. Por padrão, esse gateway será público na Internet. Os sistemas de produção podem exigir outras restrições de acesso, como regras de firewall, para evitar ataques externos.

   Observação :se você instalou o Cloud Service Mesh com valores diferentes para --network_id, transmita os mesmos valores para gen-eastwest-gateway.sh com a flag --network.

   asm/istio/expansion/gen-eastwest-gateway.sh \
       --mesh ${MESH_ID}  \
       --cluster ${CLUSTER_1}  \
       --network default \
       --revision asm-1271-5 | \
       ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_1 \
       install -y --set spec.values.global.pilotCertProvider=istiod -f -
   

2. Instale um gateway em $CLUSTER_2 dedicado ao tráfego leste a oeste para $CLUSTER_1.

   asm/istio/expansion/gen-eastwest-gateway.sh \
       --mesh ${MESH_ID}  \
       --cluster ${CLUSTER_2}  \
       --network default \
       --revision asm-1271-5 | \
       ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 \
       install -y --set spec.values.global.pilotCertProvider=istiod -f -
   

CA do Istio

1. Instale um gateway no cluster1 que seja dedicado ao tráfego leste-oeste para $CLUSTER_2. Por padrão, esse gateway será público na Internet. Os sistemas de produção podem exigir outras restrições de acesso, como regras de firewall, para evitar ataques externos.

   Observação :se você instalou o Cloud Service Mesh com valores diferentes para --network_id, transmita os mesmos valores para gen-eastwest-gateway.sh com a flag --network.

   asm/istio/expansion/gen-eastwest-gateway.sh \
       --mesh ${MESH_ID}  \
       --cluster ${CLUSTER_1}  \
       --network default \
       --revision asm-1271-5 | \
       ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_1 \
       install -y --set spec.values.global.pilotCertProvider=istiod -f -
   

2. Instale um gateway em $CLUSTER_2 dedicado ao tráfego leste a oeste para $CLUSTER_1.

   asm/istio/expansion/gen-eastwest-gateway.sh \
       --mesh ${MESH_ID}  \
       --cluster ${CLUSTER_2}  \
       --network default \
       --revision asm-1271-5 | \
       ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 \
       install -y --set spec.values.global.pilotCertProvider=istiod -f -
   

Observação sobre a plataforma:para o Google Distributed Cloud (somente software) para VMware, um endereço IP externo não será atribuído até mais tarde, quando você concluir as etapas descritas em Configurar endereços IP externos para o Google Distributed Cloud (somente software) para VMware.

Azure, AWS e anexo

Atenção:GKE no Azure e GKE na AWS foram descontinuados e serão desativados em 17 de março de 2027. O suporte do Cloud Service Mesh para clusters anexados, incluindo clusters do Amazon EKS e do Microsoft AKS, foi descontinuado e será encerrado em 17 de março de 2027.

CA da malha

1. Instale um gateway no cluster1 que seja dedicado ao tráfego leste-oeste para $CLUSTER_2. Por padrão, esse gateway será público na Internet. Os sistemas de produção podem exigir outras restrições de acesso, como regras de firewall, para evitar ataques externos.

   Observação :se você instalou o Cloud Service Mesh com valores diferentes para --network_id, transmita os mesmos valores para gen-eastwest-gateway.sh com a flag --network.

   asm/istio/expansion/gen-eastwest-gateway.sh \
       --mesh ${MESH_ID}  \
       --cluster ${CLUSTER_1}  \
       --network default \
       --revision asm-1271-5 | \
       ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_1 \
       install -y --set spec.values.global.pilotCertProvider=istiod -f -
   

2. Instale um gateway em $CLUSTER_2 dedicado ao tráfego leste a oeste para $CLUSTER_1.

   asm/istio/expansion/gen-eastwest-gateway.sh \
       --mesh ${MESH_ID}  \
       --cluster ${CLUSTER_2}  \
       --network default \
       --revision asm-1271-5 | \
       ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 \
       install -y --set spec.values.global.pilotCertProvider=istiod -f -
   

CA do Istio

1. Instale um gateway no cluster1 que seja dedicado ao tráfego leste-oeste para $CLUSTER_2. Por padrão, esse gateway será público na Internet. Os sistemas de produção podem exigir outras restrições de acesso, como regras de firewall, para evitar ataques externos.

   Observação :se você instalou o Cloud Service Mesh com valores diferentes para --network_id, transmita os mesmos valores para gen-eastwest-gateway.sh com a flag --network.

   asm/istio/expansion/gen-eastwest-gateway.sh \
       --mesh ${MESH_ID}  \
       --cluster ${CLUSTER_1}  \
       --network default \
       --revision asm-1271-5 | \
       ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_1 \
       install -y --set spec.values.global.pilotCertProvider=istiod -f -
   

2. Instale um gateway em $CLUSTER_2 dedicado ao tráfego leste a oeste para $CLUSTER_1.

   asm/istio/expansion/gen-eastwest-gateway.sh \
       --mesh ${MESH_ID}  \
       --cluster ${CLUSTER_2}  \
       --network default \
       --revision asm-1271-5 | \
       ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 \
       install -y --set spec.values.global.pilotCertProvider=istiod -f -
   

Como expor serviços

Como os clusters estão em redes separadas, é necessário expor todos os serviços (*.local) no gateway leste-oeste em ambos os clusters. Embora este gateway seja público na Internet, os serviços por trás dele só poderão ser acessados por serviços com um certificado mTLS confiável e um ID de carga de trabalho, como se estivessem na mesma rede.

1. Exponha os serviços por meio do gateway leste-oeste para o CLUSTER_NAME_1.

   kubectl --kubeconfig=PATH_TO_KUBECONFIG_1 apply -n istio-system -f \
       asm/istio/expansion/expose-services.yaml
   

2. Exponha os serviços por meio do gateway leste-oeste para o CLUSTER_NAME_2.

   kubectl --kubeconfig=PATH_TO_KUBECONFIG_2 apply -n istio-system -f \
       asm/istio/expansion/expose-services.yaml
   

Ativar descoberta de endpoints

Observação:: saiba mais sobre a descoberta de endpoints em Descoberta de endpoints com vários planos de controle.

Execute o comando asmcli create-mesh para ativar a descoberta de endpoints. Este exemplo mostra apenas dois clusters, mas é possível executar o comando para ativar a descoberta de endpoints em clusters adicionais, sujeitos ao limite de serviço do GKE Hub.

  ./asmcli create-mesh \
      FLEET_PROJECT_ID \
      PATH_TO_KUBECONFIG_1 \
      PATH_TO_KUBECONFIG_2

Verificar a conectividade de vários clusters

Nesta seção, você verá como implantar os serviços de amostra HelloWorld e Sleep no ambiente de vários clusters para verificar se o balanceamento de carga entre eles funciona.

Observação :esses serviços de amostra estão localizados no diretório samples do Istio incluído no tarball istioctl (localizado em OUTPUT_DIR/istio-${ASM_VERSION%+*}/samples) e não no diretório samples transferido por download em asmcli (localizado em OUTPUT_DIR/samples).

Ative a injeção de sidecar

1. Crie o namespace de amostra em cada cluster.

   for CTX in ${CTX_1} ${CTX_2}
   do
       kubectl create --context=${CTX} namespace sample
   done
   

2. Ative a injeção de sidecar nos namespaces criados.

   Recomendado:execute o comando a seguir para aplicar o rótulo de injeção padrão ao namespace:

   for CTX in ${CTX_1} ${CTX_2}
   do
       kubectl label --context=${CTX} namespace sample \
           istio.io/rev- istio-injection=enabled --overwrite
   done
   

   Recomendamos que você use a injeção padrão, mas a injeção baseada em revisão é compatível. Use as seguintes instruções:

   1. Use o seguinte comando para localizar o rótulo de revisão em istiod:

      kubectl get deploy -n istio-system -l app=istiod -o \
          jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
      

   2. Aplique o rótulo de revisão ao namespace. No comando a seguir, REVISION_LABEL é o valor do rótulo de revisão istiod que você anotou na etapa anterior.

      for CTX in ${CTX_1} ${CTX_2}
      do
          kubectl label --context=${CTX} namespace sample \
              istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      done
      

Instalar o serviço HelloWorld

Observação: o exemplo do serviço HelloWorld usa o Docker Hub. Em um cluster particular, o ambiente de execução do contêiner pode extrair imagens do Artifact Registry por padrão. O ambiente de execução do contêiner não pode extrair imagens de outros registros de imagem de contêineres na Internet. É possível fazer o download e enviar a imagem para o Artifact Registry ou usar o Cloud NAT para fornecer acesso de saída à Internet para determinados nós particulares. Para mais informações, consulte Migrar contêineres externos e Como criar um cluster particular.

• Crie o serviço HelloWorld em ambos os clusters:

  kubectl create --context=${CTX_1} \
      -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
      -l service=helloworld -n sample
  

  kubectl create --context=${CTX_2} \
      -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
      -l service=helloworld -n sample
  

Implantar o HelloWorld v1 e v2 em cada cluster

1. Implante HelloWorld v1 em CLUSTER_1 e v2 em CLUSTER_2. Isso ajudará a verificar o balanceamento de carga entre clusters posteriormente:

   kubectl create --context=${CTX_1} \
     -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
     -l version=v1 -n sample

   kubectl create --context=${CTX_2} \
     -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
     -l version=v2 -n sample

2. Confirme se HelloWorld v1 e v2 estão em execução usando os seguintes comandos. Verifique se a saída é semelhante a esta:

   kubectl get pod --context=${CTX_1} -n sample

   NAME                            READY     STATUS    RESTARTS   AGE
   helloworld-v1-86f77cd7bd-cpxhv  2/2       Running   0          40s

   kubectl get pod --context=${CTX_2} -n sample

   NAME                            READY     STATUS    RESTARTS   AGE
   helloworld-v2-758dd55874-6x4t8  2/2       Running   0          40s

Implantar o serviço Sleep

1. Implante o serviço Sleep nos dois clusters. Esse pod gera tráfego de rede artificial para fins de demonstração:

   for CTX in ${CTX_1} ${CTX_2}
   do
       kubectl apply --context=${CTX} \
           -f ${SAMPLES_DIR}/samples/sleep/sleep.yaml -n sample
   done
   

2. Aguarde a inicialização do serviço Sleep em cada cluster. Verifique se a saída é semelhante a esta:

   kubectl get pod --context=${CTX_1} -n sample -l app=sleep

   NAME                             READY   STATUS    RESTARTS   AGE
   sleep-754684654f-n6bzf           2/2     Running   0          5s

   kubectl get pod --context=${CTX_2} -n sample -l app=sleep

   NAME                             READY   STATUS    RESTARTS   AGE
   sleep-754684654f-dzl9j           2/2     Running   0          5s

Verificar o balanceamento de carga entre clusters

Chame o serviço HelloWorld várias vezes e confira o resultado para verificar as respostas alternadas da v1 e da v2:

1. Chame o serviço HelloWorld:

   kubectl exec --context="${CTX_1}" -n sample -c sleep \
       "$(kubectl get pod --context="${CTX_1}" -n sample -l \
       app=sleep -o jsonpath='{.items[0].metadata.name}')" \
       -- /bin/sh -c 'for i in $(seq 1 20); do curl -sS helloworld.sample:5000/hello; done'
   

   A resposta será semelhante a esta:

   Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8
   Hello version: v1, instance: helloworld-v1-86f77cd7bd-cpxhv
   ...

2. Chame o serviço HelloWorld novamente:

   kubectl exec --context="${CTX_2}" -n sample -c sleep \
       "$(kubectl get pod --context="${CTX_2}" -n sample -l \
       app=sleep -o jsonpath='{.items[0].metadata.name}')" \
       -- /bin/sh -c 'for i in $(seq 1 20); do curl -sS helloworld.sample:5000/hello; done'
   

   A resposta será semelhante a esta:

   Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8
   Hello version: v1, instance: helloworld-v1-86f77cd7bd-cpxhv
   ...

Parabéns, você verificou seu balanceamento de carga com vários clusters do Cloud Service Mesh!

Limpar

Quando terminar de verificar o balanceamento de carga, remova os serviços HelloWorld e Sleep do seu cluster.

kubectl delete ns sample --context ${CTX_1}
kubectl delete ns sample --context ${CTX_2}