🏷️ Kubernetes

No post anterior, deixamos nossas máquinas virtuais ligadas e conversando em uma rede privada isolada no KVM. Temos load balancers, managers, workers e um servidor NFS com endereços estáticos e resolução de nomes básica. Se tentarmos rodar qualquer comando do Kubernetes nelas agora, nada vai acontecer: não há binários instalados, não há certificados emitidos e nenhum processo do control plane existe. Antes de enviar a primeira instrução para as máquinas, precisamos responder a uma pergunta de arquitetura: onde vive a verdade sobre as versões, as faixas de rede e os papéis de cada nó?

Na Parte 1 desta série, gastamos o post inteiro falando sobre por que construir um cluster Kubernetes na mão e o que pretendemos montar. Conceitos, diagramas, motivação. Agora é hora de sujar as mãos de verdade: vamos configurar o computador hospedeiro, dissecar linha por linha como o Vagrant lê nosso inventário Ansible para criar máquinas virtuais e resolver o problema mais traiçoeiro de qualquer laboratório local de Kubernetes: fazer a rede funcionar direito.

Se você trabalha com infraestrutura, nuvem ou DevOps, as chances de você já ter digitado kubeadm init ou subido um cluster em nuvem gerenciada (EKS, GKE, AKS) com dois cliques são de praticamente cem por cento. Essas ferramentas são incríveis para o dia a dia de trabalho porque ninguém em sã consciência quer passar quatro horas configurando certificados e manifestos na mão para subir um ambiente de homologação. O problema começa quando algo quebra nos bastidores e você não faz a menor ideia do que está acontecendo por baixo do capô.