Configurar uma malha de vários clusters no GKE
Neste guia, explicamos como mesclar dois clusters em um único Cloud Service Mesh usando a CA da Mesh ou a CA do Istio, 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 Cloud Service Mesh com vários clusters pode resolver vários problemas vários cenários, como escala, localização e isolamento. Para mais informações, consulte Casos de uso de vários clusters.
Pré-requisitos
Para este guia, presumimos que você tenha dois ou mais clusters do Google Cloud GKE que atendam aos seguintes requisitos:
Cloud Service Mesh versão 1.11 ou posterior instalado nos clusters usando
asmcli install
. Você precisa deasmcli
, da ferramentaistioctl
e de amostras queasmcli
faz download para o diretório especificado em--output_dir
quando você executouasmcli install
Se precisar ser configurado, siga as etapas em Instalar ferramentas dependentes e validar o cluster para:Os clusters na malha precisam ter conectividade entre todos os pods antes de configurar o Cloud Service Mesh. Além disso, você mesclar clusters que não estejam no mesmo projeto, eles vão precisar ser registrados no mesmo projeto host da frota, e será preciso que os clusters estejam em uma configuração do projeto de VPC compartilhada na mesma rede. Também recomendamos que você tenha um projeto para hospedar a VPC compartilhada e dois projetos de serviço para criar clusters. Para mais informações, consulte Como configurar clusters com a VPC compartilhada.
Se você usar a CA do Istio, utilize o mesmo certificado raiz personalizado para os dois clusters.
Se o Cloud Service Mesh foi criado em clusters particulares, recomendamos criar uma única sub-rede na mesma VPC. Caso contrário, é preciso garantir que:
- Os planos de controle podem ser acessados pelos planos de controle remotos do cluster por meio dos IPs particulares do cluster.
- É 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.
O servidor de API precisa ser acessível pelas outras instâncias do plano de controle do Cloud Service Mesh na malha de vários clusters.
- Verifique se os clusters estão com o acesso global ativado.
- Verifique se o IP do plano de controle do Cloud Service Mesh foi permitido corretamente usando a lista de permissões com a Rede autorizada mestre.
Como definir variáveis de projeto e de cluster
Crie as seguintes variáveis de ambiente para o ID do projeto, a zona ou região do cluster, o nome do cluster e o contexto.
export PROJECT_1=PROJECT_ID_1 export LOCATION_1=CLUSTER_LOCATION_1 export CLUSTER_1=CLUSTER_NAME_1 export CTX_1="gke_${PROJECT_1}_${LOCATION_1}_${CLUSTER_1}" export PROJECT_2=PROJECT_ID_2 export LOCATION_2=CLUSTER_LOCATION_2 export CLUSTER_2=CLUSTER_NAME_2 export CTX_2="gke_${PROJECT_2}_${LOCATION_2}_${CLUSTER_2}"
Se esses forem clusters recém-criados, busque credenciais para cada cluster com os seguintes comandos
gcloud
. Caso contrário, ocontext
associado não estará disponível para uso nas próximas etapas deste guia.Os comandos dependem do tipo de cluster, por região ou por zona:
Regional
gcloud container clusters get-credentials ${CLUSTER_1} --region ${LOCATION_1} gcloud container clusters get-credentials ${CLUSTER_2} --region ${LOCATION_2}
Zonal
gcloud container clusters get-credentials ${CLUSTER_1} --zone ${LOCATION_1} gcloud container clusters get-credentials ${CLUSTER_2} --zone ${LOCATION_2}
Criar regra de firewall
Em alguns casos, você precisa criar uma regra de firewall para permitir o tráfego entre clusters. Por exemplo, você precisa criar uma regra de firewall se:
- 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.
As instruções a seguir permitem a comunicação entre todos os clusters no projeto ou apenas entre $CLUSTER_1
e $CLUSTER_2
.
Reúna informações sobre a rede dos clusters.
Todos os clusters de projeto
Se os clusters estiverem no mesmo projeto, use o seguinte comando para permitir a comunicação entre todos os clusters no projeto. Se você não quiser expor alguns clusters no seu projeto, use o comando na guia Clusters específicos.
function join_by { local IFS="$1"; shift; echo "$*"; } ALL_CLUSTER_CIDRS=$(gcloud container clusters list --project $PROJECT_1 --format='value(clusterIpv4Cidr)' | sort | uniq) ALL_CLUSTER_CIDRS=$(join_by , $(echo "${ALL_CLUSTER_CIDRS}")) ALL_CLUSTER_NETTAGS=$(gcloud compute instances list --project $PROJECT_1 --format='value(tags.items.[0])' | sort | uniq) ALL_CLUSTER_NETTAGS=$(join_by , $(echo "${ALL_CLUSTER_NETTAGS}"))
Clusters específicos
O comando a seguir permite a comunicação entre
$CLUSTER_1
e$CLUSTER_2
e não expõe outros clusters no projeto.function join_by { local IFS="$1"; shift; echo "$*"; } ALL_CLUSTER_CIDRS=$(for P in $PROJECT_1 $PROJECT_2; do gcloud --project $P container clusters list --filter="name:($CLUSTER_1,$CLUSTER_2)" --format='value(clusterIpv4Cidr)'; done | sort | uniq) ALL_CLUSTER_CIDRS=$(join_by , $(echo "${ALL_CLUSTER_CIDRS}")) ALL_CLUSTER_NETTAGS=$(for P in $PROJECT_1 $PROJECT_2; do gcloud --project $P compute instances list --filter="name:($CLUSTER_1,$CLUSTER_2)" --format='value(tags.items.[0])' ; done | sort | uniq) ALL_CLUSTER_NETTAGS=$(join_by , $(echo "${ALL_CLUSTER_NETTAGS}"))
Crie a regra de firewall.
GKE
gcloud compute firewall-rules create istio-multicluster-pods \ --allow=tcp,udp,icmp,esp,ah,sctp \ --direction=INGRESS \ --priority=900 \ --source-ranges="${ALL_CLUSTER_CIDRS}" \ --target-tags="${ALL_CLUSTER_NETTAGS}" --quiet \ --network=YOUR_NETWORK
Piloto automático
TAGS="" for CLUSTER in ${CLUSTER_1} ${CLUSTER_2} do TAGS+=$(gcloud compute firewall-rules list --filter="Name:$CLUSTER*" --format="value(targetTags)" | uniq) && TAGS+="," done TAGS=${TAGS::-1} echo "Network tags for pod ranges are $TAGS" gcloud compute firewall-rules create asm-multicluster-pods \ --allow=tcp,udp,icmp,esp,ah,sctp \ --network=gke-cluster-vpc \ --direction=INGRESS \ --priority=900 --network=VPC_NAME \ --source-ranges="${ALL_CLUSTER_CIDRS}" \ --target-tags=$TAGS
Configurar a descoberta de endpoints
As etapas necessárias para configurar a descoberta de endpoints dependem da sua preferência para usar a API declarativa entre clusters em uma frota ou ativá-la manualmente em clusters públicos ou clusters particulares.
Configurar a descoberta de endpoints entre clusters públicos
Para configurar a descoberta de endpoints entre clusters do GKE, execute asmcli create-mesh
. Esse comando:
- Registra todos os clusters na mesma frota.
- Configura a malha para confiar na identidade da carga de trabalho da frota.
- Cria secrets remotos.
É possível especificar o URI de cada cluster ou o caminho do arquivo kubeconfig.
URI do cluster
No comando a seguir, substitua FLEET_PROJECT_ID
pelo
ID do projeto do host da frota e o URI do cluster pelo
nome do cluster, zona ou região e pelo ID do projeto de cada cluster.
Este exemplo mostra apenas dois clusters, mas é possível executar o comando para ativar
a descoberta de endpoints em clusters adicionais, sujeito ao
número máximo permitido de clusters que podem ser adicionados à sua frota.
./asmcli create-mesh \
FLEET_PROJECT_ID \
${PROJECT_1}/${LOCATION_1}/${CLUSTER_1} \
${PROJECT_2}/${LOCATION_2}/${CLUSTER_2}
Arquivo kubeconfig
No comando a seguir, substitua FLEET_PROJECT_ID
pelo
ID do projeto do
projeto host da frota
e PATH_TO_KUBECONFIG
pelo caminho para cada
kubeconfig
. Este exemplo mostra apenas dois clusters, mas é possível executar o
comando para ativar a descoberta de endpoints em clusters adicionais, sujeito ao
número máximo permitido de clusters que podem ser adicionados à sua frota.
./asmcli create-mesh \
FLEET_PROJECT_ID \
PATH_TO_KUBECONFIG_1 \
PATH_TO_KUBECONFIG_2
Configurar a descoberta de endpoints entre clusters particulares
Configure secrets remotos para permitir que o servidor de API acesse o cluster com o plano de controle do Cloud Service Mesh de outro cluster. Os comandos dependem das suas Tipo do Cloud Service Mesh (no cluster ou gerenciado):
A. Para o Cloud Service Mesh no cluster, é preciso configurar os IPs particulares em vez dos IPs públicos porque os IPs públicos não estão acessíveis:
PRIV_IP=`gcloud container clusters describe "${CLUSTER_1}" --project "${PROJECT_1}" \ --zone "${LOCATION_1}" --format "value(privateClusterConfig.privateEndpoint)"` ./istioctl x create-remote-secret --context=${CTX_1} --name=${CLUSTER_1} --server=https://${PRIV_IP} > ${CTX_1}.secret
PRIV_IP=`gcloud container clusters describe "${CLUSTER_2}" --project "${PROJECT_2}" \ --zone "${LOCATION_2}" --format "value(privateClusterConfig.privateEndpoint)"` ./istioctl x create-remote-secret --context=${CTX_2} --name=${CLUSTER_2} --server=https://${PRIV_IP} > ${CTX_2}.secret
B. Para o Cloud Service Mesh gerenciado:
PUBLIC_IP=`gcloud container clusters describe "${CLUSTER_1}" --project "${PROJECT_1}" \ --zone "${LOCATION_1}" --format "value(privateClusterConfig.publicEndpoint)"` ./istioctl x create-remote-secret --context=${CTX_1} --name=${CLUSTER_1} --server=https://${PUBLIC_IP} > ${CTX_1}.secret
PUBLIC_IP=`gcloud container clusters describe "${CLUSTER_2}" --project "${PROJECT_2}" \ --zone "${LOCATION_2}" --format "value(privateClusterConfig.publicEndpoint)"` ./istioctl x create-remote-secret --context=${CTX_2} --name=${CLUSTER_2} --server=https://${PUBLIC_IP} > ${CTX_2}.secret
Aplique os novos secrets aos clusters:
kubectl apply -f ${CTX_1}.secret --context=${CTX_2}
kubectl apply -f ${CTX_2}.secret --context=${CTX_1}
Configurar redes autorizadas para clusters particulares
Siga esta seção somente se todas as condições a seguir se aplicarem à sua malha:
- Você está usando clusters particulares.
- Os clusters não pertencem à mesma sub-rede.
- Os clusters têm redes autorizadas.
Ao implantar vários clusters particulares, o plano de controle do Cloud Service Mesh cada cluster precisa chamar o plano de controle do GKE da 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.
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)"`
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.
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.
É necessário ativar o acesso global ao plano de controle para permitir que o plano de controle do Cloud Service Mesh em cada cluster chame o plano de controle do GKE dos clusters remotos.
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
Verifique se o acesso global ao plano de controle está ativado:
gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1}
gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2}
A seção
privateClusterConfig
na saída exibe o status demasterGlobalAccessConfig
.
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.
Definir variável para diretório de amostras
Navegue até o local onde
asmcli
foi salvo e execute o seguinte comando para configurar oASM_VERSION
export ASM_VERSION="$(./asmcli --version)"
Defina uma pasta de trabalho para as amostras que você usa para verificar se o balanceamento de carga entre clusters funciona. As amostras estão localizadas em um subdiretório, no diretório
--output_dir
que você especificou no comandoasmcli install
. No comando a seguir, altereOUTPUT_DIR
para o diretório especificado em--output_dir
.export SAMPLES_DIR=OUTPUT_DIR/istio-${ASM_VERSION%+*}
Ative a injeção de sidecar
Criar o namespace de amostra em cada cluster.
for CTX in ${CTX_1} ${CTX_2} do kubectl create --context=${CTX} namespace sample done
Ativar a injeção do arquivo secundário em namespaces criados.
Recomendado:execute o seguinte comando para aplicar o rótulo de injeção padrão ao namespace:
for CTX in ${CTX_1} ${CTX_2} do kubectl label --context=${CTX} namespace sample \ istio.io/rev- istio-injection=enabled --overwrite done
Recomendamos que você use a injeção padrão, mas a injeção baseada em revisão tem suporte: Siga estas instruções:
Use o seguinte comando para localizar o rótulo de revisão em
istiod
:kubectl get deploy -n istio-system -l app=istiod -o \ jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
Aplique o rótulo de revisão ao namespace. No comando a seguir,
REVISION_LABEL
é o valor do rótulo de revisãoistiod
que você anotou na etapa anterior.for CTX in ${CTX_1} ${CTX_2} do kubectl label --context=${CTX} namespace sample \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite done
Instalar o serviço HelloWorld
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
Implante
HelloWorld v1
emCLUSTER_1
ev2
emCLUSTER_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
Confirme se
HelloWorld v1
ev2
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
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
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:
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 ...
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 Cloud 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}