Configurar uma malha híbrida ou de várias nuvens

Visualização — Hybrid and multi-cloud mesh

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Nesta página, explicamos 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é-lançamento)
• Híbrido: GKE no Google Cloud e Google Distributed Cloud (pré-lançamento)
• Várias nuvens: GKE no Google Cloud e Amazon EKS (visualização)

Aviso: entre em contato com o suporte antes de configurar uma malha de várias nuvens.

Observação sobre a plataforma: o comando asmcli create-mesh usado para ativar a descoberta de endpoints exige que todos os clusters na malha sejam uma das combinações de plataformas de várias nuvens/híbridas na lista anterior. Outras combinações de malhas de várias nuvens ou híbridas em outras plataformas não são compatíveis. O Cloud Service Mesh gerenciado não é compatível com malhas de várias nuvens ou híbridas.

Ao seguir estas instruções, você configurará dois clusters, mas poderá estender esse processo para incorporar qualquer quantidade de clusters em sua malha.

Pré-requisitos

• Todos os clusters precisam ser registrados no mesmo projeto host da frota.
• Todos os clusters do GKE precisam estar em uma configuração de VPC compartilhada na mesma rede.
• O endereço do plano de controle do Kubernetes e o endereço do gateway do cluster precisam estar acessíveis em todos os clusters da malha. O projeto do Google Cloud em que os clusters do GKE estão localizados precisa ter permissão para criar tipos de balanceamento de carga externos. Recomendamos que você use redes autorizadas e regras de firewall da VPC para restringir o acesso.
• Clusters particulares, incluindo clusters privados do GKE, não são compatíveis. Se você usa clusters no local, incluindo o Google Distributed Cloud, o endereço do plano de controle do Kubernetes e o endereço do gateway precisam ser acessíveis de pods em clusters do GKE. Recomendamos que você use o CloudVPN para conectar a sub-rede do cluster do GKE à rede do cluster no local.
• Se você usar a CA do Istio, utilize o mesmo certificado raiz personalizado para todos os clusters.

Antes de começar

Este guia pressupõe que você instalou o Cloud Service Mesh usando a ferramenta asmcli. 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. Para mais informações, consulte Instalar ferramentas dependentes e validar o cluster para:

• Instale as ferramentas necessárias
• Fazer o download do 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. Para criar um novo arquivo kubeconfig no cluster do GKE, é possível exportar o ambiente KUBECONFIG com o caminho completo do arquivo como valor no terminal e gerar a entrada kubeconfig.

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.

Crie variáveis de ambiente para os nomes de rede:

• O padrão dos clusters do GKE é o nome da rede do cluster:

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

• Outros clusters usam default:

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

Se você instalou o Cloud Service Mesh em outros clusters com valores diferentes para --network_id, transmita os mesmos valores para NETWORK_2.

Instalar o gateway leste-oeste

1. Instale um gateway em CLUSTER_1 (seu cluster do GKE) que seja dedicada a leste-oeste tráfego para CLUSTER_2 (seu cluster de várias nuvens ou no local):

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

   Observe que esse gateway é público na Internet por padrão. Os sistemas de produção podem exigir outras restrições de acesso, como regras de firewall, para evitar ataques externos.

2. Instale um gateway em CLUSTER_2 que seja dedicado ao tráfego leste-oeste para CLUSTER_1.

   asm/istio/expansion/gen-eastwest-gateway.sh \
       --network ${NETWORK_2} \
       --revision asm-1187-26 | \
       ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 install -y -f -
   

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.

Expor serviços pelo 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

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

Observação da plataforma: estas etapas se aplicarão somente se você estiver usando um plano de controle no cluster. Para o Cloud Service Mesh gerenciado, consulte Como injetar proxies sidecar ou Aplicar o plano de dados gerenciado.

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 exemplo estão localizados na Diretório samples do Istio incluído no tarball istioctl (localizado em OUTPUT_DIR/istio-${ASM_VERSION%+*}/samples) e não o Diretório samples baixado por asmcli (localizado em OUTPUT_DIR/samples).

Ative a injeção de sidecar

Localize o valor do rótulo de revisão, que você vai usar em etapas futuras.

Observação: se os clusters tiverem versões diferentes do Cloud Service Mesh, você precisará execute o comando a seguir para cada cluster.

Use o comando a seguir para localizar o identificador de revisão, que vai ser usado em etapas futuras.

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

A resposta será semelhante a:

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, observe o valor do rótulo de revisão istiod, que segue o prefixo istio.io/rev=. Neste exemplo, o valor é asm-173-3. Use o valor da revisão nas etapas da próxima seção.

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.

1. Crie o namespace de amostra e a definição de serviço em cada cluster. No comando a seguir, substitua REVISION pelo rótulo de revisão istiod que você anotou na etapa 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
   

   em que REVISION é o rótulo de revisão istiod que você anotou anteriormente.

   A resposta é:

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

   Você pode ignorar label "istio-injection" not found. com segurança

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
   

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 Cloud Service Mesh com balanceamento de carga e vários clusters.

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}