Kubernetes

Por que Kubernetes existe?

Tudo bem, você dockerizou sua aplicação. Sobe ela com docker run num servidor. Funciona!

Aí começa a vida real:

• E se o container cair? Quem reinicia?
• E se o servidor cair? Pra onde vai a aplicação?
• E se eu precisar de 20 cópias rodando ao mesmo tempo?
• Como balanceio o tráfego entre elas?
• Como faço deploy de uma versão nova sem cair?
• Como atualizo configuração sem rebuildar a imagem?

Tudo isso na mão é inviável. Por isso existe Kubernetes (ou K8s para os íntimos — tem 8 letras entre o "K" e o "s").

Kubernetes é um orquestrador de containers. Ele cuida de rodar, escalar, monitorar, atualizar e curar suas aplicações automaticamente.

A analogia do maestro

Imagine uma orquestra. Você tem violinistas, baterista, pianista, sopros — cada um é um músico (container). Sozinhos, eles fazem barulho. Juntos, sob um maestro, fazem música.

Kubernetes é o maestro. Ele:

• Diz a cada músico quando entrar
• Substitui um músico que passou mal
• Chama mais músicos quando o teatro está cheio
• Coordena tudo para soar como uma única peça

Como funciona um cluster Kubernetes

Um cluster é um conjunto de máquinas trabalhando como uma só.

flowchart TD
  subgraph CP["CONTROL PLANE — o cérebro"]
    API[API Server]
    Sched[Scheduler]
    CM[Controller Manager]
    ETCD["etcd — banco de dados"]
  end
  CP --> N1["Node 1<br/>[pod] [pod]"]
  CP --> N2["Node 2<br/>[pod] [pod]"]
  CP --> N3["Node 3<br/>[pod] [pod]"]

Control Plane (o cérebro)

• API Server: Porta de entrada. Tudo passa por aqui (até o kubectl).
• etcd: Banco de dados que guarda o estado do cluster.
• Scheduler: Decide em qual node cada pod vai rodar.
• Controller Manager: Vigia tudo e age quando algo sai do esperado.

Worker Nodes

São as máquinas que realmente rodam seus containers. Cada node tem:

• Kubelet: O "agente" do Kubernetes no node. Conversa com o control plane.
• Container runtime: O Docker (ou containerd) que roda os containers.
• Kube-proxy: Cuida da rede.

O modelo declarativo — a chave para entender Kubernetes

Esse conceito é fundamental. Em Kubernetes você não diz "faça X agora". Você diz:

"Eu quero 3 réplicas dessa aplicação rodando, sempre."

E o Kubernetes fica trabalhando 24/7 pra que essa realidade exista. Se um pod morre, ele cria outro. Se um node cai, ele move os pods. Você descreve o estado desejado, ele se vira pra atingir.

Isso é diferente do estilo imperativo (docker run, docker stop). É como dizer "quero a casa limpa" em vez de "passe vassoura, depois pano, depois lustra".

Conceitos básicos: Pod, Service, Deployment

Pod

A menor unidade do Kubernetes. Um pod é um ou mais containers que rodam juntos, compartilhando rede e armazenamento.

Na maioria dos casos, 1 pod = 1 container. Pods com múltiplos containers existem para padrões mais avançados (sidecars).

apiVersion: v1
kind: Pod
metadata:
  name: meu-pod
spec:
  containers:
  - name: app
    image: minha-app:v1
    ports:
    - containerPort: 8080

Deployment

Um Deployment é o gerente dos pods. Ele garante que tenha sempre N réplicas rodando, faz atualizações graduais, reverte se der errado.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: minha-app
spec:
  replicas: 3                    # Quero 3 pods
  selector:
    matchLabels:
      app: minha-app
  template:                      # "fôrma" do pod
    metadata:
      labels:
        app: minha-app
    spec:
      containers:
      - name: app
        image: minha-app:v1
        ports:
        - containerPort: 8080

Quando você aplica isso, o Kubernetes:

1. Cria 3 pods baseados no template
2. Vigia os pods. Se um morrer, cria outro.
3. Se você mudar a imagem para v2, faz rolling update — derruba os pods velhos aos poucos e sobe os novos, sem downtime.

Service

Pods são efêmeros. Cada um nasce com um IP novo. Como, então, outros serviços encontram eles?

A resposta é o Service — um endereço de rede estável que aponta para o conjunto de pods.

apiVersion: v1
kind: Service
metadata:
  name: minha-app-service
spec:
  selector:
    app: minha-app           # qualquer pod com esse label
  ports:
  - port: 80                 # porta do service
    targetPort: 8080         # porta do container
  type: ClusterIP            # tipo do service

Tipos de Service

Outros conceitos que você vai encontrar

• Namespace: Dividem o cluster em "ambientes" lógicos (dev, prod, team-a).
• ConfigMap: Guarda configurações (variáveis de ambiente, arquivos).
• Secret: Como ConfigMap, mas para dados sensíveis (senhas, tokens).
• Ingress: Roteia HTTP/HTTPS de fora do cluster pros services certos (tipo um nginx gerenciado).
• PersistentVolume: Armazenamento que sobrevive à morte dos pods.