Resposta rápida
Rancher, RKE e kubeadm são ótimos pra montar cluster próprio — até o dia em que o etcd corrompe às 2h da manhã e ninguém no time sabe restaurar. Migrar pra Kubernetes gerenciado faz sentido quando: a operação do control plane consome mais de 10-15h/mês do time, upgrades de versão vivem atrasados por medo de quebrar, ou o único engineer que domina o cluster virou ponto único de falha. A migração é mais simples do que parece — manifestos e Helm charts são portáveis — e o roteiro completo está neste guia.
Tem um padrão que se repete em software house brasileira: alguém do time montou um cluster com Rancher ou kubeadm em 2022, funcionou, o produto cresceu em cima — e hoje ninguém tem coragem de fazer upgrade. O cluster roda uma versão de K8s com 3 anos de atraso, o backup do etcd nunca foi testado, e a pessoa que montou tudo saiu da empresa. Se isso soa familiar, este guia é pra você.
O custo invisível do self-hosted
Rodar o control plane por conta própria significa ser responsável por:
- etcd em alta disponibilidade: 3 ou 5 nós, snapshots recorrentes, teste de restore. Se o etcd morre sem backup válido, o cluster inteiro é reconstruído do zero
- Upgrades de versão: K8s lança 3 versões por ano e mantém suporte só nas últimas 3. Ficar pra trás significa CVEs abertas e incompatibilidade progressiva de charts
- Certificados internos: quem já teve cluster parado porque o certificado do api-server expirou num sábado sabe o tamanho da dor
- Monitoramento do próprio control plane: quem monitora o monitor?
- Hardware/VM por baixo: disco cheio no nó do etcd derruba o cluster inteiro
Somando, um cluster self-hosted sério consome 10-20 horas mensais de engenharia só de operação — sem contar incidente. A conta que ninguém faz: 15h/mês de um pleno a R$ 12 mil custam R$ 1.100/mês só de manutenção invisível.
Rancher especificamente: o que considerar em 2026
O Rancher segue sendo excelente ferramenta de gestão multi-cluster. Os pontos de atenção práticos:
- RKE1 foi descontinuado — quem ainda roda RKE1 precisa migrar de qualquer forma (pra RKE2 ou pra outro caminho)
- O Rancher em si é mais uma peça pra operar, atualizar e proteger — o painel que gerencia o cluster também precisa de HA
- Pra quem usa Rancher só como interface de UM cluster, o overhead raramente compensa
Ponto importante: migrar pra gerenciado não significa abandonar o Rancher. Você pode manter o Rancher como painel de gestão e importar o cluster gerenciado nele — os workloads rodam no cluster gerenciado, o Rancher vira só interface.
Quando NÃO migrar (honestidade primeiro)
- Time tem SRE dedicado que domina etcd, upgrades e disaster recovery — e esse conhecimento está documentado, não na cabeça de uma pessoa
- Requisito regulatório exige control plane sob custódia própria
- Cluster gigante (50+ nodes) onde o custo de gerenciado escala mais que o custo do time
Fora esses três cenários, a conta costuma fechar a favor do gerenciado.
Roteiro de migração: self-hosted → gerenciado em 6 passos
- Inventário (semana 1):
kubectl get all -A+ export de todos os manifestos e values de Helm. Mapear o que é stateless (fácil) e stateful (atenção) - Cluster gerenciado provisionado (dias): você recebe o kubeconfig do cluster novo com control plane, ingress, CNI Calico e storage NVMe prontos
- Deploy do stateless (semana 2): aplicar manifestos no cluster novo. Ajustes típicos: storage class nos PVCs e annotations de load balancer — mudanças de poucas linhas
- Migração do stateful (semana 2-3): pra banco dentro do cluster, avaliar se não é a hora de mover pra DBaaS gerenciado fora do cluster (menos operação); pra volumes de arquivo, rsync/restic entre os ambientes
- Validação em paralelo (semana 3): os dois clusters rodando, tráfego de teste no novo, monitoramento comparado
- Corte de DNS (semana 4): TTL baixo, janela combinada, rollback plan documentado. Cluster antigo fica 2 semanas de standby antes de desligar
O que muda no dia a dia depois da migração
| Tarefa | Self-hosted | Gerenciado |
|---|---|---|
| Upgrade de versão K8s | Seu time, com medo | Janela agendada, gerenciado |
| Backup do etcd | Seu script, torça pra funcionar | Responsabilidade do provedor |
| Certificados internos | Renovação manual/cron | Gerenciado |
| Deploy de aplicação | kubectl/Helm — igual | kubectl/Helm — igual |
| RBAC e namespaces | Você configura — igual | Você configura — igual |
Repare: o que muda é a operação da fundação, não o seu fluxo de trabalho. Deploy continua sendo helm upgrade.
FAQ
Perco acesso root aos worker nodes no gerenciado?
Na prática o dia a dia inteiro acontece via API Kubernetes — kubectl, Helm, operators. A divisão de responsabilidade é clara: control plane é do provedor, workloads são seus, com RBAC próprio por time e namespace.
Meu CI/CD (GitLab CI, ArgoCD, Flux) continua funcionando?
Sim. Pipelines que falam com a API do K8s só precisam do kubeconfig novo. GitOps com ArgoCD/Flux migra apontando o cluster de destino — os manifestos no Git continuam a fonte da verdade.
Quanto tempo leva a migração completa?
Cluster típico de software house (10-30 serviços, 1-3 bancos): 3-5 semanas com validação em paralelo. Migração assistida por engineer da Audaks encurta isso — já fizemos o caminho e conhecemos as pegadinhas.
E os dados nos PersistentVolumes?
Volumes stateless (cache, tmp) não migram — recriam. Dados reais migram via restic/rsync com o serviço pausado brevemente, ou com réplica lógica no caso de bancos (zero downtime). O plano exato depende do tamanho e da janela aceitável.
Próximos passos
- Kubernetes gerenciado: quando faz sentido pra empresa B2B
- K8s gerenciado vs EKS/GKE/AKS: custo real em Real
- Kubernetes Gerenciado Audaks
Seu cluster self-hosted virou passivo?
Diagnóstico gratuito em 24h: avaliamos seu cluster atual (versão, etcd, riscos), estimamos o esforço real de migração e propomos o roteiro com migração assistida.
Falar com especialista →