Kubernetes

O Docker Compose inicia o BoxOffice em uma máquina. A produção precisa de mais: quarenta containers espalhados por várias máquinas, um substituto iniciado em segundos quando um deles morre, uma nova versão publicada sem indisponibilidade e capacidade adicionada automaticamente quando a venda começa. Fazer isso à mão — SSH em um nó, docker run, atualizar o load balancer — não sobrevive à primeira noite de plantão. Um orquestrador faz isso por você, e o Kubernetes é o padrão de fato⁵.

O Kubernetes descende dos gerenciadores de cluster internos do Google, Borg e Omega; seus projetistas resumiram a lição de uma década executando containers em escala como estado declarativo reconciliado por laços de controle independentes¹.

O laço de controle: estado desejado vs estado real

Você nunca diz ao Kubernetes "inicie um container". Você diz "deve haver cinco réplicas de catalog, versão 1.4.0, cada uma com 1 CPU" — o estado desejado — e o armazena no API server. Os controladores então rodam para sempre:

loop:
    desired = read spec from the API server
    actual  = observe the cluster
    if actual != desired:
        act to reduce the difference (create, delete, update)

sequenceDiagram
    participant U as kubectl / Argo CD
    participant API as API server (+ etcd)
    participant RS as Controlador do ReplicaSet
    participant S as Scheduler
    participant K as kubelet (nó 2)
    U->>API: aplica Deployment catalog, replicas = 5
    API->>RS: watch: desejado 5, real 4 (um nó morreu)
    RS->>API: cria o Pod catalog-7f9c
    API->>S: watch: pod sem nó
    S->>API: associa catalog-7f9c ao nó 2 (CPU livre suficiente)
    API->>K: watch: novo pod para este nó
    K->>K: baixa a imagem, inicia o container, executa as probes
    K->>API: status: Running, Ready
    Note over RS,API: real = desejado → nada a fazer

É por isso que o Kubernetes se autorrecupera: um processo que caiu, um pod apagado ou um nó morto aparecem todos como "real ≠ desejado", e o mesmo laço os corrige. É também por isso que a API é declarativa e idempotente: aplicar o mesmo manifest duas vezes não muda nada.

As peças de um cluster

Com um serviço gerenciado (EKS, GKE, AKS), o provedor executa e atualiza o control plane; você gerencia os nós — ou, com GKE Autopilot ou EKS no Fargate, nem eles.

Os objetos centrais

O catalog do BoxOffice no Kubernetes

Os manifests abaixo mostram o que um catalog de produção precisa. Leia-os de cima para baixo; cada bloco responde a uma pergunta operacional. O Hands-on 10 escreve uma versão menor, para um cluster de três nós num notebook (quadro depois dos manifests).

apiVersion: apps/v1
kind: Deployment
metadata:
  name: catalog
  labels: { app: catalog }
spec:
  replicas: 4
  selector:
    matchLabels: { app: catalog }
  strategy:
    type: RollingUpdate
    rollingUpdate: { maxSurge: 25%, maxUnavailable: 0 }   # never below 4 ready pods
  template:
    metadata:
      labels: { app: catalog }
    spec:
      terminationGracePeriodSeconds: 30
      topologySpreadConstraints:                           # spread replicas across zones
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: ScheduleAnyway
          labelSelector: { matchLabels: { app: catalog } }
      containers:
        - name: catalog
          image: ghcr.io/boxoffice/catalog@sha256:9f2c0d7e1b4a   # digest, not a tag
          ports: [ { containerPort: 8080 } ]
          envFrom:
            - configMapRef: { name: catalog-config }
            - secretRef:    { name: catalog-db }
          resources:
            requests: { cpu: "500m", memory: "768Mi" }      # what the scheduler reserves
            limits:   { memory: "768Mi" }                   # hard ceiling (OOMKilled above)
          startupProbe:                                     # JVM warm-up: up to 60 s
            httpGet: { path: /actuator/health/liveness, port: 8080 }
            periodSeconds: 5
            failureThreshold: 12
          readinessProbe:                                   # receive traffic?
            httpGet: { path: /actuator/health/readiness, port: 8080 }
            periodSeconds: 5
            failureThreshold: 3
          livenessProbe:                                    # restart me?
            httpGet: { path: /actuator/health/liveness, port: 8080 }
            periodSeconds: 10
            failureThreshold: 3
          lifecycle:
            preStop: { sleep: { seconds: 5 } }              # let endpoints update before SIGTERM

apiVersion: v1
kind: Service
metadata: { name: catalog }
spec:
  selector: { app: catalog }
  ports: [ { port: 8080, targetPort: 8080 } ]
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: { name: catalog }
spec:
  scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: catalog }
  minReplicas: 4
  maxReplicas: 40
  metrics:
    - type: Resource
      resource:
        name: cpu
        target: { type: Utilization, averageUtilization: 60 }   # % of the CPU request
  behavior:
    scaleUp:   { stabilizationWindowSeconds: 0,   policies: [ { type: Percent, value: 100, periodSeconds: 15 } ] }
    scaleDown: { stabilizationWindowSeconds: 300, policies: [ { type: Pods,    value: 2,   periodSeconds: 60 } ] }
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: { name: catalog }
spec:
  minAvailable: 3
  selector: { matchLabels: { app: catalog } }

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata: { name: boxoffice-api }
spec:
  parentRefs: [ { name: public-gateway } ]
  hostnames: [ "api.boxoffice.example" ]
  rules:
    - matches: [ { path: { type: PathPrefix, value: /catalog } } ]
      backendRefs: [ { name: catalog, port: 8080 } ]
    - matches: [ { path: { type: PathPrefix, value: /inventory } } ]
      backendRefs: [ { name: inventory, port: 8080 } ]

A Gateway API (Gateway + HTTPRoute) é a sucessora do antigo objeto Ingress: ela separa o dono da infraestrutura (quem opera o Gateway) dos times de aplicação (donos das rotas) e suporta nativamente backends com pesos³ — que é como os canaries dividem o tráfego (veja Entrega). A aula de Borda trata do componente Ingress.

env:
  - name: SERVER_SHUTDOWN
    value: graceful        # finish in-flight requests on SIGTERM
resources:
  requests:                # what the scheduler reserves; HPA percentages are relative to this
    cpu: 250m
    memory: 512Mi
  limits:
    cpu: "1"
    memory: 768Mi
startupProbe:              # the JVM needs time: no liveness kills before it has started
  httpGet: { path: /actuator/health/liveness, port: http }
  periodSeconds: 5
  failureThreshold: 60     # up to 5 min: the first start also runs the Flyway migrations
livenessProbe:             # "restart me": only for a process that is stuck
  httpGet: { path: /actuator/health/liveness, port: http }
  periodSeconds: 10
  failureThreshold: 3
readinessProbe:            # "send me traffic": removed from the Service while not ready
  httpGet: { path: /actuator/health/readiness, port: http }
  periodSeconds: 5
  failureThreshold: 2
lifecycle:
  preStop:
    sleep:
      seconds: 5           # let the endpoints update before the JVM stops accepting

Probes: três perguntas diferentes

Mantenha a liveness local (a JVM está respondendo?) e faça a readiness refletir apenas o que o próprio pod precisa para atender. O Spring Boot Actuator expõe /actuator/health/liveness e /actuator/health/readiness exatamente com essa semântica. A aula de Observabilidade trata health checks como um componente da paleta (Health Check).

Requests, limits e qualidade de serviço

• Request — o que o scheduler reserva em um nó. Decide onde um pod cabe e é a base da porcentagem de utilização do HPA.
• Limit — o teto. Acima do limite de memória, o container é morto (OOMKilled); acima do limite de CPU, ele é estrangulado (throttled) — simplesmente espera, o que aparece como latência, não como erros.

Perdendo um nó

O laço de controle substitui os pods perdidos, mas a autocura precisa de duas coisas que o laço não fornece. Os pods substitutos precisam de espaço: o scheduler só coloca um pod num nó cuja capacidade livre cubra seus requests, então num cluster lotado a 100% os pods de um nó morto ficam Pending. E quem chama precisa parar de enviar aos pods mortos: até o nó ser declarado NotReady (dezenas de segundos, por padrão) e os endpoints do Service serem atualizados, parte do tráfego ainda vai para pods que não existem mais. São as duas regras de redundância e failover da aula de Confiabilidade, no nível dos nós: capacidade N + 1 e detecção rápida de falhas.

Experimente: em k8s-node-failure, catalog e pricing rodam 6 pods cada em 3 nós × 4 pods — um cluster lotado — e em t = 60 s um nó morre.

1. Rode como está. Por cerca de 40 s, perto de 90% das requisições falham: quem chama ainda envia aos pods mortos. Depois os erros caem, e voltam a 7–10% a partir de t ≈ 150 s: os 2 pods perdidos de cada serviço não têm para onde ir, e 4 sobreviventes carregam a carga de 6. No total: erros ≈ 27%, p99 ≈ 4,6 s.
2. Dê espaço ao cluster: ajuste podsPerNode para 8 no quadro do cluster. Os erros tardios desaparecem (os pods perdidos são realocados), mas a janela de 40 s continua: erros ≈ 25%.
3. Conecte um Service Registry a catalog e pricing — o equivalente, no playground, a endpoints atualizados rapidamente. Quem chama descarta os pods mortos em 3 s em vez de 30–40 s: erros ≈ 4%.

Autoscaling em três níveis

flowchart LR
    load["k6 / fãs<br/>requisições por segundo ↑"] --> hpa["HPA<br/>mais pods"]
    hpa --> pend["Pods Pending<br/>(sem espaço nos nós)"]
    pend --> ca["Cluster Autoscaler / Karpenter<br/>mais nós"]
    ca --> run["Pods escalonados<br/>imagem baixada, JVM aquecida"]
    run --> ready["Ready → recebem tráfego"]

1. Pods — Horizontal Pod Autoscaler (HPA). A cada 15 s o HPA calcula²

Com 4 pods de catalog a 90 % de CPU (do request) e meta de 60 %: ⌈4 × 90/60⌉ = 6 pods. Escalar por CPU funciona para serviços limitados por CPU; para serviços limitados por I/O, escale por requisições por segundo por pod ou pelo atraso da fila por meio de métricas customizadas/externas.

2. Nós — Cluster Autoscaler ou Karpenter. Quando pods ficam Pending porque nenhum nó tem espaço, um autoscaler de nós provisiona novas máquinas (o Karpenter escolhe tipos de instância por carga de trabalho e pode usar capacidade spot). Isso leva minutos: boot da VM, entrada do nó no cluster, download da imagem.

3. Eventos — KEDA. O Kubernetes Event-Driven Autoscaler escala a partir de fontes externas (atraso de consumidores Kafka, tamanho de filas, janelas de cron) e consegue escalar até zero — natural para os workers de notification⁴.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: catalog
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: catalog
  minReplicas: 2
  maxReplicas: 8
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60     # % of the CPU *request* (250m): scale when pods average > 150m
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0  # react at once to load
      selectPolicy: Max
      policies:
        - type: Percent
          value: 100                 # at most double...
          periodSeconds: 15
        - type: Pods
          value: 2                   # ...or +2 pods, whichever is more, every 15 s
          periodSeconds: 15
    scaleDown:
      stabilizationWindowSeconds: 120  # wait 2 min of lower load before removing pods
      policies:
        - type: Pods
          value: 1
          periodSeconds: 30

Experimente: no cenário abaixo, rode o perfil spike com 2 réplicas e depois com 6. Observe a latência p99 e os erros enquanto as réplicas estão ocupadas; depois ative o autoscaling (se disponível) e observe o atraso entre o início do pico e o momento em que as novas réplicas ficam saudáveis.

Onde rodar Kubernetes

Trade-offs

Como se conecta

flowchart LR
    ETCD["etcd: Raft<br/>→ Consenso (aula 3)"] --> DS["estado desejado<br/>no API server"]
    DS --> CL["laço de controle:<br/>real → desejado"]
    CL --> DEP["Deployment → pods"]
    DEP --> SVC["Service, Ingress, Gateway API<br/>→ Balanceamento de carga"]
    DEP --> PR["probes de startup,<br/>readiness, liveness"]
    PR --> HC["endpoints de saúde<br/>→ Confiabilidade, Observabilidade"]
    DEP --> RL["requests e limits,<br/>QoS, throttling de CPU"]
    RL --> HPA["HPA, autoscaler de nós,<br/>KEDA por lag"]
    HPA --> PRE["pré-escalar antes das 10:00<br/>→ Autoscaling em Compute"]
    RL --> COST["requests movem a fatura<br/>→ FinOps"]
    DEP --> PDB["PDB, espalhar por zonas<br/>→ redundância"]

Componentes da paleta: app · worker (KEDA escala o notification pelo lag) · scheduler (CronJob libera reservas expiradas) · lb (um Service é um balanceador L4) · ingress · healthcheck · metrics (o que o HPA lê). Cenários: scale-out, k8s-node-failure (N + 1 nós), flash-sale (pré-escala). Continua em: Tráfego e borda — balanceamento no Kubernetes, Distribuídos — consenso (etcd), Compute — atraso do autoscaling, Confiabilidade — health checks, FinOps, Exercício — autoscaling no Kubernetes.