Configurar uma malha de vários clusters fora do Google Cloud
Neste guia, explicamos como configurar uma malha de vários clusters para as seguintes plataformas:
- Google Distributed Cloud
- Google Distributed Cloud
- GKE no Azure
- GKE na AWS
- Clusters anexados, incluindo clusters do Amazon EKS e clusters do Microsoft AKS
Neste guia, mostramos como configurar dois clusters, mas é possível ampliar esse processo para incorporar vários clusters à malha.
Antes de começar
Neste guia, presume-se que você tenha instalado o Cloud Service Mesh usando
asmcli install. 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.
Se precisar de configuração, siga as etapas em
Instalar ferramentas dependentes e validar o cluster
para:
- Instale as ferramentas necessárias
- Fazer o download de
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.
Configurar variáveis de ambiente e marcadores
Você precisa das seguintes variáveis de ambiente ao instalar o gateway leste-oeste.
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)")Crie uma variável de ambiente para o identificador da malha.
export MESH_ID="proj-${PROJECT_NUMBER}"Crie variáveis de ambiente para os nomes dos clusters no formato exigido por
asmcli.export CLUSTER_1="cn-FLEET_PROJECT_ID-global-CLUSTER_NAME_1" export CLUSTER_2="cn-FLEET_PROJECT_ID-global-CLUSTER_NAME_2"Consiga o nome do contexto para os clusters usando os valores na coluna
NAMEna saída deste comando:kubectl config get-contexts
Defina as variáveis de ambiente para os nomes de contexto de cluster, o que será usado por este guia em várias etapas posteriores:
export CTX_1=CLUSTER1_CONTEXT_NAME export CTX_2=CLUSTER2_CONTEXT_NAME
Instalar o gateway leste-oeste
Nos comandos a seguir:
Substitua
CLUSTER_NAME_1eCLUSTER_NAME_2pelos nomes dos clusters.Substitua
PATH_TO_KUBECONFIG_1ePATH_TO_KUBECONFIG_2pelos arquivos kubeconfig dos clusters.
Clusters do Anthos
Mesh CA ou serviço de CA
Instale um gateway no cluster1 que seja 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 outras restrições de acesso, como regras de firewall, para evitar ataques externos.asm/istio/expansion/gen-eastwest-gateway.sh \ --mesh ${MESH_ID} \ --cluster ${CLUSTER_1} \ --network default \ --revision asm-1271-5 | \ ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_1 \ install -y --set spec.values.global.pilotCertProvider=kubernetes -f -Instale um gateway em
$CLUSTER_2dedicado ao tráfego leste a oeste para$CLUSTER_1.asm/istio/expansion/gen-eastwest-gateway.sh \ --mesh ${MESH_ID} \ --cluster ${CLUSTER_2} \ --network default \ --revision asm-1271-5 | \ ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 \ install -y --set spec.values.global.pilotCertProvider=kubernetes -f -
CA do Istio
Instale um gateway no cluster1 que seja 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 outras restrições de acesso, como regras de firewall, para evitar ataques externos.asm/istio/expansion/gen-eastwest-gateway.sh \ --mesh ${MESH_ID} \ --cluster ${CLUSTER_1} \ --network default \ --revision asm-1271-5 | \ ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_1 \ install -y --set spec.values.global.pilotCertProvider=istiod -f -Instale um gateway em
$CLUSTER_2dedicado ao tráfego leste a oeste para$CLUSTER_1.asm/istio/expansion/gen-eastwest-gateway.sh \ --mesh ${MESH_ID} \ --cluster ${CLUSTER_2} \ --network default \ --revision asm-1271-5 | \ ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 \ install -y --set spec.values.global.pilotCertProvider=istiod -f -
Azure, AWS e anexo
CA da malha
Instale um gateway no cluster1 que seja 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 outras restrições de acesso, como regras de firewall, para evitar ataques externos.asm/istio/expansion/gen-eastwest-gateway.sh \ --mesh ${MESH_ID} \ --cluster ${CLUSTER_1} \ --network default \ --revision asm-1271-5 | \ ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_1 \ install -y --set spec.values.global.pilotCertProvider=istiod -f -Instale um gateway em
$CLUSTER_2dedicado ao tráfego leste a oeste para$CLUSTER_1.asm/istio/expansion/gen-eastwest-gateway.sh \ --mesh ${MESH_ID} \ --cluster ${CLUSTER_2} \ --network default \ --revision asm-1271-5 | \ ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 \ install -y --set spec.values.global.pilotCertProvider=istiod -f -
CA do Istio
Instale um gateway no cluster1 que seja 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 outras restrições de acesso, como regras de firewall, para evitar ataques externos.asm/istio/expansion/gen-eastwest-gateway.sh \ --mesh ${MESH_ID} \ --cluster ${CLUSTER_1} \ --network default \ --revision asm-1271-5 | \ ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_1 \ install -y --set spec.values.global.pilotCertProvider=istiod -f -Instale um gateway em
$CLUSTER_2dedicado ao tráfego leste a oeste para$CLUSTER_1.asm/istio/expansion/gen-eastwest-gateway.sh \ --mesh ${MESH_ID} \ --cluster ${CLUSTER_2} \ --network default \ --revision asm-1271-5 | \ ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 \ install -y --set spec.values.global.pilotCertProvider=istiod -f -
Como 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.
Exponha os serviços por meio do gateway leste-oeste para o
CLUSTER_NAME_1.kubectl --kubeconfig=PATH_TO_KUBECONFIG_1 apply -n istio-system -f \ asm/istio/expansion/expose-services.yamlExponha os serviços por meio do gateway leste-oeste para o
CLUSTER_NAME_2.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
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
istiodque 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 doneem que REVISION é o rótulo de revisão
istiodque você anotou anteriormente.A resposta é:
label "istio-injection" not found. namespace/sample labeled
Você pode ignorar
label "istio-injection" not found.com segurançaCrie o serviço HelloWorld em ambos os clusters:
kubectl create --context=${CTX_1} \ -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \ -l service=helloworld -n samplekubectl 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 v1emCLUSTER_1ev2emCLUSTER_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 samplekubectl create --context=${CTX_2} \ -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \ -l version=v2 -n sampleConfirme se
HelloWorld v1ev2estão em execução usando os seguintes comandos. Verifique se a saída é semelhante a esta:kubectl get pod --context=${CTX_1} -n sampleNAME READY STATUS RESTARTS AGE helloworld-v1-86f77cd7bd-cpxhv 2/2 Running 0 40s
kubectl get pod --context=${CTX_2} -n sampleNAME READY STATUS RESTARTS AGE helloworld-v2-758dd55874-6x4t8 2/2 Running 0 40s
Implantar o serviço Sleep
Implante o serviço
Sleepnos 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 doneAguarde a inicialização do serviço
Sleepem cada cluster. Verifique se a saída é semelhante a esta:kubectl get pod --context=${CTX_1} -n sample -l app=sleepNAME READY STATUS RESTARTS AGE sleep-754684654f-n6bzf 2/2 Running 0 5s
kubectl get pod --context=${CTX_2} -n sample -l app=sleepNAME 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
HelloWorldnovamente: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
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}