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 oferece suporte às APIs do 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
• GKE na AWS
• Clusters anexados, incluindo clusters do Amazon EKS e clusters do Microsoft AKS

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, presume-se que você tenha instalado o Cloud Service Mesh 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 Anthos

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-1226-2 | \
       ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_1 \
       install -y --set spec.values.global.pilotCertProvider=kubernetes -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-1226-2 | \
       ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 \
       install -y --set spec.values.global.pilotCertProvider=kubernetes -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-1226-2 | \
       ./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-1226-2 | \
       ./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) no 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) no VMware.

Azure, AWS e anexo

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-1226-2 | \
       ./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-1226-2 | \
       ./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-1226-2 | \
       ./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-1226-2 | \
       ./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 (em inglês) 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 tem suporte: Siga estas 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}