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

Este guia explica como configurar uma rede de vários clusters para as seguintes plataformas:

• Google Distributed Cloud
• Google Distributed Cloud
• GKE no Azure
• GKE no AWS
• Clusters associados, incluindo clusters do Amazon EKS e clusters do Microsoft AKS

Este guia mostra como configurar dois clusters, mas pode expandir este processo para incorporar qualquer número de clusters na sua malha.

Nota da plataforma: o comando asmcli create-mesh que usa para ativar a deteção de pontos finais requer que todos os clusters estejam na mesma plataforma. Atualmente, asmcli create-mesh só suporta a malha híbrida na pré-visualização.

Antes de começar

Este guia pressupõe que instalou o Cloud Service Mesh através do asmcli install. Precisa de asmcli e do pacote de configuração que asmcli transfere para o diretório que especificou em --output_dir quando executou asmcli install. Se precisar de configurar, siga os passos em Instale ferramentas dependentes e valide o cluster para:

• Instale as ferramentas necessárias
• Transferir asmcli
• Conceda autorizações de administrador do cluster
• Valide o seu projeto e cluster

Tem de ter acesso aos ficheiros kubeconfig de todos os clusters que está a configurar na malha.

Aviso: use apenas ficheiros kubeconfig de origens fidedignas. A utilização de um ficheiro kubeconfig especialmente criado pode resultar na execução de código malicioso ou na exposição de ficheiros. Se tiver de usar um ficheiro kubeconfig não fidedigno, inspecione-o cuidadosamente primeiro, tal como faria com um script de shell.

Configure variáveis de ambiente e marcadores de posição

Precisa das seguintes variáveis de ambiente quando instala o gateway leste-oeste.

1. Crie uma variável de ambiente para o número do projeto. No comando seguinte, substitua FLEET_PROJECT_ID pelo ID do projeto do projeto anfitrião 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 que o comando asmcli requer.

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

4. Obtenha 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 do cluster, que este guia usa em muitos passos mais tarde:

   export CTX_1=CLUSTER1_CONTEXT_NAME
   export CTX_2=CLUSTER2_CONTEXT_NAME
   

Instale o gateway de este a oeste

Nos seguintes comandos:

• Substitua CLUSTER_NAME_1 e CLUSTER_NAME_2 pelos nomes dos seus clusters.

• Substitua PATH_TO_KUBECONFIG_1 e PATH_TO_KUBECONFIG_2 pelos ficheiros kubeconfig dos seus clusters.

Clusters do Anthos

AC de malha ou serviço de AC

1. Instale uma entrada no cluster1 dedicada ao tráfego leste-oeste para $CLUSTER_2. Por predefinição, este gateway é público na Internet. Os sistemas de produção podem exigir restrições de acesso adicionais, por exemplo, regras de firewall, para evitar ataques externos.

   Nota: se instalou o Cloud Service Mesh com valores diferentes para --network_id, deve transmitir 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-1264-1 | \
       ./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-oeste para $CLUSTER_1.

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

AC do Istio

1. Instale uma entrada no cluster1 dedicada ao tráfego leste-oeste para $CLUSTER_2. Por predefinição, este gateway é público na Internet. Os sistemas de produção podem exigir restrições de acesso adicionais, por exemplo, regras de firewall, para evitar ataques externos.

   Nota: se instalou o Cloud Service Mesh com valores diferentes para --network_id, deve transmitir 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-1264-1 | \
       ./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-oeste para $CLUSTER_1.

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

Azure, AWS e anexado

Mesh CA

1. Instale uma entrada no cluster1 dedicada ao tráfego leste-oeste para $CLUSTER_2. Por predefinição, este gateway é público na Internet. Os sistemas de produção podem exigir restrições de acesso adicionais, por exemplo, regras de firewall, para evitar ataques externos.

   Nota: se instalou o Cloud Service Mesh com valores diferentes para --network_id, deve transmitir 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-1264-1 | \
       ./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-oeste para $CLUSTER_1.

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

AC do Istio

1. Instale uma entrada no cluster1 dedicada ao tráfego leste-oeste para $CLUSTER_2. Por predefinição, este gateway é público na Internet. Os sistemas de produção podem exigir restrições de acesso adicionais, por exemplo, regras de firewall, para evitar ataques externos.

   Nota: se instalou o Cloud Service Mesh com valores diferentes para --network_id, deve transmitir 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-1264-1 | \
       ./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-oeste para $CLUSTER_1.

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

Nota da plataforma: para o Google Distributed Cloud, não é atribuído um endereço IP externo até mais tarde, quando concluir os passos descritos no artigo Configure endereços IP externos para o Google Distributed Cloud.

Serviços de exposição

Uma vez que os clusters estão em redes separadas, tem de expor todos os serviços (*.local) no gateway leste-oeste em ambos os clusters. Embora este gateway seja público na Internet, só é possível aceder aos serviços que estão por detrás através de serviços com um certificado mTLS fidedigno e um ID da carga de trabalho, tal como se estivessem na mesma rede.

1. Exponha serviços através 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 serviços através 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
   

Ative a deteção de pontos finais

Nota: para mais informações sobre a deteção de pontos finais, consulte o artigo Deteção de pontos finais com vários planos de controlo.

Execute o comando asmcli create-mesh para ativar a descoberta de pontos finais. Este exemplo mostra apenas dois clusters, mas pode executar o comando para ativar a deteção de pontos finais em clusters adicionais, sujeito ao limite do serviço GKE Hub.

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

Valide a conetividade multicluster

Esta secção explica como implementar os serviços de exemplo HelloWorld e Sleep no seu ambiente de vários clusters para verificar se o equilíbrio de carga entre clusters funciona.

Nota: estes serviços de exemplo encontram-se no diretório Istio samples incluído no ficheiro tarball (localizado em istioctl) e não no diretório samples transferido pelo asmcli (localizado em OUTPUT_DIR/samples).

OUTPUT_DIR/istio-${ASM_VERSION%+*}/samples

Ative a injeção de sidecar

Localize o valor da etiqueta de revisão, que usa em passos posteriores.

Nota: se os seus clusters tiverem versões diferentes do Cloud Service Mesh, tem de executar o seguinte comando para cada cluster.

Use o comando seguinte para localizar a etiqueta de revisão, que vai usar nos passos posteriores.

kubectl -n istio-system get pods -l app=istiod --show-labels

O resultado tem um aspeto semelhante ao seguinte:

NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-asm-173-3-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-173-3,istio=istiod,pod-template-hash=5788d57586
istiod-asm-173-3-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-173-3,istio=istiod,pod-template-hash=5788d57586

Na saída, na coluna LABELS, repare no valor da etiqueta de revisão istiod, que segue o prefixo istio.io/rev=. Neste exemplo, o valor é asm-173-3. Use o valor da revisão nos passos da secção seguinte.

Instale o serviço HelloWorld

Nota: o exemplo do serviço HelloWorld usa o Docker Hub. Num cluster privado, o tempo de execução do contentor pode extrair imagens de contentores do Artifact Registry por predefinição. O tempo de execução do contentor não pode extrair imagens de qualquer outro registo de imagens de contentores na Internet. Pode transferir a imagem e enviá-la para o Artifact Registry ou usar o Cloud NAT para fornecer acesso à Internet de saída para determinados nós privados. Para mais informações, consulte os artigos Migre contentores externos e Crie um cluster privado.

1. Crie o namespace de exemplo e a definição de serviço em cada cluster. No comando seguinte, substitua REVISION pela istiod etiqueta de revisão que anotou no passo anterior.

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

   onde REVISION é a etiqueta de revisão istiod que anotou anteriormente.

   O resultado é:

   label "istio-injection" not found.
   namespace/sample labeled
   

   Pode ignorar com segurança label "istio-injection" not found.

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

Implemente o HelloWorld v1 e v2 em cada cluster

1. Implemente HelloWorld v1 em CLUSTER_1 e v2 em CLUSTER_2, o que ajuda mais tarde a validar o balanceamento de carga entre clusters:

   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 o HelloWorld v1 e o v2 estão a ser executados através dos seguintes comandos. Verifique se o resultado é semelhante ao apresentado:

   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

Implemente o serviço de sono

1. Implemente o serviço Sleep em ambos os clusters. Este 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 que o serviço Sleep seja iniciado em cada cluster. Verifique se o resultado é semelhante ao apresentado:

   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

Valide o balanceamento de carga entre clusters

Chame o serviço HelloWorld várias vezes e verifique o resultado para validar respostas alternadas da v1 e v2:

1. Ligue para 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'
   

   O resultado é semelhante ao apresentado:

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

2. Ligue novamente para o serviço HelloWorld:

   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'
   

   O resultado é semelhante ao apresentado:

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

Parabéns, validou a sua malha de serviços na nuvem com vários clusters e equilíbrio de carga!

Limpar

Quando terminar a validação do equilíbrio de carga, remova o serviço HelloWorld e Sleep do cluster.

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