Kubernetes pareceu mais fácil depois que entendi esses básicos

Eu ainda não fiz deploy de Kubernetes em nenhum projeto de verdade, igual à maior parte do que sei sobre software design em .NET: assisti, entendi, ainda não apliquei. Mas os básicos pararam de parecer uma parede de YAML assim que tive um modelo mental para o que cada peça de fato faz.

Pods, Deployments, Services, arquivos YAML, ConfigMaps, Secrets, probes, clusters, e dezenas de comandos. Como desenvolvedor .NET júnior, eu ficava pensando: por que eu precisaria de tudo isso só para rodar uma API ASP.NET Core?

Ficou mais fácil assim que entendi algumas ideias básicas.

Kubernetes roda containers

Kubernetes não builda a minha aplicação C#. Primeiro ela precisa ser publicada e empacotada dentro de uma imagem Docker:

ASP.NET Core API
→ Docker image
→ Kubernetes

Se a aplicação não funciona dentro do Docker, Kubernetes não vai consertar isso.

Pods rodam a aplicação

Um Pod é onde um container roda. Um Pod pode conter uma instância de uma API ASP.NET Core.

Pods são temporários. Eles podem ser deletados, reiniciados, ou substituídos, então nada importante deveria viver dentro de um. O database, sessions, e arquivos importantes ficam fora do Pod.

Deployments gerenciam Pods

Um Deployment descreve quantas instâncias de uma aplicação deveriam estar rodando:

spec:
  replicas: 2

Se um Pod trava, o Kubernetes cria outro para substituí-lo. Essa é a ideia central: você descreve o estado desejado, e o Kubernetes tenta mantê-lo.

Services expõem a aplicação

Pods podem mudar de endereço IP quando são recriados. Um Service dá à aplicação um endereço estável e roteia requests para quaisquer Pods disponíveis:

Client
→ Service
→ Pod
→ ASP.NET Core API

Sem um Service, os clients precisariam saber o endereço de cada Pod individual.

Configuração deveria ser externa

Connection strings e configurações de ambiente não deveriam estar hardcoded na imagem. ConfigMaps e Secrets cuidam disso, e o ASP.NET Core os lê como environment variables:

var connectionString =
    builder.Configuration.GetConnectionString("DefaultConnection");

É isso que permite que a mesma imagem de container rode em development, testing, e produção com configurações diferentes.

Health checks importam

O Kubernetes consegue checar se uma API está saudável. Uma readiness probe pergunta se a aplicação consegue receber tráfego. Uma liveness probe pergunta se ela ainda está rodando corretamente. O ASP.NET Core expõe isso através de um health endpoint:

builder.Services.AddHealthChecks();

app.MapHealthChecks("/health");

O Kubernetes usa isso para decidir se um Pod deveria receber tráfego ou ser reiniciado.

Os comandos que mais importam

O punhado de comandos kubectl que aparecem constantemente em todo tutorial:

kubectl get pods
kubectl get services
kubectl describe pod <pod-name>
kubectl logs <pod-name>
kubectl apply -f deployment.yaml

O fluxo de debugging é quase sempre o mesmo: get pods, depois describe pod, depois checar logs.

Onde eu realmente estou com isso

Eu entendo o modelo mental: Docker empacota a aplicação, Pods a rodam, Deployments gerenciam os Pods, Services os expõem, ConfigMaps e Secrets cuidam da configuração, probes checam saúde. O que eu ainda não tenho é um projeto de verdade rodando de fato no Kubernetes. É a mesma lacuna que tenho com vários conceitos de software design: entendido o suficiente para explicar, ainda não algo que eu tive que fazer funcionar sob condições reais. Isso é o próximo passo.