Meu primeiro cluster Kubernetes de verdade

Olá! Você está lendo este post do meu cluster kubernetes! Louco, né? (Na verdade, não é nada demais...)

Já faz algum tempo que eu estava pensando e planejando como realizar isso. Depois que aprendi sobre Docker, depois Docker Compose, mais tarde Docker Swarm, e ouvi falar sobre Kubernetes, pensei que não precisaria de mais nada. O Docker Swarm sempre atendeu à minha necessidade: balanceamento de carga, fail-overs e rollouts (ou rollbacks) de atualização seguros.

A Necessidade de Escalar

Foi depois que me aprofundei em CI/CD com Github Actions e vi a conveniência de auto-hospedá-los dentro da nossa VCN que as coisas começaram a mudar. A implantação era tão simples quanto um docker stack deploy com um DOCKER_HOST personalizado.

No entanto, minha equipe e eu começamos a ter que esperar pelas execuções de outros colegas. Vi a necessidade de múltiplas instâncias. O problema era simples de resolver:

Adicionar mais instâncias!

Mas não parecia legal ter sempre 10 instâncias ociosas para alguns casos específicos durante a semana, quando teríamos mais de 5 execuções acontecendo simultaneamente.

Descobrindo uma Solução: ARC

Então descobri o ARC (Actions Runner Controller), que foi criado pela comunidade e tinha acabado de ser adotado pelo próprio Github. Isso tornou a documentação muito confusa. Eu tinha três lugares para ler sobre o assunto, todos com instruções diferentes. Como alguém que nunca tinha usado Kubernetes, me senti perdido, mas sabia o que tinha que fazer.

O melhor lugar para começar a aprender sobre algo que você não entende é, claro, o Youtube!

Encontrei alguns guias sobre como configurar tudo e instalei as ferramentas necessárias:

• minikube
• helm
• kubectl

Em minutos, eu tinha o ambiente configurado corretamente. Em seguida, configurei os Runners do Github e os personalizei para ter um ambiente dind (Docker in Docker). E era isso! Estava funcionando. Agora sempre tínhamos um runner ocioso e, se precisássemos de mais, ele criaria outra instância em apenas seis segundos.

Mas eu sempre senti que não era o suficiente para mim. Eu tinha alcançado meu objetivo, mas descobri um sistema totalmente novo: o Kubernetes. É cativante, escalável, uma palavra-chave, um tópico quente. E eu senti que não sabia nada sobre isso. Segui as instruções de alguém, mas isso não significava que eu entendia. Eu tinha sede de aprender mais.

Construindo o Cluster "de Verdade"

O Oracle Cloud tem um nível gratuito insano para o qual uma vez me inscrevi para hospedar um servidor de Minecraft com alguns velhos amigos: 4 OCPUs e 24GB de RAM. Eu normalmente o usava como um único servidor para meus projetos.

Um dia eu vi que eles também oferecem seu módulo OKE (Oracle Kubernetes Engine) com um cluster Básico se você se inscrever no plano "Pay as you go".

Então, nas minhas férias, decidi encarar o desafio! A Oracle tem uma "Configuração Rápida" fácil que cria uma nova VCN, um Load Balancer e um pool de nós. Decidi distribuir o nível gratuito deles em dois nós de 2 OCPUs e 12GB de RAM cada, o que é suficiente para mim.

Primeiro, configurei meu registro Docker para gerenciar minhas próprias imagens Docker, como a deste site! Depois, decidi configurar o ARC novamente (não vou mentir, sou um grande fã do Github Actions).

Adotando GitOps com ArgoCD

Comecei a pesquisar como poderia automatizar implantações e outras coisas. Eu queria fazer do jeito certo. Depois de um estudo muito intensivo com Gemini, Claude, ChatGPT, Grok e pesquisas no Google (é difícil abandonar velhos hábitos), encontrei o ArgoCD, que usa um fluxo de trabalho GitOps.

O GitOps era exatamente o que eu estava procurando. E tudo o que li me dizia por que era uma má prática sempre fazer o auto-deploy a partir da tag latest.

O Primeiro Obstáculo: ImagePullbackError

Eu refiz meu site, adicionei alguns toques finais e criei um blog onde eu pudesse “blá, blá, blá…” sobre coisas. Depois, acho que vai ser engraçado e um pouco vergonhoso olhar para isso daqui a alguns anos.

E foi isso. Criei o projeto no ArgoCD, apertei o deploy e…

ImagePullbackError

Ótimo! O problema levou algumas horas de depuração, mas era porque a Action do Github build-and-push do Docker, se configurada para usar um registro Docker para cache, não usa os valores de /etc/hosts. Ela estava tentando enviar o arquivo pela rede externa.

O Verdadeiro Gargalo

O que me leva a apresentar a vocês o maior gargalo deste projeto: o balanceador de carga!

Não me entenda mal, é ótimo e funciona sem precisar de configuração, mas a Oracle oferece apenas 10Mbps de largura de banda gratuitamente. Fazer o push de uma imagem Docker leva uma eternidade, mesmo uma que usa construção multi-stage com variantes alpine e uma base final distroless do Google. Tentei de tudo — configurar hosts personalizados, DNS, rotas internas — mas não teve jeito, a ponto de eu desistir do cache. Leva alguns minutos para construir uma nova imagem, mas estou feliz com o resultado final.

Conclusão

E, finalmente, eu realmente senti que pelo menos sabia algo sobre Kubernetes: implantar um cluster, gerenciá-lo e depurá-lo.

É isso, pessoal. Obrigado por lerem meu primeiro post de verdade. 🙂