Você está vendo a documentação do Anthos Service Mesh 1.8. Veja uma mais recente ou selecione outra versão disponível:

Configuração de GKE de vários clusters no Anthos Service Mesh

Neste guia, explicamos como mesclar dois clusters em um único Anthos Service Mesh usando a Mesh CA ou o Citadel, além de ativar o balanceamento de carga entre clusters. É possível ampliar facilmente esse processo para incorporar qualquer quantidade de clusters na malha.

Uma configuração do Anthos Service Mesh de vários clusters pode resolver várias situações corporativas cruciais, como escala, local e isolamento. Para mais informações, consulte Casos de uso de vários clusters. Além disso, otimize seus aplicativos para aproveitar ao máximo uma malha de serviço. Para mais informações, consulte Como preparar um aplicativo para o Anthos Service Mesh.

Pré-requisitos

Para este guia, presumimos que você tenha dois ou mais clusters do Google Cloud GKE que atendam aos seguintes requisitos:

  • Anthos Service Mesh versão 1.6.8 ou posterior instalado nos clusters.
  • Se você mesclar clusters que não estão no mesmo projeto, eles precisarão ser instalados usando o perfil asm-gcp-multiproject e estar em uma configuração de VPC compartilhada, juntos na mesma rede. Além disso, recomendamos que você tenha um projeto para hospedar a VPC compartilhada e dois projetos de serviço para a criação de clusters. Para mais informações, consulte Como configurar clusters com a VPC compartilhada.
  • Se você usar a Citadel CA, aplique a mesma CA raiz personalizada para os dois clusters.
  • Se o Anthos Service Mesh for construído em clusters particulares, recomendamos criar uma única sub-rede na mesma VPC. Caso contrário, você precisará garantir que:
    1. Os planos de controle podem ser acessados pelos planos de controle remotos do cluster por meio dos IPs particulares do cluster.
    2. É possível adicionar os intervalos de IP dos planos de controle de chamadas às redes autorizadas dos clusters particulares remotos. Para mais informações, consulte Configurar a descoberta de endpoints entre clusters particulares.

Como definir variáveis de projeto e de cluster

  1. Para facilitar, defina uma pasta de trabalho. Ela deve ser aquela em que você fez o download e extraiu os arquivos do Anthos Service Mesh na etapa de pré-requisito Preparação para instalar o Anthos Service Mesh.

    export PROJECT_DIR=YOUR_WORKING_FOLDER
  2. Crie uma variável de contexto para cada cluster. O contexto é uma string criada a partir dos IDs de projeto, nomes e locais de clusters. Para os valores de local, use a localização do cluster, por exemplo, us-west2-a. Neste exemplo, uma malha já contém um cluster, e você está adicionando outro:

    export CTX_1=gke_CLUSTER_1_PROJECT_ID_CLUSTER_1_LOCATION_CLUSTER_1_NAME
    export CTX_2=gke_CLUSTER_2_PROJECT_ID_CLUSTER_2_LOCATION_CLUSTER_2_NAME

Configurar a descoberta de endpoints entre clusters

.

Configure a descoberta de endpoints para balanceamento de carga entre clusters usando os comandos a seguir. Essa etapa executa as seguintes tarefas:

  • O comando istioctl cria um secret que concede acesso ao servidor da API Kube para um cluster.
  • O comando kubectl aplica o secret a outro cluster. Assim, o segundo pode ler os endpoints de serviço do primeiro.
istioctl x create-remote-secret --context=${CTX_1} --name=${CLUSTER_1_NAME} | \
  kubectl apply -f - --context=${CTX_2}
istioctl x create-remote-secret --context=${CTX_2} --name=${CLUSTER_2_NAME} | \
  kubectl apply -f - --context=${CTX_1}

Configurar a descoberta de endpoints entre clusters particulares

Ao usar clusters particulares, você precisa configurar os IPs particulares dos clusters remotos em vez dos IPs públicos, porque os IPs públicos não são acessíveis.

  1. Grave os secrets com IPs públicos em arquivos temporários:

    istioctl x create-remote-secret --context=${CTX_1} --name=${CLUSTER_1_NAME} > ${CTX_1}.secret
    
    istioctl x create-remote-secret --context=${CTX_2} --name=${CLUSTER_2_NAME} > ${CTX_2}.secret
    
  2. Recupere os IPs particulares dos clusters particulares e substitua os IPs públicos pelos IPs nos secrets dos arquivos temporários.

    IFS="_" read -r -a VALS <<< ${CTX_1}
    PROJECT_1=${VALS[1]}
    LOCATION_1=${VALS[2]}
    CLUSTER_1=${VALS[3]}
    PRIV_IP=`gcloud container clusters describe "${CLUSTER_1}" --project "${PROJECT_1}" \
        --zone "${LOCATION_1}" --format "value(privateClusterConfig.privateEndpoint)"`
    sed -i 's/server\:.*/server\: https:\/\/'"${PRIV_IP}"'/' ${CTX_1}.secret
    
    IFS="_" read -r -a VALS <<< ${CTX_2}
    PROJECT_2=${VALS[1]}
    LOCATION_2=${VALS[2]}
    CLUSTER_2=${VALS[3]}
    PRIV_IP=`gcloud container clusters describe "${CLUSTER_2}" --project "${PROJECT_2}" \
        --zone "${LOCATION_2}" --format "value(privateClusterConfig.privateEndpoint)"`
    sed -i 's/server\:.*/server\: https:\/\/'"${PRIV_IP}"'/' ${CTX_2}.secret
    
  3. Aplique os novos secrets aos clusters:

    kubectl apply -f ${CTX_1}.secret --context=${CTX_2}
    
    kubectl apply -f ${CTX_2}.secret --context=${CTX_1}
    

Como configurar redes autorizadas para clusters particulares

Siga esta seção somente se todas as condições a seguir se aplicarem à sua malha:

Ao implantar vários clusters no Anthos Service Mesh, o Istio em cada cluster precisa chamar o plano de controle do GKE dos clusters remotos. Para permitir o tráfego, você precisa adicionar o intervalo de endereços do pod no cluster de chamada para as redes autorizadas dos clusters remotos.

  1. Consiga o bloco de CIDR de IP de pod para cada cluster:

    POD_IP_CIDR_1=`gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
      --format "value(ipAllocationPolicy.clusterIpv4CidrBlock)"`
    
    POD_IP_CIDR_2=`gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
      --format "value(ipAllocationPolicy.clusterIpv4CidrBlock)"`
    
  2. Adicione os blocos CIDR de IP do pod do cluster do Kubernetes aos clusters remotos:

    EXISTING_CIDR_1=`gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
     --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"`
    gcloud container clusters update ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
    --enable-master-authorized-networks \
    --master-authorized-networks ${POD_IP_CIDR_2},${EXISTING_CIDR_1//;/,}
    
    EXISTING_CIDR_2=`gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
     --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"`
    gcloud container clusters update ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
    --enable-master-authorized-networks \
    --master-authorized-networks ${POD_IP_CIDR_1},${EXISTING_CIDR_2//;/,}
    

    Para mais informações, consulte Como criar um cluster com redes autorizadas.

  3. Verifique se as redes autorizadas estão atualizadas:

    gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
     --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"
    
    gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
     --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"
    

Ativar o acesso global ao plano de controle

Siga esta seção somente se todas as condições a seguir se aplicarem à sua malha:

  • Você está usando clusters particulares.
  • Você usa regiões diferentes para os clusters na malha.

É preciso ativar o acesso global ao plano de controle para permitir que o istiod em cada cluster chame o plano de controle do GKE dos clusters remotos.

  1. Ativar o acesso global ao plano de controle:

    gcloud container clusters update ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
     --enable-master-global-access
    
    gcloud container clusters update ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
     --enable-master-global-access
    
  2. Verifique se o acesso global ao plano de controle está ativado:

    gcloud container clusters describe ${CLUSTER_1} --zone ${LOCATION_1}
    
    gcloud container clusters describe ${CLUSTER_2} --zone ${LOCATION_2}
    

    A seção privateClusterConfig na saída exibe o status de masterGlobalAccessConfig.

Como abrir portas para tráfego entre sub-redes

Siga esta seção somente se todas as condições a seguir se aplicarem à sua malha:

  • Você usa sub-redes diferentes para os clusters na malha.
  • Os pods abrem portas diferentes de 443 e 15002.

O GKE adiciona automaticamente regras de firewall a cada nó para permitir o tráfego dentro da mesma sub-rede. Se a malha contiver várias sub-redes, será necessário configurar explicitamente as regras de firewall para permitir o tráfego entre as sub-redes. Você precisa adicionar uma nova regra de firewall para cada sub-rede para permitir os bloqueios de CIDR de IP de origem e segmentar as portas de todo o tráfego de entrada.

Crie as regras de firewall:

TARGET_TAG_1=`gcloud compute firewall-rules list --filter="name~gke-${CLUSTER_1}-[0-9a-z]*-master" --format 'value(targetTags)'`
NEW_FIREWALL_NAME_1=new_firewall_name_1

gcloud compute firewall-rules create ${NEW_FIREWALL_NAME_1} \
    --action ALLOW \
    --direction INGRESS \
    --source-ranges ${POD_IP_CIDR_2} \
    --rules protocol:port[,protocol,port] \
    --target-tags ${TARGET_TAG_1}
TARGET_TAG_2=`gcloud compute firewall-rules list --filter="name~gke-${CLUSTER_2}-[0-9a-z]*-master" --format "value(targetTags)"`
NEW_FIREWALL_NAME_2=new_firewall_name_2
gcloud compute firewall-rules create ${NEW_FIREWALL_NAME_2} \
    --action ALLOW \
    --direction INGRESS \
    --source-ranges ${POD_IP_CIDR_1} \
    --rules protocol:port[,protocol,port] \
    --target-tags ${TARGET_TAG_2}

onde:

  • protocol:port é a porta desejada e o protocolo dela, tcp ou udp.

Verificar sua implantação

Nesta seção, explicamos como implantar um serviço HelloWorld de amostra no seu ambiente de vários clusters para verificar se o balanceamento de carga entre eles funciona.

Ative a injeção de sidecar

  1. Use o comando a seguir para localizar o valor do rótulo de revisão no serviço istiod, que será usado em etapas posteriores.

    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

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 saída é:

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

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

  1. Crie o serviço HelloWorld em ambos os clusters:

    kubectl create --context=${CTX_1} \
        -f ${PROJECT_DIR}/samples/helloworld/helloworld.yaml \
        -l service=helloworld -n sample
    
    kubectl create --context=${CTX_2} \
        -f ${PROJECT_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 ${PROJECT_DIR}/samples/helloworld/helloworld.yaml \
      -l version=v1 -n sample
    kubectl create --context=${CTX_2} \
      -f ${PROJECT_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 ${PROJECT_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}')" \
        -- curl -sS helloworld.sample:5000/hello
    

    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}')" \
        -- curl -sS helloworld.sample:5000/hello
    

    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 o serviço HelloWorld

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}