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

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 GKE no VMware (pré-lançamento)
  • Híbrido: GKE no Google Cloud e GKE em Bare Metal (pré-lançamento)
  • Várias nuvens: GKE no Google Cloud e Amazon EKS (visualização)

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 GKE no VMware e o GKE em Bare Metal, o endereço do plano de controle do Kubernetes e o endereço do gateway precisam ser acessíveis por 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

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

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.

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 Anthos Service Mesh em outros clusters com valores diferentes para --network_id, transmita os mesmos valores para o valor para NETWORK_2.

Instalar o gateway leste-oeste

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

    asm/istio/expansion/gen-eastwest-gateway.sh \
        --network ${NETWORK_1}  \
        --revision asm-1233-2 | \
        ./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-1233-2 | \
        ./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

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.

Ative a injeção de sidecar

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

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

  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 balanceamento de carga com vários clusters do Anthos 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}