O Anthos Service Mesh (ASM) é uma instalação gerenciada do Istio, um service mesh para Kubernetes. Confira nosso guia passo a passo para configurar um ASM multi-cluster usando o control plane gerenciado.

Anthos Service Mesh

Este é um guia prático, passo a passo, para subir um Anthos Service Mesh (ASM) multi-cluster usando o control plane gerenciado.

O código que acompanha o guia está disponível aqui: https://github.com/caddac/anthos-examples/tree/main/asm

Um service mesh é uma camada de abstração construída sobre diferentes plataformas de computação – neste caso, clusters – para simplificar a comunicação entre serviços, a observabilidade e a segurança. Ele transfere essas responsabilidades para a plataforma e deixa a aplicação mais enxuta. Neste post, vamos implantar o Anthos Service Mesh, que é uma instalação gerenciada do Istio. O Istio é um service mesh para Kubernetes, uma ferramenta poderosa para ter uma visão consistente sobre observabilidade e segurança entre serviços. No Istio, isso é feito intermediando toda a comunicação entre serviços por proxies que rodam como sidecars dos seus pods.

Os serviços podem usar os padrões consistentes e transparentes do Istio para se comunicar com outros serviços, sem precisar se preocupar em como chegar até outro serviço, com a segurança das requisições recebidas ou com a publicação de métricas sobre o tráfego entre serviços. Tudo isso fica a cargo do Istio. Esses recursos são ainda mais importantes quando você trabalha com uma configuração multi-cluster, em que o overhead operacional é ainda maior.

Usar um service mesh tem algumas desvantagens, como complexidade na configuração, consumo extra de recursos e custo. O Istio tem muitos recursos e várias formas de configuração, incluindo istioctl, IstioOperator e helm. No entanto, o Anthos Service Mesh com control plane gerenciado não suporta a API do IstioOperator nem o helm.

Neste tutorial, vamos criar dois clusters GKE e implantar a aplicação hello-world do Istio em ambos. Em seguida, instalaremos um único ingress (em apenas um cluster) e mostraremos que o tráfego é balanceado entre os 4 pods do hello-world rodando nos dois clusters GKE.

service-mesh

Implante o terraform

No diretório asm/infra, atualize os valores no arquivo var_inputs.auto.tfvars.

Faça o plan e o apply:

$ terraform init

$ terraform apply

Observação: se o apply falhar, tente rodar de novo. Às vezes, o terraform se atrapalha quando precisa criar muitos recursos dependentes de uma vez só. No meu caso, precisei rodar três vezes para que todos os recursos fossem criados.

Tem bastante coisa rolando aqui, então vamos resumir.

infra.tf

Esse arquivo cria um novo projeto no GCP e habilita várias APIs necessárias [1]. Uma observação rápida: a documentação oficial parece esquecer das APIs sts e anthos, então não deixe de habilitá-las.

Ele também cria uma VPC, duas sub-redes com ranges secundários e uma regra de firewall para que tudo se comunique. Por fim, habilita o recurso de hub mesh para o projeto.

cluster1.tf e cluster2.tf

Cada arquivo cria um cluster. Eles diferem apenas nos nomes dos clusters, regiões e referências de sub-rede. Vale destacar dois pontos na configuração do cluster. Primeiro, definimos a label mesh_id para que o GCP saiba a qual mesh este cluster pertence. Segundo, habilitamos o Workload Identity, que permite que service accounts do Kubernetes atuem como service accounts do GCP [2] sem precisar baixar nem criar chaves JSON.

Registramos o cluster na fleet, usando o nome do cluster como membership id.

Por fim, instalamos o control plane gerenciado. Estamos usando o control-plane automático (que significa "gerenciado"), mas em qual revisão? Verifique a label de revisão no namespace para descobrir qual revisão do control plane está em uso [5]. Sim, é simples assim!

A esta altura, temos dois clusters rodando na mesma fleet, ambos com o ASM instalado via control plane gerenciado. Já podemos começar a instalar os componentes do Istio, mas a descoberta de serviços entre clusters ainda não está funcionando.

Configure a descoberta de serviços entre clusters

Precisamos instalar os secrets de cada cluster em todos os outros clusters da nossa fleet. Felizmente, existe uma ferramenta de cli para isso – a asmcli. Infelizmente, ela ainda não roda no macOS, então o mais prático é executá-la no cloud console.

Abra o cloud console no seu projeto entrando no console do GCP e clicando no botão do cloud console.

istio-service-mesh

Quando o console aparecer na parte inferior da tela, execute os seguintes comandos:

$ curl https://storage.googleapis.com/csm-artifacts/asm/asmcli\_1.13 > asmcli

$ chmod +x asmcli

_$ ./asmcli create-mesh ${GOOGLE_CLOUD_PROJECT} _

_${GOOGLE_CLOUD_PROJECT}/us-west1/${GOOGLE_CLOUD_PROJECT}-cluster1 _

${GOOGLE_CLOUD_PROJECT}/us-east1/${GOOGLE_CLOUD_PROJECT}-cluster2

istio-kubernetes

Observação rápida: se você usa clusters privados, há etapas adicionais para habilitar a descoberta de serviços entre clusters [6][7].

Implante os apps e os componentes do Istio

A partir do diretório asm/manifests, podemos instalar apps para testar nosso mesh. No cluster 1, vamos instalar o app helloworld e os componentes do Istio para o ingress.

Comece obtendo os contextos dos clusters:

export PROJECT_ID=<gcp_project_id>

gcloud container clusters get-credentials ${PROJECT_ID}-cluster1 --region us-west1 --project ${PROJECT_ID}

gcloud container clusters get-credentials ${PROJECT_ID}-cluster2 --region us-east1 --project ${PROJECT_ID}

Instale o cluster 1 executando:

kubectl apply -k manifests/ --context=gke_${PROJECT_ID}_us-west1_${PROJECT_ID}-cluster1

E o cluster 2 executando:

kubectl apply -k manifests/app/ --context=gke_${PROJECT_ID}_us-east1_${PROJECT_ID}-cluster2

service-mesh-istio

Confira o resultado

Depois de alguns minutos, tudo deve estar no ar e você pode conferir o resultado.

Verifique se todos os pods do helloworld estão rodando nos dois clusters:

$ export PROJECT_ID=<gcp_project_id>

$ kubectl get pods -n helloworld

--context=gke_${PROJECT_ID}_us-west1_${PROJECT_ID}-cluster1

$ kubectl get pods -n helloworld

--context=gke_${PROJECT_ID}_us-east1_${PROJECT_ID}-cluster2

kubernetes-service-mesh

Verifique se o deployment do ingress-gateway está rodando no cluster 1

$ kubectl get deploy -n asm-gateways --context=gke_${PROJECT_ID}_us-west1_${PROJECT_ID}-cluster1

istio-mesh

Verifique se o serviço ingress-gateway tem um IP externo no cluster 1

$ kubectl get svc -n asm-gateways --context=gke_${PROJECT_ID}_us-west1_${PROJECT_ID}-cluster1

service-mesh kubernetes

Por fim, valide o balanceamento de carga entre clusters fazendo várias chamadas ao endpoint público. Você vai notar que a versão e o pod id mudam conforme diferentes pods respondem. O esperado é receber 4 pod ids diferentes e 2 versões diferentes.

application-mesh

$ curl /hello

service-mesh-architecture

Personalização e visualização de logs

Habilite os logs de debug do envoy

Já fizemos isso quando implantamos a configuração do asm. Dê uma olhada no arquivo asm/manifests/gateways/asm-config.yaml. O ConfigMap que implantamos configurou os proxies envoy para enviar os logs de acesso para o stdout. Há outras opções que você pode habilitar de forma parecida [3].

Logs do control plane

Mesmo com o control plane gerenciado, você continua conseguindo ver os logs do control plane. Eles ficam no Logs Explorer, sob o recurso "Istio Control Plane".

Configure Anthos Service Mesh multi-cluster com control plane gerenciado