VPS para Kubernetes: guia de cluster pequeno

Resposta direta

Sim, dá para rodar Kubernetes em VPS, principalmente para laboratório, staging, aplicações internas, automações e produção leve. A configuração mais comum é usar k3s em 1 a 3 nós, começando com 2 vCPUs, 4 GB de RAM e 40 GB de SSD ou NVMe por nó. Para algo mais estável, 3 VPS com 2 vCPUs e 4 GB de RAM cada permitem distribuir workloads e reduzir o impacto de falhas isoladas. Kubernetes em VPS exige atenção a rede, firewall, storage persistente, backups, atualizações e observabilidade. Ele não substitui automaticamente um serviço gerenciado como EKS, GKE ou AKS, mas pode ser uma boa escolha quando o time quer controle, previsibilidade e custo operacional menor, aceitando cuidar da administração do cluster.

Resumo rápido

Kubernetes em VPS funciona bem quando o objetivo é aprender, padronizar deploys, testar ambientes parecidos com produção ou hospedar workloads containerizados de pequeno e médio porte. O ponto crítico é não tratar uma VPS como se fosse uma plataforma gerenciada. Você será responsável por firewall, upgrades, certificados, storage, backup e recuperação. Para quem já usa Docker em produção, a curva de aprendizado é menor, e o guia de VPS para Docker ajuda a revisar a base antes de avançar para orquestração.

• Para laboratório, uma VPS com 2 vCPUs, 4 GB de RAM e 40 GB de disco já permite rodar k3s, Ingress Controller e alguns serviços leves.
• Para staging, 3 nós com 2 vCPUs e 4 GB de RAM cada entregam isolamento melhor e testes mais realistas.
• Para produção leve, considere 3 nós, backups externos, monitoramento, firewall restritivo e estratégia clara de upgrade.
• k3s costuma ser mais adequado que kubeadm para VPS pequenas, porque reduz consumo de recursos e simplifica a instalação.
• Disco NVMe ajuda em workloads com banco local, filas, logs e imagens frequentes, mas não corrige arquitetura ruim.
• Datacenter no Brasil pode reduzir latência para usuários brasileiros, desde que rede e DNS também estejam bem configurados.
• Preços, regiões, bandwidth e recursos de provedores mudam com frequência e precisam de revisão humana antes da publicação.

A melhor decisão depende do uso. Um cluster para testar Helm charts não precisa da mesma estrutura de um SaaS com clientes pagantes. Do mesmo modo, um ambiente que roda n8n, APIs internas e filas pequenas exige menos do que um e-commerce com picos de tráfego e banco transacional sensível.

Quando faz sentido rodar Kubernetes em VPS

Rodar Kubernetes em VPS faz sentido quando você precisa de mais controle do que uma hospedagem compartilhada oferece, mas ainda não quer assumir o custo e a complexidade de uma cloud gerenciada completa. O cenário aparece bastante em times que já empacotam aplicações em containers, usam GitHub Actions ou GitLab CI e querem um ambiente previsível para deploy contínuo. Em vez de manter scripts diferentes para cada servidor, o time passa a declarar Deployments, Services, Ingress e Secrets em manifests versionados.

Kubernetes pequeno não é Kubernetes simples

Um erro comum é pensar que um cluster pequeno exige pouca disciplina operacional. Na prática, ele apenas tem menos nós. Ainda será preciso cuidar de atualização do sistema operacional, runtime de containers, certificados, DNS, limites de CPU e memória, logs, backups e recuperação. Em um cluster de um nó, se a VPS cair, tudo para. Em um cluster de três nós, uma falha isolada pode ser absorvida, mas somente se os pods, volumes e serviços tiverem sido desenhados para isso.

Para um dev solo, Kubernetes em uma VPS pode ser excelente para aprender Ingress, Helm, namespaces e ConfigMaps sem depender de créditos de cloud pública. Para um time, o uso mais interessante costuma ser staging: simular deploys próximos da produção, validar migrações de banco, testar autoscaling horizontal em pequena escala e treinar rollback. Para produção, a conversa muda. Você precisa saber qual é o tempo aceitável de indisponibilidade, como restaurar volumes e quem recebe alertas às 3 da manhã.

VPS, Cloud Server e cloud instance no contexto de clusters

Também ajuda separar conceitos. Uma VPS tradicional é uma máquina virtual em um servidor físico, com recursos alocados pelo provedor. Um Cloud Server ou cloud instance geralmente oferece provisionamento mais rápido, API, snapshots, rede privada e upgrades mais flexíveis. Essa diferença importa para Kubernetes porque clusters dependem de recriação de nós, IPs previsíveis, storage e automação. Se você ainda está comparando os modelos, o artigo sobre VPS ou Cloud Server explica as diferenças de forma mais ampla.

Na prática, Kubernetes pode rodar nos dois modelos. O que muda é a operação. Se o provedor oferece rede privada entre instâncias, snapshots confiáveis, firewall por painel e console de emergência, a vida do operador fica mais simples. Se não oferece, você precisará compensar com configuração manual e documentação interna.

Arquiteturas recomendadas para clusters pequenos

A arquitetura define boa parte da experiência. Antes de instalar qualquer script, decida se o cluster será laboratório, staging ou produção leve. Essa escolha muda o número de nós, a distribuição de pods, a tolerância a falhas e a estratégia de storage. Kubernetes permite muitas combinações, mas em VPS pequenas o excesso de componentes vira custo em RAM, CPU e manutenção. O melhor desenho costuma ser o mais simples que atende ao risco do projeto.

Cluster de um nó com k3s

Para laboratório e projetos pessoais, um nó único com k3s é o caminho mais direto. Uma VPS com 2 vCPUs, 4 GB de RAM e 40 GB de SSD consegue rodar o control plane, CoreDNS, Traefik ou NGINX Ingress, cert-manager e algumas aplicações leves. Um exemplo realista seria hospedar uma API Node.js, um worker pequeno, Redis para cache e um painel administrativo. Ainda sobra pouco espaço para picos, então limites de recursos são obrigatórios.

Nesse modelo, use namespaces para separar ambientes. Por exemplo: dev, staging e tools. Configure requests e limits nos pods, como 250m de CPU e 256 MiB de RAM para serviços pequenos. Sem limites, um container com vazamento de memória pode derrubar o nó inteiro. O cluster de um nó não entrega alta disponibilidade, mas entrega repetibilidade, que já é útil para quem quer aprender manifests e deploys.

Três nós para staging e alta disponibilidade básica

Para staging sério, 3 VPS com 2 vCPUs e 4 GB de RAM cada formam uma base mais segura. Você pode usar k3s em modo server nos três nós, com datastore embutido, ou um nó server e dois agents se a tolerância a falha não for requisito. Em três nós, dá para distribuir pods com anti-affinity, testar rolling updates e validar como a aplicação se comporta quando um nó sai do ar.

Um exemplo de distribuição seria: nó 1 com control plane e workloads leves, nó 2 com APIs, nó 3 com workers e tarefas agendadas. Se você tiver banco de dados, pense duas vezes antes de colocá-lo dentro do cluster. Em muitos projetos pequenos, PostgreSQL ou MySQL fora do Kubernetes, mas na mesma região, reduz complexidade. Para staging, isso facilita reset de dados e restauração.

Separação entre control plane e workloads

Em produção leve, a separação entre control plane e workloads melhora previsibilidade, mas aumenta custo. Um desenho possível é 3 nós control plane pequenos e 2 nós worker, todos com rede privada. Só que, em VPS, isso pode sair exagerado para uma aplicação com 2 mil acessos por dia. Por isso, muita gente usa 3 nós mistos, todos participando do control plane e recebendo workloads, com cuidado para não sobrecarregar o etcd ou o datastore.

A decisão final deve considerar o custo de indisponibilidade. Se ficar 30 minutos fora do ar não causa perda relevante, um cluster simples com backup bom pode ser mais sensato do que uma arquitetura complexa mal operada. Kubernetes recompensa disciplina, não quantidade de nós.

Requisitos técnicos de CPU, RAM, disco e rede

Os requisitos de Kubernetes em VPS variam conforme distribuição, número de pods e componentes instalados. k3s é mais leve que uma instalação kubeadm tradicional porque empacota componentes e usa escolhas mais enxutas por padrão. Ainda assim, Kubernetes consome recursos antes mesmo da sua aplicação iniciar. CoreDNS, CNI, Ingress Controller, metrics-server, cert-manager e agentes de observabilidade ocupam CPU e memória. Em VPS pequenas, esse overhead precisa entrar na conta.

Configuração mínima realista

Para laboratório, considere 2 vCPUs, 4 GB de RAM e 40 GB de SSD por nó. Dá para instalar com menos, mas a experiência piora rápido quando entram imagens grandes, builds, logs ou múltiplos pods. Para staging, uma base mais confortável é 3 nós com 2 vCPUs, 4 GB de RAM e 60 GB de disco cada. Para produção leve, comece em 3 nós com 4 vCPUs, 8 GB de RAM e 80 GB de SSD ou NVMe quando houver APIs, workers e observabilidade no mesmo cluster.

Um exemplo prático: uma API em Go pode rodar com 128 MiB a 256 MiB de RAM por pod. Uma aplicação Laravel ou Node.js com filas pode precisar de 512 MiB a 1 GiB por pod. Some isso a Redis, Ingress, cert-manager e logs. Se o nó tem 4 GB de RAM, talvez apenas 2,5 GB estejam confortáveis para workloads depois do sistema e do cluster.

Disco e IOPS importam mais do que parecem

Disco não é só espaço. Kubernetes baixa imagens, grava logs, mantém dados de volumes locais e pode executar bancos pequenos. SSD ou NVMe reduz tempo de pull, inicialização de containers e escrita de logs. Em clusters com banco dentro do nó, IOPS e latência de disco afetam diretamente consultas e checkpoints. Mesmo assim, NVMe não resolve problemas de arquitetura, como banco sem backup, pod sem limite de memória ou volume preso em um único nó.

Use pelo menos 40 GB para laboratório e 80 GB para produção leve. Configure rotação de logs no container runtime e monitore uso de /var/lib/rancher, /var/lib/kubelet e diretórios de volumes. Um cluster que parecia saudável pode parar de agendar pods simplesmente porque o disco atingiu 90 por cento.

Rede, latência e portas necessárias

Kubernetes depende de comunicação entre nós. Em VPS, prefira rede privada quando disponível. Ela reduz exposição pública e costuma melhorar estabilidade entre nós da mesma região. Portas como 6443 para API Server, 10250 para kubelet e portas específicas do CNI não devem ficar abertas para a internet sem necessidade. Para acesso externo, concentre entrada em 80 e 443 via Ingress Controller.

Para público brasileiro, datacenter em São Paulo ou região próxima pode reduzir latência percebida. Se o provedor está nos Estados Unidos, a latência pode ser aceitável para painéis administrativos, mas menos interessante para APIs sensíveis. Teste com ping, mtr e medições de aplicação, não apenas com opinião.

Instalação prática com k3s e cuidados iniciais

k3s costuma ser a escolha mais prática para Kubernetes em VPS porque simplifica instalação e reduz dependências. Ele já inclui componentes essenciais e permite subir um cluster funcional em poucos minutos. Isso não significa instalar sem planejamento. Antes do primeiro comando, atualize o sistema, defina hostname, configure firewall, crie usuário administrativo e desative login SSH por senha. Esses passos parecem básicos, mas evitam boa parte dos incidentes em servidores expostos.

Preparando a VPS

Em uma VPS Ubuntu ou Debian, comece com atualização do sistema e pacotes essenciais. Um fluxo comum é executar apt update, apt upgrade, instalar curl, ufw, fail2ban e ajustar timezone para America/Sao_Paulo quando a equipe opera no Brasil. Crie um usuário sem root direto, adicione chave SSH e limite o acesso por IP quando possível. Se você já usa containers sem orquestração, o guia atualizado de VPS para Docker em 2026 ajuda a revisar boas práticas de base, como volumes, portas e logs.

No firewall, libere apenas o necessário. Para um nó único com Ingress público, normalmente entram 22, 80 e 443. A porta 6443 da API do Kubernetes deve ficar restrita ao IP do administrador ou VPN. Em clusters multinó, libere comunicação interna entre os IPs privados dos nós. Evite abrir portas de kubelet ou datastore para a internet.

Comando de instalação e kubeconfig

Uma instalação básica de k3s em nó único pode ser feita com curl -sfL https://get.k3s.io | sh -. Em produção, leia o script antes, fixe versão e registre o comando usado. Depois, valide com kubectl get nodes e kubectl get pods -A. O kubeconfig fica em /etc/rancher/k3s/k3s.yaml. Copie para sua máquina local com cuidado, ajuste o endereço do servidor e proteja o arquivo, porque ele concede acesso administrativo ao cluster.

Para adicionar workers, use o token do server e a URL da API interna. Um comando típico usa K3S_URL=https://IP_PRIVADO:6443 e K3S_TOKEN=TOKEN_DO_CLUSTER. Não publique tokens em repositórios, tickets ou prints. Se precisar compartilhar acesso, use RBAC com permissões menores em vez de entregar o kubeconfig de administrador.

Ingress, DNS e certificados

Depois do cluster no ar, configure Ingress e DNS. k3s pode vir com Traefik, mas alguns times preferem NGINX Ingress por familiaridade. Aponte o registro A do domínio para o IP público da VPS ou para um balanceador, se existir. Para HTTPS, cert-manager com Let’s Encrypt resolve a maior parte dos casos. Teste renovação automática e monitore certificados. Um certificado vencido pode parecer falha de aplicação, mas nasce de uma configuração esquecida.

Um exemplo simples: api.exemplo.com aponta para o Ingress, que roteia para um Service chamado api-service na porta 8080. O Deployment roda 2 réplicas, cada uma com limite de 500m de CPU e 512 MiB de RAM. Esse desenho já permite rolling update sem desligar todos os pods ao mesmo tempo.

Storage, backup e persistência em VPS

Storage é a parte em que muitos clusters pequenos quebram. Kubernetes facilita recriar pods, mas não recria dados perdidos. Em VPS, nem sempre você terá volumes gerenciados com attach e detach automático entre nós. Muitas instalações usam storage local, como local-path-provisioner no k3s. Ele é simples e funciona, mas prende o volume ao nó onde foi criado. Se esse nó falhar, o pod pode até ser reagendado em outro lugar, mas o dado não acompanha automaticamente.

Volumes locais e seus riscos

Volumes locais servem bem para laboratório, cache, uploads não críticos e ferramentas internas. Para banco transacional, exigem cautela. Imagine um PostgreSQL rodando em um volume local no nó 2. Se o nó 2 ficar indisponível, o Kubernetes não consegue mover magicamente o banco para o nó 3 com os mesmos dados. Será preciso restaurar backup ou ter replicação configurada fora do mecanismo básico de volume.

Para aplicações stateless, prefira manter estado fora do cluster: banco gerenciado, banco em VPS dedicada, object storage compatível com S3 para uploads e Redis configurado com persistência adequada quando necessário. Essa separação simplifica upgrades e recriação de nós. Se a aplicação grava arquivos no container, revise o design. Containers devem ser descartáveis.

Snapshots não substituem backup

Snapshots do provedor ajudam em recuperação rápida, mas não substituem backup lógico e testado. Snapshot pode capturar um banco em estado inconsistente se não houver flush ou coordenação. Para PostgreSQL, use pg_dump, pg_basebackup ou ferramenta especializada. Para MySQL, use mysqldump, mysqlpump ou backup físico conforme o tamanho. Guarde cópias fora da VPS e, idealmente, fora da mesma conta do provedor.

Uma rotina mínima para produção leve inclui backup diário, retenção de 7 a 14 dias, teste de restauração mensal e alerta em caso de falha. Parece burocrático até o primeiro incidente. O teste de restauração é o que separa backup real de arquivo decorativo.

Banco de dados dentro ou fora do cluster

Rodar banco dentro do Kubernetes em VPS é possível, mas aumenta a responsabilidade. Para ambientes pequenos, banco fora do cluster costuma ser mais previsível. Pode ser uma VPS separada com firewall restrito, backup próprio e acesso apenas pelos nós Kubernetes. Se você precisa de PostgreSQL altamente disponível, talvez seja hora de avaliar serviço gerenciado ou operador especializado, não apenas aumentar RAM.

Uma boa regra prática: coloque no cluster o que pode ser recriado por manifest. Trate dados persistentes como componente de infraestrutura, com plano de backup, restauração e migração documentado.

Comparativo de perfis e provedores para Kubernetes em VPS

Comparar VPS para Kubernetes exige cuidado. Preço isolado não mostra latência, qualidade de rede, política de snapshots, suporte, tipo de disco ou limite de transferência. Também não dá para afirmar que um provedor é mais rápido sem benchmark controlado, com metodologia, região, tamanho de instância e repetição dos testes. Por isso, a tabela abaixo foca em perfis técnicos e características públicas relevantes. Valores, regiões e recursos devem ser verificados nos sites oficiais antes de qualquer recomendação final.

Como ler a tabela sem cair em armadilhas

Um cluster Kubernetes pequeno valoriza previsibilidade. Rede privada entre nós ajuda mais do que 1 vCPU extra em vários cenários. Snapshots facilitam rollback de sistema, mas backup de aplicação continua obrigatório. Datacenter no Brasil pode ser ótimo para latência de usuários locais, mas talvez não seja necessário para jobs assíncronos, painéis internos ou APIs consumidas globalmente. O melhor provedor depende do workload e da equipe que vai operar.

Perfil ou provedor	Localidade relevante	Configuração inicial sugerida	Pontos úteis para Kubernetes	Atenções antes de publicar
LetsCloud	Brasil, com foco em São Paulo	3 nós de 2 vCPUs, 4 GB RAM e SSD ou NVMe	Pagamento em reais, suporte em português e baixa latência para público brasileiro quando a região se aplica	Confirmar planos, disco, bandwidth, snapshots e regiões no site oficial
Vultr Cloud Compute	Inclui São Paulo e regiões globais	3 nós de 2 vCPUs, 4 GB RAM e SSD	Boa cobertura de regiões, API e opções úteis para clusters pequenos	Confirmar disponibilidade de região, limites de rede e recursos atuais
DigitalOcean Droplets	EUA, Europa e outras regiões, sem foco principal no Brasil	3 nós de 2 vCPUs, 4 GB RAM e SSD	Documentação forte, painel simples, API e ecossistema amplo	Confirmar regiões, backups, volumes e custos atuais antes de comparar
Hetzner Cloud	Europa e EUA	3 nós de 2 vCPUs, 4 GB RAM e SSD ou NVMe conforme plano	Custo técnico competitivo para workloads tolerantes a latência internacional	Confirmar regiões, tráfego incluído e suporte esperado para operação brasileira

Dados de concorrentes coletados em 12/06/2026 a partir de fontes oficiais listadas no final. Como preço, bandwidth, promoções, storage e regiões são dados voláteis, qualquer comparação comercial precisa de revisão humana antes da publicação.

Dados voláteis e revisão humana

Para Kubernetes, evite escolher apenas pelo menor valor mensal. Um ambiente que parece econômico pode custar caro se não tiver snapshot prático, console de recuperação, rede privada ou documentação clara. Também observe limites de rebuild, política de abuso de rede e suporte a imagens customizadas. Clusters precisam de manutenção. Se a operação depende de API para criar nós, DNS automatizado e firewall via painel, confirme tudo antes de migrar.

Em workloads para brasileiros, LetsCloud entra no radar quando latência local, cobrança em reais e suporte em português pesam na decisão. DigitalOcean e Vultr costumam agradar times que priorizam documentação, API e ecossistema. Hetzner pode fazer sentido para workloads menos sensíveis a latência no Brasil. Nenhuma dessas escolhas é universal.

Segurança, observabilidade e operação diária

Depois que o cluster funciona, começa a parte menos glamourosa: manter tudo seguro e previsível. Kubernetes expõe uma superfície considerável. API Server, kubelet, Ingress, imagens de containers, Secrets e permissões RBAC precisam de configuração consciente. Em VPS, a responsabilidade é sua. O provedor entrega a máquina, mas não decide quem pode acessar o cluster, quais portas ficam abertas ou como suas imagens são atualizadas.

Firewall, SSH e acesso ao cluster

Use firewall no provedor e no sistema operacional quando possível. O painel do provedor bloqueia tráfego antes de chegar à VPS, enquanto ufw ou nftables dão uma camada local. Restrinja SSH por chave, desative senha e mantenha acesso root direto bloqueado. Para Kubernetes, limite a porta 6443 a IPs confiáveis ou VPN. Se a equipe cresce, crie usuários e permissões via RBAC. Não compartilhe o kubeconfig administrativo como atalho.

Secrets também merecem cuidado. Kubernetes armazena Secrets codificados em base64, não criptografados de forma mágica para qualquer cenário. Em ambientes sensíveis, avalie criptografia em repouso, Sealed Secrets, External Secrets ou integração com cofre externo. Para projetos pequenos, ao menos mantenha Secrets fora do Git e registre processo de rotação.

Monitoramento mínimo

Um cluster sem monitoramento só parece estável porque ninguém está olhando. O mínimo inclui métricas de CPU, RAM, disco, uso de pods, status dos nós, certificados e disponibilidade HTTP. metrics-server ajuda no básico, mas Prometheus e Grafana entregam visão melhor. Para logs, Loki, Vector ou coleta externa podem resolver. Em VPS pequenas, cuidado para a observabilidade não consumir mais recurso do que a aplicação.

Defina alertas simples: disco acima de 80 por cento, nó NotReady, pod em CrashLoopBackOff, certificado perto do vencimento e backup com falha. Esses alertas evitam surpresas comuns. Também registre runbooks curtos, como reiniciar um Deployment, drenar um nó, restaurar backup e renovar certificado.

Atualizações e janelas de manutenção

Atualize o sistema operacional e o Kubernetes com calendário. Não faça upgrade de cluster em sexta-feira à tarde sem plano de rollback. Em k3s, acompanhe versões suportadas e teste primeiro em staging. Antes de atualizar, tire snapshot da VPS quando fizer sentido, confirme backup da aplicação e leia notas da versão. Em clusters de três nós, atualize um nó por vez e valide kubectl get nodes e kubectl get pods -A a cada etapa.

Operação boa não precisa ser complexa. Precisa ser repetível. Um checklist de 15 minutos por semana pode evitar horas de incidente no mês seguinte.

Recomendações por perfil

Dev solo

Para dev solo, a melhor entrada é um cluster k3s de um nó com 2 vCPUs, 4 GB de RAM e 40 GB de SSD. Use para aprender Deployments, Services, Ingress, Helm, ConfigMaps e Secrets sem montar uma arquitetura cara. Rode aplicações stateless, ferramentas internas e bancos apenas quando os dados puderem ser recriados ou restaurados com facilidade. Configure firewall, SSH por chave e backup simples desde o primeiro dia. Se o objetivo é hospedar um portfólio, APIs pequenas ou automações, esse modelo entrega bastante controle com baixa complexidade. O limite aparece quando você precisa de alta disponibilidade real.

Time pequeno

Para um time pequeno, recomendo 3 nós com 2 vCPUs, 4 GB de RAM e 60 GB de disco cada, usando k3s. Esse desenho permite staging mais fiel, rolling updates, testes de falha e separação de workloads por namespace. Configure CI/CD para aplicar manifests, use registry privado e padronize Helm charts quando houver múltiplas aplicações. Banco de dados pode ficar fora do cluster, em VPS separada ou serviço gerenciado, para reduzir risco. Documente acesso, rotação de Secrets, backup e rollback. O ganho principal é previsibilidade: todos testam no mesmo modelo operacional, em vez de cada pessoa manter scripts manuais.

Produção leve

Para produção leve, comece com 3 nós de 4 vCPUs, 8 GB de RAM e 80 GB de SSD ou NVMe, desde que o orçamento permita. Use rede privada, firewall restritivo, backups externos, monitoramento, alertas e janelas de atualização. Evite colocar tudo no cluster sem critério. Banco, object storage e filas podem ficar fora se isso simplificar recuperação. Defina SLO simples, como disponibilidade esperada, tempo máximo de restauração e janela de manutenção. Se o sistema exige alta disponibilidade rigorosa, escalabilidade automática avançada ou equipe pequena demais para operar incidentes, avalie Kubernetes gerenciado em vez de VPS autoadministrada.