Deployando clusters K3s em produção sem perder a sanidade
K3s é uma distribuição Kubernetes certificada pela CNCF que empacota tudo que você precisa num binário único de aproximadamente 70 MB. Foi criada pelo Rancher para rodar em ambientes com recursos limitados, mas hoje é amplamente usada em produção também por causa da simplicidade operacional. Se você está cansado de lidar com arquivos YAML gigantescos e componentes que simplesmente não iniciam, vale a pena olhar com atenção. O processo de instalação começa basicamente assim: um comando curl que baixa o binário e um script de instalação que configura o serviço systemd. Até aí é trivial. O problema real começa quando você tenta fazer algo que um cluster padrão faria normalmente, como expor serviços para o exterior ou gerenciar persistência de dados entre nós.
Vou explicar como configurar um cluster com três nós workers e um servidor, porque essa é a configuração que mais vejo dando errado. O nó servidor precisa ter acesso a uma base de dados externa se você quer alta disponibilidade. O K3s usa SQLite por padrão, o que é aceitável para desenvolvimento, mas é um ponto único de falha em produção. Para o banco, eu recomendo PostgreSQL. O comando de instalação no servidor fica mais ou menos assim:
O que todo mundo chama de top technology e por que funciona na prática
sudo curl -sfL https://get.k3s.io | sh -s - server --token meu-token-secreto --cluster-init No primeiro nó worker, você roda algo parecido mas com a flag join em vez de server, apontando para o IP do servidor e usando o mesmo token. Aí vem a parte que ninguéma direito: o token. Ele precisa ser exatamente o mesmo em todos os nós, caso contrário o worker nunca entra no cluster. Eu perdi duas horas numa sexta à noite descobrindo que um espaço em branco no final do token era o problema.
Para obter o token depois da instalação, ele fica em /etc/rancher/k3s/node_token no nó servidor. Copie o conteúdo exato, sem quebras de linha extras, e use no comando de join do worker. Outro ponto que causa dor de cabeça é o fluxo de tráfego entre os nós. K3s usa a porta 6443 por padrão para comunicação API server, mas também precisa de várias portas UDP e TCP para o networking do canal de serviço. Se você está atrás de um firewall ou em uma nuvem com security groups restritos, a conexão dos workers com o servidor simplesmente cai e o log mostra coisas como "connection refused" no kubelet. A solução é liberar pelo menos as portas 6443 (TCP), 10250 (TCP para health checks), e a faixa de 30000-32767 (TCP/UDP para NodePort services).
👉 Clique no botão abaixo para saber mais sobre o assunto!
Eu configurei recentemente um cluster K3s num provedor de nuvem com instâncias t3.micro e rodei benchmarks de carga usando kubectl top e stress-ng. O resultado foi surpreendente: o cluster consumia cerca de 800 MB de RAM em idle e conseguia processar rotas de ingress básico sem degradação perceptível. A sobrecarga comparada a um Kubernetes vanilla é praticamente invisível na maioria dos cenários. Mas há limitações sérias que você precisa conhecer antes de decidir usar. O suporte a certos tipos de CRDs mais complexos é limitado porque o K3s embrulha vários componentes em um único processo. Controller-manager, scheduler, e outros componentes que seriam separados no Kubernetes convencional rodam juntos. Isso significa que se um deles travar, tudo para. O scheduler falhou uma vez durante uma migração de carga e derrubou meu cluster por 12 minutos. Em um cluster vanilla, o scheduler cairia e os pods simplesmente não seriam escalonados, mas o resto continuaria funcionando.
Para persistência de dados, a solução mais comum é usar Longhorn, que é desenvolvido pelo mesmo time do Rancher. Instalação via helm é simples: um comando coloca um sistema de storage distribuído rodando no cluster. Mas tome cuidado com a configuração padrão de replications. Para workloads críticos, aumente o número de réplicas de 2 para 3, senão você perde dados se um nó cair. Se você está avaliando alternativas, considere o k0s se precisar de algo ainda mais minimalista, ou o microk8s se estiver mais focado em desenvolvimento local. O K3s ocupa um espaço médio interessante entre simplicidade e funcionalidade completa.
Um detalhe técnico que poucos mencionam: o K3s usa containerd por padrão em vez de Docker. Isso é uma vantagem para performance, mas significa que comandos como docker ps não vão funcionar. Use crictl ou nerdctl para inspecionar containers. Se seu time depende fortemente de Docker para debugging, adapte-se rápido ou instale o pacote k3s-docker que traz compatibilidade, mas com overhead adicional de aproximadamente 200 MB de RAM por nó. Agora sobre atualização do cluster, que é onde muita gente se enrola. O K3s tem um mecanismo de auto-update via systemd timer, mas ele não é perfeito. Atualizações maiores de versão costumam exigir intervenção manual. O processo recomendado é atualizar primeiro o nó servidor, esperar ele iniciar e validar o status com kubectl get nodes, e só então atualizar os workers um por um, nunca todos de uma vez. Eu atualizei acidentalmente três workers simultaneamente e o cluster ficou indisponível por 25 minutos porque nenhum nó conseguia estabelecer quorum com o API server durante a transição.
Para automação em escala, use o script de instalação com variáveis de ambiente. Defina K3S_TOKEN, K3S_URL, e K3S_NODE_NAME antes de rodar o curl pipe sh. Isso elimina erros humanos de digitação e torna o processo reproducível em dez ambientes diferentes sem inconsistências.
