Na minha opinião, um dos aspectos mais bacanas da solução enterprise Anthos do Google é o Anthos Config Management (ACM). Você cria um repositório Git, conecta seus diversos clusters a ele e eles padronizam suas configurações e evitam drift no estilo GitOps. Isso é especialmente importante para grandes empresas que gerenciam centenas ou milhares de clusters em diferentes locais de hospedagem.
Automatizando a configuração multi-cluster do Kubernetes com Argo CD
Inspirado pelo ACM, fiquei curioso para saber se conseguiria recriar esse tipo de funcionalidade usando outra solução GitOps, o Argo CD. Tenho o prazer de contar que funcionou como esperado: quando alterei os arquivos de configuração no repositório Git, as mudanças foram aplicadas nos dois clusters sem nenhum problema.
Visão geral da arquitetura
O setup
Para simplificar, criei dois clusters no serviço gerenciado de Kubernetes do Google Cloud, o GKE, em duas regiões distintas para simular cenários East e West. É claro que você pode instalar o Argo CD em clusters em qualquer lugar, desde que eles consigam acessar seu repositório Git.
Criei o shell script abaixo para fazer o bootstrap de tudo; mas, em produção, recomendo gerenciar a infraestrutura com Terraform sempre que possível.
Clusters após o bootstrap
Em 8 a 10 minutos, os dois clusters estavam ativos e os workloads do Argo CD já tinham sido implantados.
Clusters Kubernetes nas regiões East e West
Argo CD implantado em cada cluster
App of Apps
O que torna esse setup diferente é que também instalei o Argo CD em cada cluster com uma Application inicial usando o padrão App of Apps, apontando para o meu repositório no GitHub. Isso dá a flexibilidade de adicionar quantas configurações você quiser ao repositório no futuro e personalizar os clusters ou os apps que você implanta neles.
Vale lembrar que a sincronização automática é totalmente opcional. Se o número de clusters for muito grande, recomendo ativá-la, para que os clusters façam self-healing e gerenciem o drift sozinhos. Uma desvantagem do auto-sync, porém, é que o recurso de rollback não funciona.
A pasta (path) applications/ tem um app dentro dela (por enquanto), chamado k8s-config.yaml, que é mais um app do Argo apontando para outra pasta com nossas configurações do Kubernetes.
A pasta (path) k8s-config/ contém todos os arquivos YAML que queremos aplicar nos meus clusters Kubernetes. Você também pode, opcionalmente, declarar um app para aplicar as configurações de forma recursiva, caso tenha muitos arquivos para organizar.
Repositório de código-fonte
Para o experimento, publiquei um repositório de código-fonte no GitHub em mikesparr/multi-cluster-argo-demo, com a estrutura de diretórios a seguir.
Estrutura do repositório de código-fonte
Tudo neste exemplo está em um único repositório, mas você pode separar as responsabilidades usando repositórios diferentes e dando permissões de edição para times distintos.
Interface do Argo
Pela linha de comando, você pode fazer port-forward para o serviço argo-server
kubectl -n argocd port-forward svc/argo-server 8080:443
No navegador, acesse http://localhost:8080 e, quando solicitado, aceite a exceção de segurança (sem https). DICA: por padrão, o login é feito com admin e o nome completo do pod do servidor argocd:
Copie o argocd-server-XXXXXXX para usar como senha padrão
De início, aparece o applications (app of apps) até a sincronização
Depois que o seu App of Apps ( applications) sincronizar, ele vai reconhecer o primeiro app k8s-config.
Depois que as duas applications estão sincronizadas
Se você clicar no painel do app k8s-config, verá uma visão detalhada de tudo o que ele instalou no servidor.
Todos os arquivos YAML no diretório /k8s-config do repositório são aplicados no servidor
Confirmando as configurações dos clusters
Mude o contexto do seu kubectl para cada cluster e confira os namespaces, serviceaccounts, roles e rolebindings do test-namespace. Dá para ver tudo instalado nos dois clusters. Parabéns!
O cluster instalou automaticamente os workloads a partir do repositório Git
Demo em vídeo
Demo ao vivo adicionando um pod Nginx e fazendo auto-deploy para múltiplos clusters a partir do repositório no GitHub
Potencial infinito
Imagine que você queira adicionar um API Gateway à sua stack e escolha o Ambassador ou o Kong, ambos configurados com CRDs e YAML. Bastaria adicionar outra pasta ou repositório, depois mais um YAML de app dentro da pasta applications/, e o ArgoCD instalaria e configuraria tudo automaticamente para você.
Para cada aplicação que o time de engenharia publicar, basta editar a versão da imagem Docker em um manifesto Deployment, abrir um pull request com a alteração, e você já tem aprovações manuais e separação de responsabilidades embutidas. Assim que o PR for mesclado, o Argo CD vai implantá-lo no cluster e ambiente correspondentes.
Outro caso de uso seria suportar deployments multi-cloud e balancear o tráfego via DNS para uma configuração ativo-ativo de verdade. Outro ainda seria migrar de uma nuvem para outra.
Mal posso esperar para explorar mais possibilidades e espero que você tenha curtido mais uma maneira de manter clusters sincronizados entre diferentes ambientes.
Limpeza
Se você usou o script e/ou o repositório, não esqueça de fazer a limpeza e remover os recursos para evitar cobranças desnecessárias. A forma mais simples é excluir os clusters com o comando abaixo (ou então o projeto inteiro).
gcloud container clusters delete west --zone us-west2-b
gcloud container clusters delete east --zone us-east1-c