Kubernetes sem mistério: quando usar e como começar

Kubernetes administra estado desejado em um cluster, mas também cria uma plataforma que precisa de rede, segurança, atualização, observabilidade e responsáveis.

Kubernetes resolve um problema que talvez você ainda não tenha Uma aplicação possui: frontend; API; worker; banco; cache. A equipe executa tudo com Docker Compose em um servidor. Surge a proposta: Precisamos migrar para Kubernetes para ficar profissional. Antes da migração, ninguém respondeu: qual falha atual será resolvida; quantos nós são necessários; quem operará o plano de controle; como funcionará a rede; onde ficarão dados persistentes; quem atualizará o cluster; como serão feitos backups; como diagnosticar uma falha distribuída. Kubernetes pode automatizar implantação, agendamento, atualização, descoberta e recuperação de workloads. Ele também transforma a organização em operadora de uma plataforma distribuída. Árvore de decisão Kubernetes deve ser consequência de requisitos, não ponto de partida da arquitetura. O artigo sobre arquitetura sem complexidade desnecessária apresenta o mesmo princípio: adicionar uma camada quando o problema resolvido é mais caro do que a complexidade criada. Problemas que podem justificar a adoção Muitos workloads com padrão comum A organização precisa padronizar: deploy; rede; configuração; healthchecks; recursos; identidades; políticas; observabilidade. Necessidade de agendamento entre nós O sistema precisa posicionar workloads conforme: CPU; memória; afinidade; hardware; região; tolerância; disponibilidade. Atualizações frequentes e graduais Há valor em: rolling update; rollback; réplicas; autoscaling; controle declarativo. Plataforma interna Múltiplas equipes precisam de uma interface comum para publicar serviços com políticas consistentes. Ecossistema necessário A operação depende de componentes disponíveis no ecossistema cloud native e aceita o custo de mantê los. Sinais de que Kubernetes pode ser prematuro uma aplicação pequena; um ou dois servidores; equipe sem disponibilidade operacional; poucos deploys; inexistência de CI/CD; falta de monitoramento; backups não testados; aplicação ainda muda profundamente; banco tratado como diretório local; problema resolvível por PaaS; objetivo principal é aprender uma tecnologia. Aprender é válido. Não é o mesmo que justificar produção. Para um único host, Docker Compose pode descrever e operar aplicações multi container com menos componentes. O modelo mental: estado desejado Você declara: Quero três réplicas desta aplicação usando esta imagem e estes recursos. O Kubernetes compara estado desejado e observado. A documentação de componentes descreve elementos centrais. Plano de controle kube apiserver Expõe a API. etcd Armazena estado do cluster. kube scheduler Seleciona nós para Pods pendentes. kube controller manager Executa controladores que reconciliam estado. Nós kubelet Garante que os containers definidos para o nó sejam executados. container runtime Executa containers por meio da interface compatível. kube proxy ou alternativa de rede Implementa parte da comunicação de Services, conforme solução adotada. Em produção, também entram: CNI; DNS; ingress ou Gateway; storage; certificados; observabilidade; backup; políticas; registro; gerenciamento de segredos. Kubernetes é o núcleo, não a plataforma completa. O que Kubernetes não faz sozinho Ele não: constrói sua imagem; corrige vulnerabilidades; torna a aplicação stateless; cria backups do banco automaticamente; escolhe limites corretos; impede vazamentos por padrão; fornece observabilidade completa; garante alta disponibilidade do serviço; torna uma arquitetura ruim resiliente; elimina necessidade de rollback; resolve licenciamento de dependências. Um Pod reiniciado pode reproduzir o mesmo erro indefinidamente. Managed Kubernetes reduz uma parte da operação Em serviço gerenciado, o provedor pode administrar componentes do plano de controle. A equipe continua responsável, em diferentes níveis, por: nós; versões; addons; rede; storage; RBAC; workloads; segredos; imagens; políticas; custos; observabilidade; dados; incidentes. “Gerenciado” não significa “sem operação”. Versões possuem janela curta Em 15/07/2026, a página oficial de releases do Kubernetes indicava: 1.36.2 como release mais recente; branches mantidas 1.36, 1.35 e 1.34; 1.33 encerrada em 28/06/2026. O projeto mantém as três versões menores mais recentes e oferece aproximadamente um ano de patches para versões atuais. Adotar Kubernetes implica planejar upgrades recorrentes. Inventarie: versão do control plane; nós; CNI; CSI; ingress; cert manager; operadores; APIs removidas; manifests; clientes; ferramentas. Laboratório local com kind O kind executa nós Kubernetes em containers e é adequado para testes locais e CI. Pré requisitos: Docker funcionando; kind ; kubectl . Crie um cluster: Verifique: O laboratório não representa uma topologia de produção. Primeiro manifesto Crie app.yaml : A imagem por tag é aceitável para o laboratório. Em produção, use uma imagem própria analisada e referenciada por digest. Aplique: Acompanhe: Publique localmente por port forward: Em outro terminal: O que foi criado Deployment Declara: imagem; réplicas; estratégia; template do Pod. O controller cria e substitui Pods. Pod É a unidade agendada. Containers no mesmo Pod compartilham contexto de rede e podem compartilhar volumes. Não trate Pod como servidor permanente. Ele pode ser substituído e receber outro endereço. Service Oferece um ponto estável para encontrar Pods selecionados por labels. O ClusterIP é interno ao cluster. O port forward é apenas acesso local de desenvolvimento. Requests e limits afetam decisões diferentes A documentação de recursos distingue: Request Quantidade usada pelo scheduler para posicionar o Pod. Limit Limite aplicado ao consumo, com comportamento específico para CPU e memória. Sem requests, o scheduler não entende adequadamente a necessidade. Limites muito baixos causam: throttling; encerramento por memória; latência; reinícios; instabilidade. Limites altos demais podem esconder sobrealocação. Comece com medição e ajuste. Três probes, três perguntas A documentação do ciclo de Pods define probes com finalidades diferentes. Startup probe A aplicação terminou de iniciar? Enquanto ela não passa, as demais probes não interferem. Readiness probe A instância pode receber tráfego? Quando falha, o Pod pode permanecer executando, mas sai dos endpoints prontos. Liveness probe O processo está em estado que justifica reinício? Uma liveness mal desenhada produz reinícios em cascata. Não faça liveness depender diretamente de banco ou API externa. Se a dependência cair, reiniciar todos os Pods raramente resolve. “Self healing” possui limites Kubernetes pode: recriar container; substituir Pod; reagendar após falha de nó; manter número de réplicas; interromper rollout. Ele não sabe se: uma resposta está semanticamente errada; dados foram corrompidos; pagamento foi duplicado; cache contém conteúdo indevido; usuários abandonaram a tarefa. A aplicação precisa expor sinais corretos e a operação precisa de observabilidade. ConfigMap e Secret não encerram o tema de configuração ConfigMap armazena configuração não sensível. Secret representa dados sensíveis na API, mas o nome não garante criptografia, rotação ou acesso correto. Planeje: criptografia em repouso; RBAC; integração com cofre; projeção em arquivo; rotação; auditoria; restrição de leitura; backup seguro; ausência em logs. Não coloque segredo em manifesto versionado. Rede precisa de política Por padrão, dependendo do plugin e da configuração, workloads podem comunicar se amplamente. Defina: namespaces; NetworkPolicies; egress; DNS; entrada; TLS; identidade; exposição pública. Um Service não protege a aplicação. Ele apenas fornece conectividade. Storage é a parte que não desaparece quando o Pod muda Aplicações stateless são mais simples de mover. Para estado persistente: StorageClass; PersistentVolume; snapshot; backup; restauração; zona; latência; consistência; acesso simultâneo; expansão; retenção. Não confunda réplica de volume com backup. Uma exclusão ou corrupção pode ser replicada. Bancos podem rodar em Kubernetes, mas exigem experiência com operadores, storage, backup e recuperação. Serviço gerenciado pode ser mais adequado. Segurança começa no nó O manifesto do laboratório usa: usuário não root; allowPrivilegeEscalation: false ; filesystem somente leitura; capabilities removidas; seccomp padrão; recursos definidos. Ainda faltam controles de cluster: RBAC; admission; políticas de imagem; atualização dos nós; proteção do kubelet; auditoria; isolamento de rede; etcd; certificados; runtime; backup. O hardening de Linux continua necessário. Remova o laboratório O comando a seguir remove o cluster local mindsite lab e todos os recursos armazenados nele. Confirme que está usando o nome correto: Ele não deve ser usado contra ambientes que contenham dados necessários. Matriz de adoção Critério Sinal favorável Sinal de cautela Workloads Muitos serviços padronizáveis Pouca aplicação Nós Necessidade real de cluster Um host suficiente Equipes Plataforma compartilhada Equipe única pequena Deploy Frequente e automatizado Processo manual Operação Plantão e observabilidade Sem responsável Dados Estratégia formal Volumes improvisados Segurança RBAC e políticas Acesso amplo Upgrade Ciclo planejado Versão esquecida Custo Benefício mensurável Adoção por prestígio Prova de conceito que vale alguma coisa Uma prova deve testar critérios reais: 1. publicar uma aplicação; 2. atualizar sem interrupção indevida; 3. reverter; 4. perder um Pod; 5. perder um nó de laboratório; 6. recuperar segredo; 7. observar requisição; 8. restringir rede; 9. aplicar backup; 10. atualizar a plataforma; 11. medir custo; 12. registrar esforço operacional. Não avalie apenas se o dashboard abriu. Escolha entre três caminhos Não adotar agora Use Compose, VM, LXC ou PaaS. Padronize: imagens; CI/CD; logs; healthchecks; backup; monitoramento. Essas práticas permanecem úteis caso haja migração futura. Usar Kubernetes gerenciado Adequado quando a plataforma é necessária, mas operar todo o plano de controle não gera vantagem. Operar cluster próprio Justificável quando há: requisito on premises; controle específico; equipe capacitada; integração necessária; orçamento; responsabilidade formal. A infraestrutura pode ser declarada e revisada com Terraform, mas IaC não elimina a operação diária. A decisão madura Kubernetes vale a pena quando padronização, agendamento, resiliência e autonomia superam o custo de: cluster; rede; storage; segurança; upgrade; observabilidade; backup; suporte; treinamento. A melhor preparação não é instalar Kubernetes cedo. É construir aplicações operáveis: imagens conhecidas, configuração externa, healthchecks, logs, automação e recuperação. Quando esses fundamentos existem, Kubernetes pode orquestrá los. Quando não existem, ele apenas distribui os mesmos problemas por mais componentes.