Kubernetes é um sistema open source que distribui containers por um grupo de servidores e mantém tudo no estado que você declarou: se você pediu três cópias de uma aplicação e uma máquina cai, ele recria a cópia perdida em outra. O projeto nasceu no Google, foi doado à Cloud Native Computing Foundation (CNCF) e hoje é oferecido como serviço gerenciado pelas três maiores nuvens.
A pergunta útil não é "o que é", e sim "eu preciso disso?". Para muitos projetos a resposta é não, e este guia ajuda a decidir com critérios concretos, custos oficiais e um teste que você pode fazer no próprio computador.
O que ele resolve (e o que continua com você)
O Kubernetes trabalha por reconciliação. Você descreve o estado desejado em arquivos YAML ("quero 3 réplicas da imagem X, com 256 MB de memória cada, atrás de um endereço interno") e os controladores do cluster comparam isso com a realidade o tempo todo, corrigindo diferenças.
| Ele faz automaticamente | Continua sendo trabalho seu |
|---|---|
| Recriar containers que travam ou somem com uma máquina | Escrever e manter os manifestos YAML |
| Distribuir réplicas entre os servidores (nós) | Atualizar a versão do cluster a cada ciclo de suporte |
| Trocar a versão da aplicação aos poucos, sem derrubar tudo | Configurar permissões (RBAC), rede e segredos com segurança |
| Voltar para a versão anterior com um comando | Monitorar, coletar logs e responder a incidentes |
| Escalar o número de réplicas por uso de CPU | Fazer backup dos dados, que ficam fora dos containers |
A coluna da direita é o motivo pelo qual o Kubernetes tem fama de complexo. Ele tira trabalho repetitivo, mas exige alguém que entenda o sistema.
As peças que aparecem em qualquer tutorial
| Peça | O que é | Analogia rápida |
|---|---|---|
| Cluster | O conjunto de máquinas gerenciado pelo Kubernetes | A empresa inteira |
| Plano de controle | API, agendador e controladores que tomam as decisões | A gerência |
| Nó (node) | Uma máquina, física ou virtual, que roda containers | Um galpão |
| Pod | A menor unidade: um ou mais containers que dividem rede e disco | Uma equipe num posto de trabalho |
| Deployment | Mantém N réplicas de um pod e controla atualizações | A ordem "mantenha 3 equipes ativas" |
| Service | Endereço estável que distribui tráfego entre os pods | O ramal fixo que toca em quem estiver livre |
| Ingress / Gateway | Regras de entrada HTTP vindas de fora do cluster | A recepção do prédio |
| ConfigMap e Secret | Configuração e dados sensíveis injetados nos pods | O quadro de avisos e o cofre |
| Namespace | Divisão lógica do cluster por time ou ambiente | Os andares do prédio |
Os containers em si são imagens comuns, as mesmas que você cria com o Docker. Desde a versão 1.24, o Kubernetes não usa mais o Docker Engine diretamente como runtime (a remoção do chamado dockershim), mas as imagens criadas com Docker continuam funcionando normalmente, porque seguem o padrão OCI.
Guia de decisão: você precisa de Kubernetes?
| Sua situação | Caminho mais sensato |
|---|---|
| Um site ou API, um servidor, equipe de 1 a 3 pessoas | Um VPS com Docker Compose ou uma plataforma gerenciada (PaaS) |
| Uma aplicação em container que precisa escalar, sem equipe de infraestrutura | Serviço de containers sem servidor, como Google Cloud Run, Azure Container Apps ou Amazon ECS Express Mode (a AWS fechou o App Runner para novos clientes) |
| Vários serviços, vários times, deploys diários e exigência de alta disponibilidade | Kubernetes gerenciado (EKS, GKE ou AKS) |
| Obrigação de rodar no próprio data center ou em várias nuvens com a mesma ferramenta | Kubernetes, gerenciado on-premises ou com distribuição própria |
| Só quer aprender para o currículo ou certificação | Cluster local com kind ou minikube (gratuito) |
Três sinais de que ainda não é hora: ninguém da equipe sabe ler um manifesto, a aplicação cabe numa máquina com folga, e não há rotina de monitoramento. Nesses casos, o Kubernetes adiciona custo e pontos de falha antes de trazer benefício. Para o degrau anterior, compare em VPS, hospedagem compartilhada e nuvem.
Quanto custa um cluster gerenciado só para existir
Nos serviços gerenciados, o provedor opera o plano de controle e cobra uma taxa por cluster, além das máquinas (nós), discos, balanceadores e tráfego. Valores das páginas oficiais em outubro de 2026, em dólar:
| Serviço | Taxa do plano de controle | Observações |
|---|---|---|
| Amazon EKS | US$ 0,10 por cluster por hora no suporte padrão | Em suporte estendido (versão antiga), US$ 0,60 por hora |
| Google GKE | US$ 0,10 por cluster por hora, cobrada por segundo | Crédito gratuito de US$ 74,40 por mês por conta de faturamento, o equivalente a um cluster zonal ou Autopilot; suporte estendido soma mais US$ 0,50 por hora |
| Azure AKS | Nível Free: plano de controle gratuito, sem SLA | Nível Standard (com SLA de disponibilidade da API) e Premium (com suporte de longo prazo) são cobrados por hora; o valor aparece na calculadora oficial |
Fontes: páginas de preços do Amazon EKS, do GKE e do AKS, consultadas em outubro de 2026.
US$ 0,10 por hora dá cerca de US$ 73 em um mês de 730 horas, antes de qualquer servidor. A documentação do AKS avisa que clusters no nível Free não são indicados para mais de 10 nós nem para cargas que exigem alta disponibilidade. O custo real costuma vir dos nós ociosos e dos discos esquecidos, assunto de como reduzir custos na nuvem.
Versões: o relógio que ninguém pode ignorar
Em outubro de 2026, a página oficial de versões do Kubernetes listava como suportadas as linhas 1.37 (patch 1.37.1), 1.36, 1.35 e 1.34, esta última com fim de vida em 27 de outubro de 2026. Desde a 1.19, cada versão menor recebe cerca de um ano de correções.
Na prática, um cluster precisa ser atualizado pelo menos uma vez por ano. Quem atrasa paga duas vezes: fica sem correções de segurança e, na nuvem, cai no suporte estendido, que no EKS e no GKE custa US$ 0,50 por hora a mais por cluster, segundo as páginas de preço.
Teste no seu computador com kind ou minikube
Para aprender sem pagar nuvem, rode um cluster local. As duas opções mais citadas na documentação são:
- kind (Kubernetes in Docker): cria o cluster dentro de containers Docker. Instala com
brew install kind(macOS),choco install kindouwinget install Kubernetes.kind(Windows). Depois,kind create cluster. - minikube: usado no tutorial oficial "Hello Minikube". Inicia com
minikube start.
Você também precisa do kubectl, a ferramenta de linha de comando. Com o cluster no ar, os comandos abaixo, do tutorial oficial, criam um deployment com uma imagem de teste do projeto, mostram os pods e expõem a aplicação (o último abre no navegador quando o cluster é do minikube):
kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.53 -- /agnhost netexec --http-port=8080
kubectl get deployments
kubectl get pods
kubectl logs <nome-do-pod>
kubectl expose deployment hello-node --type=LoadBalancer --port=8080
kubectl get services
minikube service hello-node
Para ver o que faz o Kubernetes valer a pena, use o exemplo nginx-deployment da documentação e teste escala, atualização e rollback:
kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
kubectl rollout status deployment/nginx-deployment
kubectl scale deployment/nginx-deployment --replicas=10
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
kubectl rollout history deployment/nginx-deployment
kubectl rollout undo deployment/nginx-deployment
Apague um pod com kubectl delete pod <nome> e rode kubectl get pods em seguida: um substituto aparece, porque o Deployment exige o número de réplicas declarado. No fim, limpe com kubectl delete deployment hello-node, kubectl delete service hello-node e minikube delete (ou kind delete cluster).
Erros comuns de quem começa
- CrashLoopBackOff. O container inicia e cai repetidamente. A causa está quase sempre em
kubectl logs <pod>(com--previouspara ver a execução anterior) ou emkubectl describe pod <pod>. - ImagePullBackOff. O cluster não consegue baixar a imagem: nome ou tag errados, registro privado sem credencial ou limite de downloads do registro.
- Pods sem requests e limits de CPU e memória. O agendador não sabe quanto cada pod precisa, e um processo pode consumir a máquina inteira e derrubar os vizinhos.
- Achar que Secret é cofre. A documentação avisa que, por padrão, Secrets ficam sem criptografia no etcd, o banco do plano de controle, e qualquer um com acesso à API pode lê-los. Ative a criptografia em repouso e restrinja o acesso com RBAC.
- Usar a tag
latest. Duas réplicas podem rodar versões diferentes da aplicação sem você perceber. Fixe a versão da imagem. - Esquecer a atualização do cluster. Veja a seção de versões: o calendário de fim de vida é público e não espera.
Para escolher em qual nuvem rodar o cluster, inclusive quanto à região em São Paulo, veja o comparativo entre AWS, Azure e Google Cloud. O contexto geral de modelos de serviço está em o que é computação em nuvem.
Fontes
- Kubernetes. Releases.
- Kubernetes. Hello Minikube.
- Kubernetes. Deployments.
- Kubernetes. Secrets.
- Kubernetes Blog. Updated: Dockershim Removal FAQ.
- AWS. What is AWS App Runner? (aviso de disponibilidade).
- kind. Quick Start.
- AWS. Amazon EKS pricing.
- Google Cloud. Google Kubernetes Engine pricing.
- Microsoft Azure. Azure Kubernetes Service (AKS) pricing.




