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:
- GKE no VMware
- Google Distributed Cloud Virtual para Bare Metal
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 o Anthos Service Mesh tenha sido instalado 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
NAME
na 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_1
eCLUSTER_NAME_2
pelos nomes dos clusters.Substitua
PATH_TO_KUBECONFIG_1
ePATH_TO_KUBECONFIG_2
pelos arquivos kubeconfig dos clusters.
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-1157-23 | \ ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_1 install -y --set spec.values.global.pilotCertProvider=kubernetes -f -
Instale um gateway em
$CLUSTER_2
dedicado 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-1157-23 | \ ./istioctl install --kubeconfig=PATH_TO_KUBECONFIG_2 -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-1157-23 | \ ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_1 install -y -f -
Instale um gateway em
$CLUSTER_2
dedicado 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-1157-23 | \ ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 install -y -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.yaml
Exponha 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. A etapa depende do tipo de Anthos Service Mesh (gerenciado ou no cluster).
Gerenciado
Use o comando a seguir para localizar o identificador de revisão, que vai ser usado em etapas futuras.
kubectl get controlplanerevision -n istio-system
A saída será assim:
NAME RECONCILED STALLED AGE asm-managed-rapid True False 89d
Na saída, na coluna
NAME
, observe o valor do rótulo de revisão. Neste exemplo, o valor éasm-managed-rapid
. Use o valor da revisão nas etapas da próxima seção.No cluster
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 saída será assim:
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ãoistiod
, que segue o prefixoistio.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 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 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 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}