Como escolher VPS para K3s no Brasil

Resposta direta

Uma VPS para K3s no Brasil deve ter, como ponto de partida prático para produção pequena, 2 vCPUs, 4 GB de RAM, 40 a 80 GB de armazenamento SSD e uma distribuição Linux atualizada. Esse tamanho comporta o servidor K3s, os componentes básicos do cluster e algumas aplicações leves, mas não substitui uma medição real de consumo. Bancos de dados, observabilidade e pipelines de entrega podem elevar rapidamente a demanda.

Para alta disponibilidade, a arquitetura muda: use pelo menos três nós de servidor, preferencialmente com 4 vCPUs e 8 GB de RAM cada, rede privada entre eles e armazenamento de baixa latência. A localização brasileira pode reduzir o tempo de resposta para usuários locais, mas o resultado precisa ser confirmado com testes de RTT, perda de pacotes e rotas do provedor.

Resumo rápido

• Uma configuração inicial equilibrada usa 2 vCPUs, 4 GB de RAM e 40 a 80 GB de SSD.
• Produção com alta disponibilidade pede três nós de servidor, quantidade ímpar necessária ao quorum do etcd.
• K3s consome menos recursos que várias instalações Kubernetes tradicionais, mas as aplicações continuam definindo a maior parte da carga.
• O desempenho do etcd depende de latência de disco estável, não apenas da sigla SSD ou NVMe.
• Rede privada reduz a exposição do tráfego interno e simplifica regras de firewall entre os nós.
• Snapshots do etcd não substituem backups dos volumes persistentes usados pelas aplicações.
• Preço, banda, localização, armazenamento e recursos incluídos devem ser confirmados no site do provedor antes da contratação.

O que muda ao executar K3s em uma VPS brasileira

K3s é uma distribuição Kubernetes mantida pela SUSE e pelo projeto Rancher. Ela empacota componentes essenciais em uma instalação mais compacta, usa containerd como runtime padrão e automatiza boa parte da configuração inicial. Isso facilita a criação de clusters em VPS, edge computing, ambientes de desenvolvimento e pequenas plataformas internas. A redução de componentes, porém, não transforma Kubernetes em um serviço sem manutenção.

K3s reduz componentes, não a responsabilidade operacional

O servidor ainda precisa receber atualizações, ter firewall, monitoramento, backup e capacidade suficiente para os pods. K3s pode instalar componentes como CoreDNS, Traefik, ServiceLB e o provisionador local-path. Cada item ocupa memória e CPU. Em uma VPS com 2 GB de RAM, por exemplo, o sistema operacional, o processo do K3s e os pods de sistema deixam uma margem pequena para uma API, um banco e um controlador GitOps executados juntos.

Quem está comparando a distribuição com uma instalação mais convencional pode consultar o conteúdo sobre VPS para Kubernetes. A principal diferença prática está na simplicidade do bootstrap e no menor consumo do plano de controle, não na API usada pelas aplicações. Deployments, Services, Ingresses, Secrets e PersistentVolumeClaims continuam fazendo parte da rotina.

Nó único ou cluster distribuído

Um único servidor K3s atende laboratórios, homologação e aplicações que toleram uma janela de indisponibilidade. Nesse desenho, uma VPS de 2 vCPUs e 4 GB pode hospedar o plano de controle e os workloads. Se o servidor reiniciar, todos os serviços ficam indisponíveis durante a inicialização. O backup permite recuperar dados, mas não evita a parada.

Para produção com maior exigência, três servidores K3s com etcd embarcado formam um cluster com quorum. A perda de um dos três nós não impede o funcionamento do plano de controle, desde que os dois restantes estejam saudáveis. Um exemplo é distribuir três VPS em zonas ou hosts físicos diferentes dentro da mesma região. Colocar as três instâncias no mesmo hipervisor preserva o quorum lógico, mas não protege contra a falha desse equipamento.

Como dimensionar CPU, RAM e disco

O requisito mínimo publicado pelo projeto serve para instalar o K3s, não para prometer capacidade de produção. O dimensionamento deve somar o consumo do sistema operacional, dos componentes do cluster, das aplicações e de uma margem para picos. Reservar entre 20% e 30% da memória para variações é uma referência operacional mais segura do que ocupar toda a VPS desde o primeiro deploy.

Recursos para laboratório e produção pequena

Um laboratório com Nginx, uma API pequena e Redis pode começar com 2 vCPUs, 4 GB de RAM e 40 GB de SSD. O K3s e os pods de sistema podem consumir uma parcela relevante dessa memória, enquanto API e Redis dividem o restante. Configure requests e limits para impedir que um processo com vazamento de memória derrube os demais pods.

Em uma produção pequena, com duas APIs, worker de filas e monitoramento básico, 4 vCPUs, 8 GB de RAM e 80 GB de disco oferecem uma margem mais realista. Um exemplo de reserva seria 500 millicores e 512 MiB para cada API, 1 vCPU e 1 GiB para o worker, além dos recursos do plano de controle. Prometheus com retenção longa ou Loki recebendo muitos logs pode exigir outro nó ou volume maior.

resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    cpu: 1000m
    memory: 768Mi

Quando aumentar CPU ou memória

CPU adicional ajuda em compilações, criptografia, compressão, picos de requisições e muitos pods iniciando ao mesmo tempo. Memória ganha prioridade quando o cluster executa Java, bancos, caches, observabilidade ou vários controladores. Se a VPS usa swap constantemente, o problema não deve ser tratado apenas aumentando o limite dos pods. Verifique o working set de cada contêiner, o page cache e processos externos ao Kubernetes.

Disco também entra na conta. Imagens de contêiner antigas, logs e volumes locais podem preencher uma unidade de 40 GB rapidamente. Um cluster que armazena imagens de 800 MB e mantém dez versões de cinco serviços pode consumir dezenas de gigabytes só no cache. Para entender a camada de runtime antes de adicionar orquestração, o guia sobre VPS para Docker ajuda a separar consumo de contêiner, imagem e volume.

Comparação de configurações para K3s

Não existe um plano universal para K3s. A tabela abaixo compara perfis de infraestrutura, e não ofertas comerciais. Os números são pontos de partida editoriais. Eles precisam ser ajustados após testes de carga, métricas de produção e análise do tamanho real dos volumes.

Perfil	Topologia	Recursos por nó	Disco sugerido	Carga indicativa	Principal limitação
Laboratório	1 servidor	2 vCPUs e 2 a 4 GB de RAM	40 GB SSD	Testes, estudo e poucos pods	Qualquer reinício interrompe todo o ambiente
Produção pequena	1 servidor	4 vCPUs e 8 GB de RAM	80 a 160 GB SSD ou NVMe	APIs, workers e serviços internos	Plano de controle e aplicações compartilham a mesma falha
Alta disponibilidade	3 servidores	4 vCPUs e 8 GB de RAM	80 GB ou mais, com baixa latência	Aplicações críticas de pequeno e médio porte	Custo e operação distribuída aumentam
Cluster com workers	3 servidores e 2 ou mais agentes	Servidores com 4 vCPUs e 8 GB, agentes conforme carga	Disco separado por função	Múltiplas equipes e workloads variados	Rede, storage e observabilidade ficam mais complexos

Como interpretar os perfis da tabela

Uma loja pequena com API, painel administrativo e worker pode usar o perfil de produção pequena se aceitar indisponibilidade durante manutenção. Já um SaaS que recebe requisições continuamente pode separar três servidores de controle e dois agentes com 4 vCPUs e 8 GB. Assim, os pods de aplicação não disputam todos os recursos com o etcd e a API do Kubernetes.

Outro exemplo é um ambiente de integração contínua. Runners que compilam imagens geram picos intensos de CPU, disco e rede. Nesse caso, adicionar agentes de 8 vCPUs pode funcionar melhor do que ampliar apenas os servidores do plano de controle. Taints e tolerations mantêm os jobs de build fora dos nós responsáveis pelo etcd.

Capacidade anunciada não equivale a desempenho garantido

Duas VPS com 4 vCPUs e 8 GB podem entregar resultados diferentes. A geração do processador, o nível de compartilhamento da CPU, a política de IOPS, a latência do storage e o limite de banda influenciam o cluster. A sigla NVMe, isoladamente, não prova baixa latência sustentada. Testes devem medir p95 e p99, além da média.

Antes de contratar, confirme se a CPU é compartilhada ou dedicada, qual é a franquia de transferência, se existe rede privada e como snapshots são cobrados. Informações de plano, localidade e armazenamento são variáveis. Qualquer comparação de preço precisa de revisão humana e consulta às páginas oficiais na data da publicação.

Rede, latência e datacenter no Brasil

A escolha de uma região brasileira pode reduzir a distância de rede até usuários, APIs externas e escritórios locais. Isso não garante automaticamente a melhor rota. Uma aplicação atendida por operadoras diferentes pode registrar 10 ms para um usuário e mais de 50 ms para outro, mesmo dentro do país. Execute testes a partir das redes que representam o público real e registre RTT, jitter, perda de pacotes e tempo de conexão TLS.

Portas e comunicação entre os nós

A API do Kubernetes usa normalmente TCP 6443. Em clusters com Flannel no modo VXLAN, os nós também precisam se comunicar pela porta UDP 8472. Essa porta não deve ficar aberta para toda a internet. O kubelet usa TCP 10250, enquanto o etcd utiliza TCP 2379 e 2380 entre servidores. As regras exatas dependem da topologia e do backend de rede escolhido.

Um desenho comum coloca SSH e a API atrás de uma lista de IPs autorizados, mantém o tráfego entre nós em uma rede privada e publica somente HTTP e HTTPS. Por exemplo, o firewall pode liberar TCP 80 e 443 ao público, TCP 6443 apenas para a rede administrativa e portas internas apenas no bloco privado 10.20.0.0/24.

Evite criar o cluster usando endereços públicos quando o provedor oferece uma rede privada estável. O IP anunciado por cada nó deve ser alcançável pelos demais. Também teste a MTU. Encapsulamento VXLAN sobre uma rede com MTU incompatível pode causar falhas difíceis de perceber, como downloads interrompidos e conexões que funcionam apenas com pacotes pequenos.

Exposição de aplicações e balanceamento

Em um nó único, Traefik e ServiceLB podem publicar aplicações diretamente nos endereços da VPS. Em múltiplos nós, um balanceador externo ou uma solução compatível com o ambiente simplifica a distribuição de tráfego. O endpoint da API também precisa de um endereço estável para que agentes continuem se registrando quando um servidor falhar.

Um caso prático usa DNS apontando para um balanceador TCP, que encaminha a porta 6443 aos três servidores. Para aplicações, outro listener recebe 443 e encaminha aos nós aptos a executar o Ingress Controller. Se o projeto adota entrega declarativa, o artigo sobre Cloud Server para Argo CD e GitOps em produção explica como separar acesso administrativo, reconciliação e credenciais do pipeline.

Armazenamento persistente, etcd e backups

O armazenamento do K3s tem duas funções distintas. A primeira sustenta o estado do cluster, mantido em SQLite no cenário simples ou no etcd e em bancos externos nas topologias compatíveis. A segunda guarda os dados das aplicações, como uploads, índices, filas e bancos. Fazer snapshot do primeiro grupo não cria uma cópia automática do segundo.

O impacto do disco no plano de controle

O etcd executa operações sensíveis à latência de gravação e sincronização. Um disco que entrega alta taxa sequencial, mas apresenta pausas longas em fsync, pode provocar eleições, timeouts e lentidão na API. Por isso, medir somente megabytes por segundo não basta. Ferramentas como fio ajudam a observar latência de escrita aleatória, desde que o teste seja feito com limites para não afetar um ambiente em produção.

Para um cluster pequeno, 80 GB por servidor costuma oferecer espaço para sistema, imagens e dados do plano de controle, mas não é uma regra de capacidade. Se cada nó acumula logs por semanas ou recebe imagens grandes, 160 GB pode ser uma escolha mais segura. Configure rotação de logs e coleta de imagens não utilizadas. Disco cheio pode impedir novos pods e comprometer serviços do nó.

Em alta disponibilidade com etcd embarcado, use três servidores com desempenho de storage semelhante. Um nó muito mais lento pode prejudicar o tempo de confirmação das operações. Espalhar os servidores entre regiões distantes também aumenta a latência do consenso. Para resiliência local, zonas próximas e redes privadas de baixa latência tendem a ser mais adequadas.

Volumes de aplicações e restauração

O provisionador local-path é simples, mas vincula o volume ao nó. Se um pod de banco for recriado em outra VPS, os dados locais não aparecem magicamente no novo servidor. Aplicações stateful podem exigir block storage do provedor, NFS administrado, replicação no nível do banco ou uma camada distribuída, como Longhorn, desde que haja recursos e discos adequados.

Um plano de backup funcional combina snapshots periódicos do datastore, cópias externas dos volumes e teste de restauração. Por exemplo, gere snapshots do etcd a cada seis horas, mantenha retenção diária e envie uma cópia para armazenamento fora do cluster. Para PostgreSQL, faça também backup lógico ou físico consistente. Restaure mensalmente em um ambiente isolado e registre o tempo necessário. Um backup nunca testado é apenas uma hipótese de recuperação.

Segurança e operação contínua do cluster

A instalação rápida do K3s não elimina o hardening do sistema. Comece com uma imagem Linux suportada, atualize os pacotes, crie um usuário administrativo sem login direto como root e use chaves SSH. Desative autenticação por senha depois de validar o acesso alternativo. O firewall deve seguir o princípio de menor exposição, liberando somente as portas exigidas pela topologia.

Hardening inicial da VPS

O token usado para registrar servidores e agentes concede acesso sensível ao cluster. Armazene-o em um cofre de segredos ou mecanismo equivalente, nunca em repositório Git, script público ou imagem de máquina. O arquivo kubeconfig também precisa de proteção, pois normalmente contém credenciais administrativas.

Um exemplo seguro limita SSH ao IP da VPN corporativa, permite 6443 apenas ao bastion ou balanceador e restringe as portas de overlay à rede privada. Em vez de compartilhar um único kubeconfig, crie identidades e permissões RBAC por função. Um desenvolvedor que só consulta logs de um namespace não precisa administrar nós ou Secrets de toda a plataforma.

Ative criptografia de Secrets em repouso quando o modelo de risco exigir e confirme como as chaves serão protegidas. A criptografia do datastore não resolve exposição por RBAC permissivo. Revise ServiceAccounts, ClusterRoles e bindings. Imagens devem usar tags imutáveis ou digests, executar sem root quando possível e declarar filesystem somente leitura para processos compatíveis.

Atualizações, observabilidade e limites

Planeje upgrades em etapas. Em um cluster de três servidores, atualize um nó, verifique a saúde do etcd e da API, depois prossiga. Saltar versões sem consultar a documentação pode introduzir incompatibilidades. Tire snapshot antes da manutenção e confirme que a cópia está acessível fora do nó atualizado.

Monitore uso de CPU, working set de memória, pressão de disco, reinicializações, latência da API e saúde do datastore. Um exemplo de alerta útil dispara quando o disco passa de 80%, quando um pod reinicia repetidamente ou quando um nó permanece NotReady por mais de cinco minutos. Para logs, imponha retenção. Uma aplicação gravando 2 GB por dia consome 60 GB em um mês, sem contar índices e réplicas.

PodDisruptionBudgets, probes e réplicas ajudam durante manutenção, mas não corrigem uma aplicação sem tolerância a falhas. Uma API com duas réplicas ainda pode parar se ambas dependerem do mesmo banco local. Segurança e disponibilidade precisam considerar a cadeia inteira, não apenas o scheduler.

Instalação prática e solução de gargalos

Antes da instalação, configure hostname, DNS, horário, firewall e rede privada. Registre os endereços de cada nó e confirme conectividade. Para um servidor único de laboratório, a instalação oficial pode ser iniciada com o script do projeto. Em produção, revise o conteúdo do instalador, fixe uma versão testada e armazene a configuração de forma reproduzível.

Exemplo de instalação inicial

O comando abaixo ilustra a instalação de um servidor simples. Ele não contém tokens ou chaves. O acesso remoto à API deve ser configurado de acordo com firewall, certificados e rede administrativa.

curl -sfL https://get.k3s.io | \
  INSTALL_K3S_VERSION="v1.31.5+k3s1" \
  sh -s - server \
  --write-kubeconfig-mode 600 \
  --secrets-encryption

A versão é apenas um exemplo e precisa ser confirmada como suportada antes do uso. Fixar a versão evita que novas máquinas instalem uma release diferente sem validação. Depois, verifique os nós, pods de sistema e eventos:

sudo k3s kubectl get nodes -o wide
sudo k3s kubectl get pods -A
sudo k3s kubectl get events -A --sort-by=.lastTimestamp

Em alta disponibilidade, não copie comandos com tokens diretamente para histórico compartilhado. Use um processo seguro de distribuição e configure o endereço fixo de registro. Valide o quorum antes de mover aplicações.

Diagnóstico de CPU, memória e rede

Se pods ficam em Pending, execute kubectl describe pod e confira requests, taints, afinidade e volumes. Se aparecem como OOMKilled, compare o limite de memória com o consumo real. Aumentar o limite pode aliviar o sintoma, mas um vazamento precisa ser corrigido na aplicação.

Quando a API responde lentamente, observe CPU steal, iowait, latência de disco e saúde do datastore. CPU steal alta sugere disputa no host físico. Iowait elevado pode indicar storage saturado. Se a comunicação entre pods falha apenas em determinados tamanhos de pacote, teste MTU e encapsulamento.

Outro problema comum é falta de espaço em /var/lib/rancher/k3s. Liste imagens, volumes e logs antes de apagar arquivos manualmente. Configure rotação e políticas de limpeza. Em um ambiente GitOps, suspenda temporariamente reconciliações agressivas durante o diagnóstico para evitar que o controlador recrie recursos enquanto a equipe investiga a causa.

Recomendações por perfil

A configuração certa depende mais da tolerância a falhas e do tipo de aplicação do que da quantidade inicial de pods. Dez microsserviços quase ociosos podem consumir menos que um único banco sob escrita intensa. Use os perfis abaixo como início do planejamento e valide tudo com métricas.

Desenvolvedor solo e laboratório

Para estudo, desenvolvimento e demonstrações, uma VPS com 2 vCPUs, 4 GB de RAM e 40 GB de SSD é uma escolha equilibrada. Um nó único reduz custo e complexidade. Instale poucas ferramentas de observabilidade, limite a retenção de logs e evite executar bancos pesados junto com builds de imagens.

Se o ambiente puder ser recriado, mantenha manifests em Git e dados de teste fora da VPS. Faça snapshot antes de upgrades, mas não trate o snapshot como estratégia completa de backup. Esse perfil aceita interrupções durante reinicializações e não precisa simular alta disponibilidade apenas para executar dois ou três serviços.

Time pequeno com aplicações internas

Um time que mantém APIs internas, automações e ambientes de homologação pode começar com 4 vCPUs, 8 GB de RAM e 80 a 160 GB de disco. Se builds ou jobs disputarem CPU, adicione um agente separado em vez de inflar o nó de controle. Requests e limits devem ser obrigatórios nos namespaces compartilhados.

Use rede privada, RBAC por equipe, backup externo e monitoramento de disco. Uma janela mensal de manutenção pode ser aceitável, desde que o negócio conheça o impacto. Se a aplicação depende de PostgreSQL, considere um banco gerenciado ou uma instância separada. Isolar o banco reduz a concorrência de I/O com o K3s e simplifica algumas rotinas de recuperação.

Produção com alta disponibilidade

Para serviços que não podem depender de uma única VPS, use três servidores K3s com pelo menos 4 vCPUs e 8 GB de RAM por nó, além de dois ou mais agentes dimensionados para as aplicações. Prefira rede privada, endereço estável para a API e distribuição entre zonas ou hosts físicos quando o provedor documentar essa possibilidade.

Separe os workloads do plano de controle com taints quando houver carga significativa. Mantenha snapshots do etcd fora do cluster, backups consistentes dos volumes e ensaios de restauração. Antes de escolher o provedor, confirme região brasileira, CPU compartilhada ou dedicada, limites de banda, política de IOPS, rede privada e opções de recuperação. A decisão final deve considerar suporte operacional e arquitetura, não apenas a quantidade anunciada de vCPUs.