Configure uma malha híbrida ou multicloud

Pré-visualização — Hybrid and multi-cloud mesh

Esta funcionalidade está sujeita aos "Termos das Ofertas de Pré-DG" na secção Termos Gerais de Serviço dos Termos Específicos do Serviço. As funcionalidades de pré-DG estão disponíveis "tal como estão" e podem ter apoio técnico limitado. Para mais informações, consulte as descrições das fases de lançamento.

Esta página explica como configurar uma malha híbrida ou de várias nuvens para as seguintes plataformas:

• Híbrido: GKE no Google Cloud e Google Distributed Cloud (pré-visualização)
• Híbrido: GKE no Google Cloud e Google Distributed Cloud (pré-visualização)
• Multinuvem: GKE no Google Cloud e Amazon EKS (pré-visualização)

Aviso: contacte o apoio técnico antes de configurar uma malha de várias nuvens.

Nota da plataforma: o comando asmcli create-mesh que usa para ativar a deteção de pontos finais requer que todos os clusters na malha sejam uma das combinações de plataformas multinuvem/híbridas na lista anterior. Outras combinações de malhas híbridas ou de várias nuvens noutras plataformas não são suportadas. O Managed Cloud Service Mesh não é suportado em malhas híbridas ou multicloud.

Seguindo estas instruções, configura dois clusters, mas pode expandir este processo para incorporar qualquer número de clusters na sua malha.

Pré-requisitos

• Todos os clusters têm de estar registados no mesmo projeto anfitrião da frota.
• Todos os clusters do GKE têm de estar numa configuração de VPC partilhada na mesma rede.
• O endereço do painel de controlo do Kubernetes do cluster e o endereço do gateway têm de estar acessíveis a partir de todos os clusters na malha. O Google Cloud projeto no qual os clusters do GKE estão localizados deve ter autorização para criar tipos de balanceamento de carga externos. Recomendamos que use redes autorizadas e regras da firewall da VPC para restringir o acesso.
• Os clusters privados, incluindo os clusters privados do GKE, não são suportados. Se usar clusters no local, incluindo o Google Distributed Cloud e o Google Distributed Cloud, o endereço do plano de controlo do Kubernetes e o endereço do gateway têm de estar acessíveis a partir de pods em clusters do GKE. Recomendamos que use o CloudVPN para associar a sub-rede do cluster do GKE à rede do cluster no local.
• Se usar a AC do Istio, use o mesmo certificado de raiz personalizado para todos os clusters.

Antes de começar

Este guia pressupõe que instalou o Cloud Service Mesh através da ferramenta asmcli. Precisa do ficheiro asmcli e do pacote de configuração que asmcli transfere para o diretório que especificou em --output_dir quando executou asmcli install. Para mais informações, consulte o artigo Instale ferramentas dependentes e valide o cluster para:

• Instale as ferramentas necessárias
• Transfira o 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. Para o cluster do GKE, para criar um novo ficheiro kubeconfig para o cluster, pode exportar KUBECONFIG env com o caminho completo do ficheiro como valor no terminal e gerar a entrada kubeconfig.

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.

Crie variáveis de ambiente para os nomes das redes:

• Os clusters do GKE usam o nome da rede do cluster por predefinição:

  export NETWORK_1="PROJECT_ID-CLUSTER_NETWORK"
  ``````
  

• Outros clusters usam default:

  export NETWORK_2="default"
  ``````
  

Se instalou o Cloud Service Mesh noutros clusters com valores diferentes para --network_id, deve transmitir os mesmos valores para NETWORK_2.

Instale o gateway de este a oeste

1. Instale um gateway no CLUSTER_1 (o seu cluster do GKE) dedicado ao tráfego leste-oeste para o CLUSTER_2 (o seu cluster multinuvem ou no local):

   asm/istio/expansion/gen-eastwest-gateway.sh \
       --mesh ${MESH_ID} \
       --network ${NETWORK_1}  \
       --revision asm-11910-9 | \
       ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_1 install -y -f -
   

   Tenha em atenção que este gateway é público na Internet por predefinição. Os sistemas de produção podem exigir restrições de acesso adicionais, por exemplo, regras de firewall, para evitar ataques externos.

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} \
       --network ${NETWORK_2} \
       --revision asm-11910-9 | \
       ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 install -y -f -
   

Exponha serviços

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.

Exponha serviços através do gateway leste-oeste para cada cluster

    kubectl --kubeconfig=PATH_TO_KUBECONFIG_1 apply -n istio-system -f \
        asm/istio/expansion/expose-services.yaml
    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

Nota da plataforma: estes passos só se aplicam se estiver a usar um plano de controlo no cluster. Para a malha de serviços na nuvem gerida, consulte os artigos Injetar proxies sidecar ou Aplicar o plano de dados gerido.

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 istioctl tar (localizado em OUTPUT_DIR/istio-${ASM_VERSION%+*}/samples) e não no diretório samples transferido pelo asmcli (localizado em OUTPUT_DIR/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}