Construindo uma plataforma Cloud Native do zero com Kairos, k0rdent e bindy
Este artigo detalha a estratégia de engenharia de plataforma da RBC Capital Markets para gerenciar 50+ clusters Kubernetes em ambientes híbridos e regulados. A solução centraliza-se em infraestrutura imutável (Kairos), orquestração de ciclo de vida de clusters (k0rdent) e automação de DNS nativa (bindy). A conclusão principal é que a unificação de operações via modelos declarativos, versionados em Git, elimina o drift de configuração e garante conformidade contínua, transformando a infraestrutura em código real e auditável.
Como compartilhamos anteriormente em nosso post sobre FluxCD, a RBC Capital Markets iniciou uma jornada deliberada para modernizar nossa plataforma Kubernetes. O GitOps com FluxCD nos forneceu uma fundação sólida de deployment. No entanto, ao escalar para mais de 50 clusters entre ambientes on-premises VMware e multi-cloud, enfrentamos desafios que ferramentas de mercado não resolviam isoladamente: como gerenciar o lifecycle dos clusters, garantir que cada node seja imutável e integrar o service discovery do Kubernetes com DNS corporativo sem filas de tickets.
O desafio: Engenharia de plataforma em ambiente regulado
Gerenciar 50+ clusters não é apenas um desafio operacional, mas de compliance (SOX, PCI-DSS, Basel III). Problemas como nodes "flocos de neve" (nodes únicos, mal documentados), drift de configuração e registros DNS manuais não são aceitáveis. Identificamos três lacunas principais:
- Node configuration drift: Nodes baseados em VMs que eram alterados manualmente via patches e perdiam a previsibilidade.
- Cluster provisioning: O provisionamento manual levava dias, sem uma única fonte da verdade.
- DNS integration: A dependência da equipe de rede para cada novo endpoint de ingress criava gargalos e audit trails fora do fluxo GitOps.
Kairos: OS imutável para nodes de confiança
O primeiro pilar foi a imutabilidade. O Kairos, projeto Sandbox da CNCF, permite que cada node inicialize a partir de uma imagem OCI versionada. A configuração do nó — chaves SSH, autenticação SSSD/AD e registro no Kubernetes — é definida via cloud-config em YAML, tratado pelo FluxCD.
Um pipeline CI/CD para imagens de sistema
Tratamos nossas imagens Kairos como imagens de container: cada alteração dispara um pipeline no GitHub Actions que builda a imagem, executa testes de integração em VMs reais e publica uma tag OCI apenas após a aprovação.
Como a automação de VMs com VirtRigaud elimina o drift operacional?
Para o provisionamento, utilizamos o VirtRigaud, um operator Kubernetes que fornece gerenciamento declarativo de VMs. O provisioning de um nó Kairos torna-se semanticamente idêntico ao deploy de uma carga de trabalho: um pull request aprovado e reconciliado automaticamente.
k0rdent: O lifecycle de cluster como plataforma
O k0rdent, construído sobre a Cluster API (CAPI), permite modelar clusters como CRDs. Combinado com o k0s (distribuição Kubernetes de binário único) e k0smotron, conseguimos expressar toda nossa topologia de forma declarativa.
Essa abordagem permite:
- Cluster upgrades: Simplesmente um PR alterando a versão no manifesto.
- Cluster templates: Padronização institucional para diferentes times (trading, risco), reduzindo o tempo de criação de dias para minutos.
bindy: Operações DNS nativas do Kubernetes
O bindy é um operator desenvolvido em Rust que gerencia zonas e registros DNS como recursos de primeira classe (CRDs) no Kubernetes. Ele atua como o elo entre o GitOps e sistemas de DDI legados (como Infoblox).
Ao usar o bindy, registros DNS são criados automaticamente via FluxCD conforme o serviço é provisionado, transformando DNS de um gargalo manual em parte integrante do ciclo de vida da aplicação.
Como os três componentes se encaixam?
A coerência da plataforma reside no princípio: tudo é código, reconciliado continuamente.
- Git (Fonte da verdade)
- FluxCD (Motor de reconciliação)
- k0rdent / CAPI: Lifecycle de clusters.
- Kairos cloud-config: Configuração imutável de nodes.
- bindy CRDs: Registros DNS orquestrados.
- FluxCD (Motor de reconciliação)
Desafios e aprendizados
- Integração corporativa demanda paciência: SSSD, caixas de certificados corporativos (CA) e NetworkManager exigem atenção dobrada em ambientes imutáveis.
- Shift-left de responsabilidade: Quando o provisioning vira um pull request, a governança dos templates torna-se o ponto crítico de segurança.
- Maturidade de Rust: O uso de kube-rs é excelente para performance, mas exige design cuidadoso para arquiteturas multi-controller.
Artigo originalmente publicado por Erick Bourgeois, Director & Head of Kubernetes Platform Engineering, RBC Capital Markets em Cloud Native Computing Foundation.
