Kubernetes é uma plataforma de código aberto que gerencia contêineres: reinicia os que falham, distribui o tráfego e troca de versão em ritmo controlado. Em troca, alguém precisa operar o cluster. Três plataformas que construímos do zero rodam no Cloud Run, sem Kubernetes, e dois clientes com muitos serviços precisam dele. O que separa os casos é quantos serviços e quantos times existem por trás.
O que é Kubernetes, nas palavras do projeto?
A documentação oficial o define como uma plataforma portátil, extensível e de código aberto para gerenciar cargas de trabalho e serviços em contêineres, com configuração declarativa e automação. O Google abriu o código em 2014. O projeto entrou na CNCF em março de 2016 e chegou ao nível Graduated em 6 de março de 2018.
Do que ele oferece, o que mais pesa no dia a dia é isto. Deploys e rollbacks automáticos, em ritmo controlado. Autocorreção: ele reinicia o contêiner que falha ou que não responde a uma checagem de saúde. Encaixe automático dos contêineres nos nós (as máquinas do cluster) conforme a CPU e a memória que você declara. E balanceamento de carga, descoberta de serviços e gestão de segredos sem reconstruir imagem.
A mesma página diz o que ele não faz. Não é um PaaS completo, não constrói a sua aplicação e não decide o seu CI/CD. Você continua precisando de um pipeline, e essa parte é DevOps. Como usamos nós, com Argo CD, está na página de Kubernetes e Argo CD.
Quanto custa operar?
Alguém precisa ser o dono do cluster. Numa plataforma SaaS de análise de portfólios em AWS EKS (o Kubernetes gerenciado da Amazon), tivemos que corrigir comportamentos do próprio cluster. A consolidação de nós recriava o armazenamento de logs umas três vezes por dia. O autoscaling derrubava de uma vez a maior parte dos pods de relatórios, que são os contêineres em execução. E os jobs longos de relatórios precisavam de um encerramento ordenado.
Essas correções fazem parte do preço do Kubernetes. Se você não tem quem as assuma, o custo vem do mesmo jeito, só que sem dono.
E se eu não usar?
Três plataformas nossas rodam no Cloud Run, o serviço de contêineres gerenciado do Google Cloud.
Uma plataforma de publicidade com IA que construímos para um cliente tem um serviço no Cloud Run, 9 jobs e 18 tarefas agendadas atrás de um load balancer global com Cloud Armor. O banco fica no Cloud SQL em IP privado. Uma tag de versão constrói 3 imagens, migra o banco e publica por digest, a impressão digital da imagem. Foram 89 releases em 10 dias, da v1.0.0 à v1.61.0. Num portal govtech, cada versão sobe sem tráfego, a migração roda como job, a saúde é verificada e só então a revisão recebe usuários. E numa plataforma PropTech de primeira moradia, as versões vão para o Cloud Run por tag, atrás de um plano do Terraform que trava mudanças destrutivas.
Não estou dizendo que o Cloud Run é melhor. Nos três casos há um produto e um time, não uma frota de serviços mantida por vários times. O que você perde é o que o Kubernetes acrescenta: controle sobre como os contêineres se distribuem pelos nós e a portabilidade que a própria definição destaca.
Quando ele faz falta?
Quando o problema deixa de ser o contêiner e vira o número de times e de serviços. Uma empresa norte-americana de serviços de transporte roda mais de 150 repositórios ativos em Kubernetes multicluster, numa nuvem de grande porte. Nessa plataforma, onde nosso time trabalha desde dezembro de 2025, o Argo CD passou de 46 para 101 aplicações. Ali é preciso um jeito comum de publicar em todos os clusters, e Kubernetes com GitOps (o Git como fonte do que deve estar rodando) entrega isso.
Minha regra é uma pergunta: você consegue nomear o problema de contêineres que a sua plataforma atual não resolve? Se não, ainda não precisa. Se sim, conte dois números antes de decidir: quantos serviços são publicados separadamente e quantos times os publicam. Com um serviço e um time, comece por uma plataforma gerenciada.
Se você já está no Kubernetes ou vai estar, o pacote de CI/CD e IaC constrói ou refaz seus pipelines e sua infraestrutura como código por US$ 4.000, em 2 semanas. A consultoria de Kubernetes e Argo CD detalha como trabalhamos. Um engenheiro sênior de plataforma sai por US$ 45 a 50 a hora, com mínimo de 6 meses.
Fontes
- Kubernetes, “Overview” e CNCF, página do projeto, consultadas em 8 de outubro de 2026.