Kubernetes tem reputação de ser complicado. Parte dessa reputação é merecida — a curva de aprendizado existe e não é suave. Mas boa parte do medo vem de ser apresentado ao Kubernetes pelo lado errado: uma parede de YAML sem contexto do que cada campo significa ou por que ele existe.

Este post tenta fazer o caminho inverso. Começamos pelo problema que o Kubernetes resolve, depois os conceitos, e só então olhamos para o YAML — que nesse ponto vai parecer natural.

O problema que o Kubernetes resolve

Imagine que você tem uma aplicação rodando em um servidor. Um dia o servidor cai. Sua aplicação fica fora do ar até alguém perceber e reiniciá-la. Isso é ruim.

Agora imagine que a aplicação está tendo pico de tráfego. Você precisa de mais instâncias dela. Você entra no servidor, sobe mais processos manualmente. Depois do pico, esquecem de derrubar as instâncias extras. Isso custa dinheiro.

Kubernetes resolve esses dois problemas — e vários outros. Ele observa o estado da sua aplicação e age para manter o estado desejado. Você declara o que quer; ele se encarrega de fazer acontecer.

Os conceitos fundamentais

Kubernetes tem muitos recursos, mas o dia a dia de quem desenvolve aplicações gira em torno de poucos deles.

Pod é a menor unidade do Kubernetes. É um grupo de um ou mais containers que rodam juntos no mesmo host e compartilham rede e armazenamento. Na prática, a maioria dos Pods tem apenas um container. Você raramente cria Pods diretamente — outros recursos fazem isso por você.

Deployment é o que você usa para rodar sua aplicação. Você diz: "quero 3 réplicas dessa imagem Docker rodando". O Kubernetes cria os Pods, monitora se estão saudáveis e recria qualquer um que falhar. Se você quiser atualizar a versão da imagem, o Deployment faz o rollout gradual sem derrubar tudo de uma vez.

Service é a forma de expor sua aplicação. Pods têm endereços IP que mudam quando são recriados. Um Service cria um endereço estável que fica na frente dos Pods e distribui o tráfego entre eles. É o equivalente de um load balancer interno.

Namespace é uma forma de organizar recursos dentro do cluster. Pense como pastas: você pode ter um namespace producao e outro staging, e os recursos de cada um ficam isolados entre si.

ConfigMap e Secret servem para separar configuração do código. ConfigMap guarda dados não sensíveis (URLs, flags de feature). Secret guarda dados sensíveis (senhas, tokens). Ambos são injetados nos Pods como variáveis de ambiente ou arquivos.

Como isso aparece em YAML

Todo recurso do Kubernetes tem a mesma estrutura básica: tipo, nome e especificação. Um Deployment simples fica assim:

Você declara que quer um Deployment chamado minha-api, com 3 réplicas, usando a imagem minha-api:1.0 na porta 8080. O Kubernetes lê isso, cria os 3 Pods e mantém esse estado mesmo que um servidor do cluster caia ou um Pod seja encerrado inesperadamente.

O YAML não é mágica — é só a forma de você comunicar ao Kubernetes o que você quer. Cada campo tem um significado concreto. Quando você entende o conceito por trás, o campo faz sentido.

O fluxo básico de trabalho

Dia a dia com Kubernetes envolve poucos comandos principais. kubectl apply -f arquivo.yaml aplica ou atualiza um recurso. kubectl get pods mostra o que está rodando. kubectl logs nome-do-pod mostra os logs. kubectl describe pod nome-do-pod mostra os eventos e detalhes quando algo dá errado.

A maioria dos problemas de iniciante em Kubernetes é resolvida com kubectl describe e kubectl logs. Se o Pod não sobe, describe mostra o erro. Se o Pod subiu mas a aplicação não funciona, logs mostra o que aconteceu dentro do container.

O que não se aprende de primeira

Alguns conceitos aparecem só depois que você já está confortável com o básico. Ingress é o que expõe sua aplicação para fora do cluster via HTTP. PersistentVolume é o que você usa quando um container precisa salvar dados em disco. HorizontalPodAutoscaler aumenta e diminui automaticamente o número de réplicas com base no uso de CPU ou memória.

Não tente aprender tudo de uma vez. Kubernetes tem uma superfície grande, mas você consegue fazer muita coisa com Deployment, Service e ConfigMap. O resto você aprende conforme a necessidade aparece.

Conclusão

O medo do Kubernetes quase sempre não é medo do Kubernetes — é medo de uma documentação que começa pelo meio. Quando você entende que ele existe para manter o estado desejado da sua aplicação, que Pod é onde o container roda, que Deployment garante que os Pods existam, e que Service os expõe — o resto é detalhe. Detalhe importante, mas detalhe.

O YAML não é o vilão. Ele é só o formulário que você preenche para dizer ao Kubernetes o que você quer.