K3s — Kubernetes leve, do conceito à produção

O problema: Kubernetes é poderoso, mas pesado

O Kubernetes tornou-se o padrão para correr aplicações em contentores. O problema não é o que faz — é tudo o que arrasta: um cluster completo precisa de etcd, de plugins de nuvem, de controladores e de recursos que fazem sentido num data center, mas não num servidor único ou num Raspberry Pi. O k3s foi criado precisamente para resolver isto.

O que é o k3s

O k3s é uma distribuição de Kubernetes certificada pela CNCF, desenvolvida pela Rancher (hoje SUSE). "Certificada" é a parte importante: não é uma versão reduzida ou incompatível — é Kubernetes a sério, com a mesma API, os mesmos comandos kubectl, os mesmos manifestos. Qualquer coisa que corra num cluster Kubernetes normal corre no k3s.

A diferença está no pacote: tudo cabe num único binário de cerca de 70 MB, sem dependências externas.

Como funciona

O k3s condensa os componentes do Kubernetes (API server, scheduler, controller manager, kubelet, container runtime) num só binário. Para guardar o estado, usa SQLite embutido por defeito — em vez do etcd, onde residia a maior parte da complexidade.

• Modo single-node: servidor e agentes correm na mesma máquina. Ideal para homelab, CI ou edge.
• Modo multi-node (HA): vários servidores k3s partilham o estado através de uma base de dados externa (MySQL, Postgres, etcd).
• Agentes: máquinas worker que se juntam ao servidor com um token. Escala-se juntando nós.

O que foi removido: funcionalidades alpha ou legadas, in-tree cloud providers, drivers de storage antigos. O que ficou: substituições leves (containerd em vez de Docker, Traefik como ingress padrão, ServiceLB para balanceamento simples).

Para que serve na prática

• Edge e IoT: correr Kubernetes em hardware modesto, com rede instável e sem equipa de operações.
• Homelab: ter um cluster real em casa — num Pi, num NUC, num servidor antigo — para aprender e hospedar serviços próprios.
• Produção de pequena e média dimensão: sites, APIs, aplicações internas que não justificam a complexidade de um cluster Kubernetes completo.
• CI/CD: instâncias efémeras em pipelines para testar manifestos antes de chegarem a produção.
• ARM: suporte de primeira classe a arm64 — o mesmo binário corre num Pi ou num servidor AMD64.

k3s vs Kubernetes tradicional (k8s)

A pergunta certa não é "qual é melhor" — é "de que preciso". Se tem uma equipa de plataforma, vários data centers e precisa de cada funcionalidade nativa de nuvem, o k8s completo faz sentido. Se quer Kubernetes sem a sobrecarga — para um servidor, um cluster caseiro ou dezenas de nós edge — o k3s é a escolha.

O que se pode correr em k3s

Por ser Kubernetes certificado, o k3s corre praticamente tudo o que um cluster Kubernetes normal corre: sites e plataformas web, APIs, bases de dados em contentores, ferramentas internas e pipelines de automação. A questão não é "o que corre", mas sim "até onde escala".

Num único nó, aguenta sem problema sites institucionais, blogs, CMS headless e aplicações internas com tráfego real. Em configuração multi-server com base de dados externa (MySQL, Postgres ou etcd), o mesmo k3s serve workloads de média dimensão — plataformas SaaS internas, e-commerce de pequeno e médio porte, conjuntos de microserviços. Até onde isso chega depende de três factores concretos: a carga que se pretende servir, os recursos (CPU, RAM, rede) disponíveis para distribuir, e a arquitetura que se quer implementar. Não há número mágico — há decisões de engenharia.

Onde é usado, na prática

• Rede de retalho: cadeias com centenas ou milhares de lojas, cada uma com um k3s a correr ponto-de-venda, inventário e sincronização com a central. É o padrão de edge computing mais documentado para k3s — a própria SUSE/Rancher o posiciona para este cenário.
• Indústria e IoT: linhas de produção e dispositivos edge que precisam de orquestração local, com rede intermitente e sem equipa de operações no local.
• Plataformas web e SaaS: sites, APIs e aplicações de média dimensão onde um cluster gerido seria excessivo, mas onde se quer a API completa do Kubernetes — volumes, ingress, secrets, escalonamento automático.
• Desenvolvimento e CI/CD: ambientes efémeros em pipelines e k3d (k3s dentro de Docker) para desenvolvimento local que replica produção.

O k3s é um projeto sandbox da CNCF com dezenas de milhares de estrelas no GitHub — a adopção não é promessa, é facto. E quando um workload cresce para além do alvo do k3s, o mesmo ecossistema oferece o RKE2 (Rancher Kubernetes Engine 2): também da SUSE, com as mesmas ferramentas, mas desenhado para produção pesada e cumprimento de normas (CIS, FIPS). A transição é incremental, não uma migração traumática.

Começar com um comando

Numa máquina Linux:

curl -sfL https://get.k3s.io | sh -

Quando terminar, tem um cluster Kubernetes completo a correr. O kubectl já está instalado e configurado:

sudo k3s kubectl get nodes

Para juntar um segundo nó como agente, basta o mesmo comando com o token do servidor. Em cinco minutos familiariza-se com os conceitos; num dia tem serviços a correr com volumes persistentes e ingress.

Resumindo

O k3s é Kubernetes sem excessos: a mesma API, certificada pela CNCF, num único binário que corre desde um Raspberry Pi até clusters de produção com alta disponibilidade. Não é uma versão reduzida nem uma imitação — é o Kubernetes que sobra quando se retira o que a maioria das cargas reais não usa. Para sites, plataformas e aplicações de média dimensão, é o caminho mais directo entre precisar de orquestrar contentores e tê-los a funcionar. E quando o workload crescer, o RKE2 espera no mesmo ecossistema — sem se começar do zero.