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

Este guia explica como configurar uma malha multicluster para as seguintes plataformas:

• Nuvem distribuída do Google
• Nuvem distribuída do Google
• GKE no Azure
• GKE na AWS
• Clusters anexados, incluindo clusters do Amazon EKS e clusters do Microsoft AKS

Este guia mostra como configurar dois clusters, mas você pode estender esse processo para incorporar qualquer número de clusters em sua malha.

Nota sobre a plataforma: O comando asmcli create-mesh usado para ativar a descoberta de endpoint requer que todos os clusters estejam na mesma plataforma. Atualmente, asmcli create-mesh suporta apenas malha híbrida na visualização.

Antes de começar

Este guia pressupõe que você instalou o Cloud Service Mesh usando asmcli install . Você precisa asmcli e do pacote de configuração que asmcli baixa no diretório especificado em --output_dir quando executou asmcli install . Se for necessário configurar, siga as etapas em Instalar ferramentas dependentes e validar o cluster para:

• Instale as ferramentas necessárias
• Baixar asmcli
• Conceder permissões de administrador de cluster
• Valide seu projeto e cluster

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

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

Configurar variáveis ​​de ambiente e espaços reservados

Você precisa das variáveis ​​de ambiente a seguir 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 de malha.

   export MESH_ID="proj-${PROJECT_NUMBER}"
   

3. Crie variáveis ​​de ambiente para os nomes de cluster no formato exigido asmcli .

   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 de contexto dos 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 usará em muitas etapas posteriormente:

   export CTX_1=CLUSTER1_CONTEXT_NAME
   export CTX_2=CLUSTER2_CONTEXT_NAME
   

Instale o gateway leste-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 arquivos kubeconfig para seus clusters.

Clusters do Anthos

Mesh CA ou serviço CA

1. Instale um gateway no cluster1 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 restrições de acesso adicionais, por exemplo, regras de firewall, para evitar ataques externos.

   Nota: Se você instalou o Cloud Service Mesh usando valores diferentes para --network_id , deverá passar os mesmos valores para gen-eastwest-gateway.sh com a sinalização --network .

   asm/istio/expansion/gen-eastwest-gateway.sh \
       --mesh ${MESH_ID}  \
       --cluster ${CLUSTER_1}  \
       --network default \
       --revision  | \
       ./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  | \
       ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 \
       install -y --set spec.values.global.pilotCertProvider=kubernetes -f -
   

Istio CA

1. Instale um gateway no cluster1 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 restrições de acesso adicionais, por exemplo, regras de firewall, para evitar ataques externos.

   Nota: Se você instalou o Cloud Service Mesh usando valores diferentes para --network_id , deverá passar os mesmos valores para gen-eastwest-gateway.sh com a sinalização --network .

   asm/istio/expansion/gen-eastwest-gateway.sh \
       --mesh ${MESH_ID}  \
       --cluster ${CLUSTER_1}  \
       --network default \
       --revision  | \
       ./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  | \
       ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 \
       install -y --set spec.values.global.pilotCertProvider=istiod -f -
   

Azure, AWS e anexado

CA de malha

1. Instale um gateway no cluster1 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 restrições de acesso adicionais, por exemplo, regras de firewall, para evitar ataques externos.

   Nota: Se você instalou o Cloud Service Mesh usando valores diferentes para --network_id , deverá passar os mesmos valores para gen-eastwest-gateway.sh com a sinalização --network .

   asm/istio/expansion/gen-eastwest-gateway.sh \
       --mesh ${MESH_ID}  \
       --cluster ${CLUSTER_1}  \
       --network default \
       --revision  | \
       ./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  | \
       ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 \
       install -y --set spec.values.global.pilotCertProvider=istiod -f -
   

Istio CA

1. Instale um gateway no cluster1 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 restrições de acesso adicionais, por exemplo, regras de firewall, para evitar ataques externos.

   Nota: Se você instalou o Cloud Service Mesh usando valores diferentes para --network_id , deverá passar os mesmos valores para gen-eastwest-gateway.sh com a sinalização --network .

   asm/istio/expansion/gen-eastwest-gateway.sh \
       --mesh ${MESH_ID}  \
       --cluster ${CLUSTER_1}  \
       --network default \
       --revision  | \
       ./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  | \
       ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 \
       install -y --set spec.values.global.pilotCertProvider=istiod -f -
   

Observação da plataforma: para o Google Distributed Cloud, um endereço IP externo só será atribuído mais tarde, quando você concluir as etapas descritas em Configurar endereços IP externos para o Google Distributed Cloud .

Expondo 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 esse gateway seja público na Internet, os serviços por trás dele só podem 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 serviços por meio do gateway leste-oeste para CLUSTER_NAME_1 .

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

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

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

Habilitar descoberta de endpoint

Observação: para obter mais informações sobre descoberta de endpoint, consulte Descoberta de endpoint com vários planos de controle .

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

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

Verifique a conectividade multicluster

Esta seção explica como implantar os serviços HelloWorld e Sleep de amostra em seu ambiente de vários clusters para verificar se o balanceamento de carga entre clusters 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 baixado por asmcli (localizado em OUTPUT_DIR /samples ).

Habilitar injeção lateral

Localize o valor do rótulo de revisão, que você usará nas etapas posteriores.

Nota: Se cada um dos seus clusters tiver versões diferentes do Cloud Service Mesh, você deverá executar o comando a seguir para cada cluster.

Use o comando a seguir para localizar o rótulo de revisão, que você usará em etapas posteriores.

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

A saída é semelhante a esta:

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 de revisão nas etapas da próxima seção.

Instale o serviço HelloWorld

Nota: O exemplo do serviço HelloWorld usa Docker Hub . Em um cluster privado, o tempo de execução do contêiner pode extrair imagens de contêiner do Artifact Registry por padrão. O tempo de execução do contêiner não pode extrair imagens de nenhum outro registro de imagem de contêiner na Internet. Você pode baixar a imagem e enviá-la para o Artifact Registry ou usar o Cloud NAT para fornecer acesso de saída à Internet para determinados nós privados. Para obter mais informações, consulte Migrar contêineres externos e Criar um cluster privado .

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
   

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

   A saída é:

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

   Você 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
   

Implante HelloWorld v1 e v2 em cada cluster

1. Implante HelloWorld v1 em CLUSTER_1 e v2 em CLUSTER_2 , o que ajuda posteriormente a verificar 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 que HelloWorld v1 e v2 estão em execução usando os comandos a seguir. Verifique se a saída é semelhante à mostrada.:

   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 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 o início do serviço Sleep em cada cluster. Verifique se a saída é semelhante à mostrada:

   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

Verifique o balanceamento de carga entre clusters

Chame o serviço HelloWorld várias vezes e verifique a saída para verificar respostas alternadas de 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'
   

   A saída é semelhante à mostrada:

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

2. Ligue para 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 saída é semelhante à mostrada:

   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

Ao concluir a verificação do balanceamento 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}