VPS para Kubernetes e k3s

Um Kubernetes em servidores virtuais alugados é montado por dois motivos: o cluster gerenciado de um provedor de nuvem sai mais caro, e para estudo, um laboratório em casa ou uma produção pequena dá vontade de ter controle total sobre versões e configurações. Mas um cluster não é um servidor só, e sim vários nós com papéis diferentes, e economizar em um deles costuma quebrar o cluster inteiro. A tabela acima reúne planos em KVM a partir de 2 núcleos e 4 GB de memória, de provedores com API, para que os nós possam ser criados por script ou pelo Terraform.

k3s ou kubeadm

O k3s é uma distribuição enxuta num único binário. Pela documentação, um nó servidor se vira com 2 núcleos e 2 GB de memória, e um agente, com um núcleo e 512 MB. Em vez do etcd, por padrão usa-se o SQLite, e para tolerância a falhas dá para ativar o etcd embutido em três nós servidores. A rede Flannel, o ingress Traefik e o armazenamento local já vêm instalados. É a melhor escolha para um a três VPS, ambientes de teste e projetos pequenos.

O kubeadm instala o Kubernetes «puro»: componentes separados do control plane, etcd e o plugin de rede de sua escolha (Calico, Cilium). Os requisitos mínimos são os mesmos 2 núcleos e 2 GB por máquina, mas, na prática, um control plane com etcd funciona tranquilo a partir de 4 GB. O kubeadm é escolhido quando se precisa de compatibilidade total com produção, para preparação para a certificação CKA ou para entender como o cluster funciona por dentro. Atualizá-lo leva mais tempo: as versões sobem uma minor por vez.

Quantos nós e de que tipo

• Um nó — k3s num VPS com 4 GB de memória, em que o control plane e a carga convivem. Serve para projetos pessoais e ambientes de teste.
• Um master e 2–3 workers — o esquema clássico para estudo e serviços pequenos. O master com 2–4 GB, os workers conforme a carga real, normalmente 4–8 GB.
• Três nós de control plane — o mínimo para o quórum do etcd: o cluster sobrevive à perda de um nó. Dois masters são piores que um, porque, se qualquer um cair, não há quórum.

Calcule a memória com folga: kubelet, container runtime, CNI, CoreDNS e os agentes de monitoramento consomem 0,5–1 GB em cada nó antes mesmo dos seus pods. O Kubernetes despeja pods quando falta memória, por isso defina requests e limits. O kubeadm, por padrão, exige desativar o swap.

etcd e disco

O etcd grava cada mudança de estado do cluster com descarga síncrona no disco, e um fsync lento é causa frequente de uma API «que cai» e de novas eleições de líder. Para o control plane, escolha um VPS com NVMe, e não HDD nem planos baratos com limite rígido de IOPS. Dá para testar o disco com o utilitário fio com fdatasync: latência de alguns milissegundos é normal; dezenas são motivo para trocar de plano. Faça snapshots do etcd com regularidade e guarde-os fora do cluster.

Virtualização, rede, volumes e balanceamento

O Kubernetes precisa de kernel próprio, dos módulos overlay e br_netfilter, de cgroups e de iptables ou eBPF. Em virtualização por contêineres, OpenVZ e LXC, isso quase nunca funciona, por isso é preciso um VPS com KVM — os mesmos requisitos do Docker, só que mais rígidos. A virtualização aninhada (flag vmx ou svm em /proc/cpuinfo) só será necessária se você rodar máquinas virtuais dentro do cluster pelo KubeVirt ou pelo Kata Containers; para contêineres comuns ela não é necessária, e nem todos os provedores a ativam.

É melhor manter os nós no mesmo data center: entre eles circula o tráfego da rede overlay e do etcd, e uma latência de dezenas de milissegundos deixa o cluster visivelmente mais lento. Se o provedor oferece rede privada entre os VPS, passe o tráfego interno do cluster por ela. Para fora, abra só a API na 6443/TCP (de preferência com lista de IPs permitidos) e as portas do ingress; a porta VXLAN 8472/UDP e a do kubelet 10250 devem ficar fechadas para a internet.

Clusters gerenciados fornecem sozinhos volumes e balanceadores externos, mas em VPS crus esses serviços não existem, e um serviço do tipo LoadBalancer vai ficar para sempre com status Pending. Para o tráfego de entrada, normalmente basta um ingress controller nas portas 80 e 443 de um ou mais nós; o k3s inclui para isso o ServiceLB embutido, e num cluster kubeadm instala-se o MetalLB, se o provedor permitir obter IPs adicionais. Para volumes, o mais simples é começar com o local-path — os dados ficam no disco de um nó específico e somem junto com ele. Se o pod precisar mudar de nó junto com os dados, instala-se um armazenamento distribuído como o Longhorn, que replica os volumes entre os nós; reserve para ele espaço próprio no disco de cada worker e mais 0,5–1 GB de memória.

Cluster próprio ou gerenciado

Um Kubernetes gerenciado tira das suas mãos o control plane, as atualizações e o etcd, e você paga basicamente pelos workers e balanceadores. Um cluster próprio em VPS é mais barato e flexível, mas backups do etcd, atualizações, certificados e monitoramento viram trabalho seu. Um meio-termo razoável para começar é o k3s em alguns VPS com cobrança por hora: dá para recriar nós, testar esquemas diferentes e remover o que sobra sem pagar o mês inteiro.