Kubernetes avançado
pela lente da F1.

Etapa 01 probes + requests/limits

Saúde da aplicação e gerenciamento de recursos

O problema

O conceito

Probes. Você já viu as três no guia básico; aqui o foco é o comportamento sob falha.

• Liveness pergunta "o container travou?". Se falhar o número de vezes definido em failureThreshold, o kubelet reinicia o container. Serve para travamentos irrecuperáveis (deadlock), não para lentidão passageira, senão o app entra em um ciclo de reinícios. Se o processo simplesmente morre, quem recria o container é o restartPolicy do Pod (o padrão é Always), sem participação da liveness; a liveness cobre o caso em que o processo continua vivo, mas travado.
• Readiness pergunta "pode receber requisições?". Se falhar, o Pod é removido dos endpoints do Service e não é reiniciado. Volta sozinho quando passa de novo. É o que garante um rollout sem erros para o usuário.
• Startup pergunta "terminou de subir?". Enquanto não passa, liveness e readiness ficam suspensas. Protege apps de boot lento, que de outra forma seriam mortos antes de ficarem prontos.

Requests e limits. Todo container pode declarar dois valores por recurso:

• requests é o que o container *reserva*. O scheduler usa esse valor para decidir em qual nó o Pod cabe. É o piso garantido.
• limits é o teto que ele não pode ultrapassar. Passar do limite de memória faz o kernel encerrar o container (OOMKill). Passar do limite de CPU não mata nada: o kernel desacelera o processo (throttling) para mantê-lo dentro da cota.

CPU é medida em milicores (100m é 0,1 CPU) e memória em bytes com sufixos binários (128Mi).

Classe de QoS. Da combinação de requests e limits nasce a classe de QoS do Pod, que pesa na decisão de quem sai primeiro sob pressão:

• Guaranteed: todos os containers têm requests iguais a limits, tanto para CPU quanto para memória.
• Burstable: pelo menos um container declara request ou limit, mas o Pod não se enquadra em Guaranteed. Usa folga ociosa e cede sob contenção.
• BestEffort: nenhum container declara requests nem limits. É o primeiro a ser sacrificado.

Um ponto contraintuitivo: limite de CPU pode piorar a latência. O kernel Linux aplica o limite por cotas em períodos de 100 ms (CFS quota). Um serviço com vários threads pode gastar a cota inteira do período em um pico curto e ficar parado até o próximo período, mesmo com uso médio baixo. A Buffer relatou publicamente que removeu os limits de CPU de serviços sensíveis a latência e viu o p99 (a latência abaixo da qual ficam 99% das requisições) cair de forma expressiva (o relatório de origem fala em 5 a 10 vezes). A lição prática: em um cluster compartilhado por vários times, limits dão isolamento; em um serviço sensível a latência, vale considerar manter o request e retirar o limit de CPU, mantendo o limit de memória.

Disponibilidade e sinais. A disponibilidade de um serviço é A = MTBF / (MTBF + MTTR): o tempo médio entre falhas dividido por ele somado ao tempo médio de recuperação. Com réplicas independentes, as probabilidades de falha se multiplicam: se cada Pod fica fora do ar 1% do tempo, a chance de dois Pods estarem fora ao mesmo tempo é 0,01 × 0,01 = 0,0001, ou seja, 0,01%, e o conjunto chega a cerca de 99,99% de disponibilidade, desde que as falhas sejam independentes. O Service funciona como um "OU lógico", porque basta um Pod Ready. Para saber se o serviço está saudável de verdade, o Google SRE propõe os quatro *golden signals*: latência, tráfego, erros e saturação. Probes cobrem erro e parte da saturação; para o resto, usa-se Prometheus e Grafana.

Os conceitos-chave

Exemplos comentados

 # deploy-saude.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3                          # três cópias, como no guia básico
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api                       # precisa casar com o selector
    spec:
      containers:
        - name: api
          image: stefanprodan/podinfo:6.14.1   # versão fixa; confirme a tag com o comando acima
          ports:
            - containerPort: 9898
          startupProbe:                # protege o boot lento
            httpGet:
              path: /healthz
              port: 9898
            failureThreshold: 30       # até 30 tentativas
            periodSeconds: 10          # a cada 10s: até 5min para subir
          livenessProbe:               # travou? reinicia o container
            httpGet:
              path: /healthz
              port: 9898
            periodSeconds: 10
            failureThreshold: 3        # 3 falhas seguidas antes de reiniciar
          readinessProbe:              # pronto? entra no Service
            httpGet:
              path: /readyz
              port: 9898
            periodSeconds: 5
          resources:
            requests:                  # reserva usada pelo scheduler
              cpu: 100m
              memory: 64Mi
            limits:
              memory: 128Mi            # teto de memória; sem limit de CPU, para evitar throttling
---
apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api                           # acha os Pods pelo label
  ports:
    - port: 80
      targetPort: 9898

Comandos essenciais desta etapa

Mão na massa

1. Aplique deploy-saude.yaml e confirme 3 Pods Running com kubectl get pods -l app=api. Rode o comando de qosClass e observe Burstable.
2. Anote os nomes de dois Pods da lista (<pod-1> e <pod-2>). Desligue a readiness do primeiro com kubectl exec <pod-1> -- curl -s -X POST localhost:9898/readyz/disable. Observe READY 0/1 com RESTARTS 0 e um endpoint a menos em kubectl get endpoints api.
3. Derrube o processo do segundo Pod com kubectl exec <pod-2> -- curl -s localhost:9898/panic e acompanhe com kubectl get pods -w. Observe RESTARTS subir para <pod-2>. Quem reiniciou foi o restartPolicy: o processo morreu e o kubelet recriou o container, sem participação da liveness. Se o primeiro /panic não derrubar o processo, repita.
4. Aplique liveness-falha.yaml e acompanhe com kubectl get pod liveness-falha -w. Observe RESTARTS subir depois de 30 a 40 segundos, embora o processo continue vivo, e confirme em kubectl describe pod liveness-falha o par Liveness probe failed e Killing. Essa é a liveness agindo sobre um app vivo e travado.
5. Aplique pods-qos.yaml e confirme as três classes com o custom-columns. Observe que a classe é calculada pelo Kubernetes a partir dos requests e limits, sem você declará-la.
6. Aplique pod-oom.yaml e observe o status OOMKilled (confirme com describe pod e procure Reason: OOMKilled).
7. Limpe: kubectl delete -f deploy-saude.yaml -f pods-qos.yaml -f pod-oom.yaml -f liveness-falha.yaml.

Etapa 02 taints + affinity + spread

Agendamento avançado e comportamento de nós

O problema

O conceito

Taints e tolerations: repelir. O *taint* é uma marca colocada no nó, que diz "não agende Pods aqui, a menos que eles tolerem esta marca". A *toleration* é a declaração no Pod: "eu aceito essa marca, posso ir". Um taint tem chave, valor e efeito:

• NoSchedule: não agenda Pods que não toleram; os que já rodam ali continuam.
• PreferNoSchedule: evita, mas não é absoluto.
• NoExecute: além de barrar novos, expulsa os Pods que não toleram e já estavam no nó (útil para esvaziar um nó).

Ponto crucial: o taint só repele, não atrai. Um Pod que tolera o taint do nó de GPU pode ir para o nó de GPU ou para um nó comum. Para garantir que ele vá *apenas* para a GPU, combine com node affinity.

Node affinity: atrair. É a contraparte positiva: "quero ir para nós com este label". Existem dois modos, escritos nos campos requiredDuringSchedulingIgnoredDuringExecution (obrigatório: sem o label, o Pod fica Pending) e preferredDuringSchedulingIgnoredDuringExecution (preferência, com peso: se não houver, agenda em outro lugar). O trecho IgnoredDuringExecution indica que a regra vale só no agendamento; se o label do nó mudar depois, o Pod não é movido.

Pod affinity e anti-affinity: relacionar Pods entre si. Em vez de olhar labels do nó, olham os Pods que já estão lá. *Affinity* aproxima (cache perto do frontend, na mesma zona); *anti-affinity* separa (não colocar duas réplicas do banco no mesmo nó). A zona é uma área física separada dentro da mesma região do provedor de nuvem, com energia e rede próprias. A documentação do Kubernetes não recomenda usar regras inter-pod em clusters de várias centenas de nós, porque o cálculo é caro para o scheduler.

Topology Spread Constraints: espalhar com garantia numérica. É a alternativa preferida para distribuir réplicas. Você declara um topologyKey (o critério de agrupamento, por exemplo kubernetes.io/hostname para nós ou topology.kubernetes.io/zone para zonas), um maxSkew (a diferença máxima permitida de quantidade de Pods entre dois grupos) e whenUnsatisfiable: DoNotSchedule (rígido, o Pod fica Pending se violar) ou ScheduleAnyway (preferência). Com 4 réplicas, 2 nós e maxSkew: 1, a única distribuição aceita é 2 e 2; 3 e 1 é rejeitada, porque a diferença seria 2.

Eviction sob pressão: a autoproteção do nó. Quando o nó fica sem memória, disco ou PIDs, o kubelet age antes do colapso. Primeiro tenta liberar espaço (containers mortos, imagens não usadas). Se não bastar, começa a despejar Pods. A ordem segue a documentação: primeiro os Pods cujo uso do recurso em falta excede o request, depois a prioridade (PriorityClass), depois o tamanho do uso em relação ao request. Na prática, BestEffort e Burstable que passaram de seus requests saem antes, e Guaranteed e Pods de alta prioridade saem por último. Detalhes que importam:

• O despejo por pressão de recursos ignora o PodDisruptionBudget, porque é uma emergência.
• O parâmetro de kubelet eviction-minimum-reclaim faz o kubelet liberar uma margem além do limite, para evitar um efeito dominó de despejos repetidos.
• Eviction não é OOMKill. O OOMKill é o kernel encerrando *um container* que passou do limit de memória; o eviction é o kubelet retirando *Pods* para salvar o *nó*.

Manutenção planejada: cordon, drain e PodDisruptionBudget. Quando você precisa esvaziar um nó de propósito (atualização, troca de máquina), usa kubectl cordon (marca o nó como não agendável) e kubectl drain (cordon, mais evicção ordenada dos Pods). Esse tipo de interrupção, decidida e agendada por alguém, é chamado de disrupção voluntária; a interrupção que acontece sem pedido (um nó sem memória, uma máquina retomada pelo provedor) é involuntária. O PodDisruptionBudget (PDB) define quantos Pods de uma aplicação podem ficar indisponíveis durante uma disrupção voluntária, em minAvailable (mínimo que precisa seguir de pé) ou maxUnavailable (máximo que pode sair). O drain respeita o PDB: se retirar um Pod violaria o orçamento, a evicção é recusada e repetida até ser possível. Já o despejo por pressão de recursos, descrito acima, é involuntário e não respeita o PDB.

PriorityClass e a natureza do scheduler. A PriorityClass atribui prioridade numérica a Pods. Pods de sistema (system-cluster-critical e system-node-critical) têm prioridade altíssima e quase nunca são despejados. Alocar Pods em nós com múltiplas restrições é um problema de bin packing, NP-difícil; o scheduler usa uma heurística gulosa em duas fases (filtra os nós que servem, pontua os que sobraram, escolhe o melhor), rápida mas não necessariamente ótima.

Os conceitos-chave

Exemplos comentados

 # pod-gpu.yaml
 # Passo prévio, feito uma vez por quem administra o cluster:
 #   kubectl taint nodes gpu-node-1 nvidia.com/gpu=true:NoSchedule
 #   kubectl label nodes gpu-node-1 accelerator=nvidia-gpu
apiVersion: v1
kind: Pod
metadata:
  name: treino-ml
spec:
  tolerations:                       # aceita o taint do nó de GPU
    - key: "nvidia.com/gpu"
      operator: "Equal"
      value: "true"
      effect: "NoSchedule"
  affinity:
    nodeAffinity:                    # E exige ir para um nó com GPU
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: "accelerator"
                operator: In
                values: ["nvidia-gpu"]
  containers:
    - name: treino
      image: myregistry/treino:1.0   # imagem fictícia
      resources:
        limits:
          nvidia.com/gpu: 1          # pede uma GPU ao plugin de dispositivo

Comandos essenciais desta etapa

Mão na massa

1. Se o perfil padrão do Minikube estiver ligado, rode minikube stop. Suba o cluster de 2 nós (minikube start -p lab --nodes 2), aplique o taint e o label em lab-m02 e aplique os dois Pods do exemplo. Observe sem-toleration em Pending e a mensagem untolerated taint no describe; observe com-toleration em Running no lab-m02.
2. Remova o taint (kubectl taint nodes lab-m02 dedicated=ml:NoSchedule-), apague os dois Pods e aplique web-spread.yaml e pdb-web.yaml. Observe com -o wide os 4 Pods divididos em 2 e 2 e, em kubectl get pdb web, o valor 1 em ALLOWED DISRUPTIONS.
3. Apague o web e o pdb-web com kubectl delete -f web-spread.yaml -f pdb-web.yaml, aplique pdb-drain.yaml, rode o drain do lab-m02 e observe a recusa Cannot evict pod as it would violate the pod's disruption budget. Interrompa com Ctrl+C e rode kubectl uncordon lab-m02.
4. Rode kubectl describe node lab e observe a seção Conditions: MemoryPressure, DiskPressure e PIDPressure em False são o estado saudável. O despejo por pressão (que ignora o PDB) só acontece quando uma delas vira True; ele não é reproduzido aqui porque exigiria esgotar o nó.
5. Limpe: minikube delete -p lab. Essa remoção apaga também o contexto lab do kubectl, então volte ao cluster padrão com minikube start (se você parou o perfil padrão no passo 1) ou com kubectl config use-context minikube, e confirme com kubectl get nodes antes de seguir para a Etapa 03.

Etapa 03 estratégias de atualização

Estratégias de atualização e rollouts

O problema

O conceito

RollingUpdate (o padrão) substitui os Pods aos poucos, mantendo o serviço no ar. O Deployment cria um novo ReplicaSet com a versão nova e reduz o antigo na medida em que os novos ficam prontos. Dois parâmetros controlam o ritmo da troca:

• maxUnavailable: o piso de capacidade, isto é, quantos Pods podem ficar indisponíveis durante a troca. Padrão: 25%.
• maxSurge: a folga extra, isto é, quantos Pods a *mais* que o desejado podem existir temporariamente. Padrão: 25%.

Com N réplicas e os valores padrão, durante o rollout existem no mínimo cerca de 75% de Pods disponíveis e no máximo cerca de 125% de Pods em execução. O Kubernetes arredonda maxSurge para cima e maxUnavailable para baixo; com 10 réplicas, o padrão resulta em 3 de surge e 2 de unavailable, ou seja, no mínimo 8 disponíveis e no máximo 13 em execução. Os dois parâmetros não podem ser zero ao mesmo tempo, porque a troca não teria como progredir.

Recreate derruba *todos* os Pods da versão antiga antes de subir os da nova. Há downtime, mas as duas versões nunca coexistem. É a escolha quando a v1 e a v2 são incompatíveis.

O ajuste é um compromisso. Um maxUnavailable alto permite trocar mais Pods ao mesmo tempo, o que acelera a troca, mas reduz a capacidade que atende os usuários durante ela, e a fila de requisições cresce. Em teoria de filas, λ é a taxa de chegada de requisições, μ é quanto cada Pod atende por segundo e c é o número de Pods; a utilização ρ = λ/(cμ) é a fração da capacidade em uso. Com menos Pods (c menor), ρ sobe, e a latência cresce muito rápido quando ρ se aproxima de 1. Um maxSurge alto também acelera, mas dobra o número de Pods e de conexões, e isso pode saturar o banco de dados. Duas receitas úteis:

• Disponibilidade primeiro: maxUnavailable: 0 (nunca reduz a capacidade) e maxSurge dentro do orçamento de recursos do cluster.
• Menor tempo sob orçamento: escolher maxSurge e maxUnavailable o mais altos possível, de modo que o pico de Pods ((1 + surge) × N) caiba no orçamento de recursos e o piso ((1 - unavailable) × N) não degrade o serviço além do aceitável.

Ferramentas de garantia:

• minReadySeconds (padrão 0): quantos segundos um Pod precisa permanecer Ready antes de contar como disponível. Evita seguir adiante com um Pod que cai logo depois de subir.
• progressDeadlineSeconds (padrão 600): se o rollout não progride nesse tempo, o Deployment recebe a condição ProgressDeadlineExceeded. O Deployment não faz rollback sozinho; quem faz é você (ou uma ferramenta).
• revisionHistoryLimit (padrão 10): quantas revisões antigas (ReplicaSets) guardar para rollback.

O rollout só é disparado por mudanças em .spec.template. Mudar o número de réplicas ou uma annotation do próprio Deployment não conta.

Estratégias mais sofisticadas. Blue/Green e canário (próximas etapas) não são nativos do objeto Deployment. Controladores como Argo Rollouts e Flagger os implementam, com passos de promoção e análise automática de métricas.

Os conceitos-chave

RollingUpdate com disponibilidade em primeiro lugar

 # myapp.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  annotations:
    kubernetes.io/change-cause: "nginx 1.26"   # aparece no rollout history
spec:
  replicas: 4
  minReadySeconds: 10                  # o Pod precisa ficar 10s Ready para contar como disponível
  progressDeadlineSeconds: 600         # padrão: 10 minutos para o rollout progredir
  revisionHistoryLimit: 10             # padrão: guarda 10 revisões para rollback
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0                # nunca reduz a capacidade
      maxSurge: 1                      # cria 1 Pod extra por vez
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: app
          image: nginx:1.26
          readinessProbe:              # sem readiness, o Pod conta como pronto assim que sobe
            httpGet:
              path: /
              port: 80

Comandos essenciais desta etapa

Mão na massa

1. Aplique myapp.yaml e confirme 4 Pods Running. Em um segundo terminal, rode kubectl get pods -w.
2. Rode kubectl set image deployment/myapp app=nginx:1.27. Observe no segundo terminal que sempre existem 4 Pods prontos e que no máximo 1 Pod extra aparece: é o maxUnavailable: 0 com maxSurge: 1 em ação.
3. Registre a mudança com kubectl annotate e confirme em kubectl rollout history deployment/myapp que a revisão 2 mostra nginx 1.27.
4. Reduza o prazo com o patch de progressDeadlineSeconds: 30, troque a imagem para nginx:nao-existe e rode kubectl rollout status deployment/myapp. Observe a mensagem exceeded its progress deadline e confirme o código de saída com echo $?.
5. Observe com kubectl get pods que os Pods antigos continuam Running: o serviço nunca caiu. Volte com kubectl rollout undo deployment/myapp.
6. Limpe: kubectl delete -f myapp.yaml.

Etapa 04 pacotes + values

Gerenciador de pacotes com Helm Charts

O problema

O conceito

O Helm funciona como o gerenciador de pacotes do Kubernetes (comparável ao apt ou ao yum). Um chart tem uma estrutura simples:

• `Chart.yaml`: metadados do pacote. version é a versão do *chart*; appVersion é a versão da *aplicação* empacotada. Ambas seguem SemVer, e separá-las permite evoluir o chart sem trocar o app e vice-versa.
• `values.yaml`: os valores padrão configuráveis (réplicas, imagem, porta, recursos). Tudo o que varia por ambiente fica aqui; cada ambiente usa o seu arquivo de values, com -f.
• `templates/`: os manifestos escritos como templates da linguagem Go, com funções Sprig. {{ .Values.replicaCount }} insere um valor; arquivos como _helpers.tpl concentram trechos reutilizáveis (nomes e labels).

Um template Helm se comporta como uma função: dados os mesmos values, produz o mesmo YAML, e você confere o resultado antes de aplicar com helm template. Isso dá previsibilidade e permite testar. Funções como lookup, now e randAlphaNum quebram essa regra (leem o cluster ou geram valores diferentes a cada execução), então use-as com consciência.

Ciclo de vida de uma release. Cada instalação de um chart é uma release, com nome e histórico:

• helm install cria a release e registra o estado como um Secret no namespace (sh.helm.release.v1.<nome>.v<revisão>).
• helm upgrade renderiza os templates de novo, calcula as diferenças em relação ao que está instalado, aplica só o que mudou e cria uma nova revisão. Rodar helm upgrade sem mudar nada não altera os recursos do cluster, mas o Helm registra uma nova revisão mesmo assim.
• helm rollback <release> <revisão> volta ao estado de uma revisão anterior, e o rollback também gera uma revisão nova. As revisões antigas não são alteradas, e é isso que torna o rollback confiável.

O Helm 3 não tem servidor central (o antigo Tiller foi removido). O cliente usa as credenciais do seu kubeconfig, então o RBAC do usuário limita o que o Helm consegue fazer.

Governança em escala. Charts seguem SemVer (uma mudança de versão maior indica quebra e pede revisão humana), são distribuídos por repositórios (Artifact Hub, repositórios privados) e podem ser assinados (GPG, com um arquivo .prov), o que protege a cadeia de suprimentos. Um chart deve embutir RBAC de menor privilégio (ServiceAccounts dedicadas, Roles limitadas). Subcharts permitem composição (um chart "guarda-chuva" que junta o app e o banco), e values.schema.json valida os values como um esquema de tipos. Em fluxos de GitOps (Argo CD, Flux), o chart fica no Git, a sincronização é automática e cada release vira um commit auditável.

Os conceitos-chave

Um chart mínimo, do zero

 # Chart.yaml
apiVersion: v2              # versão do formato de chart do Helm 3
name: meuapp
description: Chart de estudo
type: application
version: 0.1.0              # versão do chart
appVersion: "1.26"          # versão da aplicação empacotada (informativa)

Comandos essenciais desta etapa

Mão na massa

1. Crie a pasta meuapp/ com os três arquivos, rode helm lint ./meuapp e helm template web ./meuapp --set replicaCount=3. Observe replicas: 3 no YAML renderizado: o values foi sobrescrito sem tocar no arquivo.
2. Rode helm install web ./meuapp e kubectl get secret -l owner=helm. Observe o Secret que guarda a revisão 1.
3. Rode helm upgrade web ./meuapp --set replicaCount=3, depois helm rollback web 1 e helm history web. Observe que o rollback criou uma revisão nova (a 3) em vez de apagar a 2.
4. Rode o upgrade com --set image.tag=nao-existe --atomic --timeout 30s. Observe o erro UPGRADE FAILED ... rolled back e que kubectl get deploy web continua com os Pods antigos saudáveis.
5. Limpe: helm uninstall web.

Etapa 05 troca de ambiente inteiro

Deploy Blue/Green

O problema

O conceito

Você mantém dois ambientes de produção idênticos. O Blue é a versão atual, servindo 100% do tráfego. O Green é a versão nova, com todos os Pods prontos, mas sem tráfego. Quando o Green é validado, você troca o tráfego para ele. Se der problema, troca de volta.

No Kubernetes, os dois conjuntos de Pods são dois Deployments, com labels diferentes (env: blue e env: green, além do app comum). Um Service aponta para um deles por meio do selector. A promoção é um patch no selector do Service: o controlador de endpoints recalcula a lista de Pods do Service e o kube-proxy reconfigura o roteamento. O rollback é o patch inverso. Como os Pods antigos continuam de pé (apenas sem tráfego), a volta não exige reimplantar nada. Uma observação prática: a troca vale para as novas conexões; conexões já abertas (por exemplo, keep-alive de HTTP) podem continuar nos Pods antigos até serem encerradas.

Formalmente, é uma transição de um estado para outro com uma única operação, e o rollback é a mesma operação no sentido contrário. Se a v2 falha, o dano se limita ao tempo até a detecção: reverter na hora reduz esse tempo ao mínimo.

Armadilhas:

• Compatibilidade de dados e esquema. É o maior desafio prático. Se a Green altera o banco de forma incompatível, voltar para a Blue quebra. A solução é fazer a mudança em duas fases (padrão conhecido como expand/contract): primeiro migrar o banco para suportar as *duas* versões, validar, e só então trocar o código. Sem isso, dados escritos pela Green podem inutilizar a Blue.
• Custo. Dois ambientes completos significam cerca de 100% de capacidade extra durante a transição. Boa prática: reduzir o ambiente inativo a zero réplicas depois que a nova versão estabilizar.
• Tempestade de conexões e cache frio. Trocar 100% do tráfego de uma vez joga toda a carga sobre a Green de repente, e caches frios podem gerar um pico. Uma mitigação é aquecer a Green com tráfego sombra antes.

Antipadrão clássico: deixar de tratar a Green como produção o tempo todo. Se você acumula mudanças esperando o "momento certo" para trocar, o salto entre as versões fica grande e arriscado. Blue/Green de verdade é fazer deploy contínuo no ambiente inativo e virar a chave quando houver confiança.

Ferramentas. O Argo Rollouts suporta blueGreen de forma nativa (com serviço de preview e promoção manual ou automática por métricas); o Flagger se integra com service mesh. O padrão também é chamado de Red/Black em contextos como Netflix e Spinnaker.

Os conceitos-chave

Um Service que aponta para blue e depois para green

 # bluegreen.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-blue
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
      env: blue
  template:
    metadata:
      labels:
        app: myapp
        env: blue                     # identifica o ambiente
    spec:
      containers:
        - name: app
          image: hashicorp/http-echo:1.0
          args: ["-text=blue v1"]     # responde com este texto, na porta 5678
          ports:
            - containerPort: 5678
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-green
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
      env: green
  template:
    metadata:
      labels:
        app: myapp
        env: green
    spec:
      containers:
        - name: app
          image: hashicorp/http-echo:1.0
          args: ["-text=green v2"]
          ports:
            - containerPort: 5678
---
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
    env: blue                         # a chave: troque para green na promoção
  ports:
    - port: 80
      targetPort: 5678

Comandos essenciais desta etapa

Mão na massa

1. Aplique bluegreen.yaml, rode kubectl get endpoints myapp-service e o wget pelo Pod cliente. Observe blue v1 e apenas os 2 IPs dos Pods blue.
2. Faça a promoção com o kubectl patch do exemplo e consulte de novo. Observe green v2 e os 2 IPs dos Pods green em get endpoints, sem que nenhum Pod tenha sido criado ou removido.
3. Faça o rollback com o patch inverso e observe blue v1 de volta, porque os Pods blue continuaram existindo.
4. Escale myapp-blue para 0, rode kubectl get endpoints myapp-service e observe que, com o selector em blue, o Service ficou sem endpoints (<none>). É por isso que o desligamento do ambiente antigo só deve ser feito depois de promover e estabilizar o novo.
5. Limpe: kubectl delete -f bluegreen.yaml.

Etapa 06 tráfego progressivo

Deploy canário

O problema

O conceito

No canário, você mantém as duas versões rodando e transfere o tráfego aos poucos (por exemplo, 1%, 5%, 25%, 50% e 100%), validando métricas reais a cada passo. Se algo degrada, o impacto ficou restrito aos poucos por cento e você reverte. Em contraste, Blue/Green é "tudo ou nada"; o canário é progressivo.

Duas formas de dividir o tráfego:

1. Por proporção de réplicas, de forma nativa. Dois Deployments com um label em comum (por exemplo app: myapp), e um Service que seleciona só por esse label. O Service distribui as requisições entre todos os Pods, então 4 Pods estáveis e 1 canário resultam em cerca de 20% do tráfego no canário. É simples, não exige nada além do Kubernetes, mas a granularidade depende do número de réplicas (para 1% você precisaria de 100 Pods).
2. Por peso, com service mesh ou ingress com suporte a peso. Com Istio ou Linkerd, ou com um ingress controller compatível, você define percentuais exatos (por exemplo 90% e 10%), independentes do número de réplicas. No Istio, um VirtualService divide o tráfego entre *subsets* (v1 e v2), que são declarados em um DestinationRule a partir de labels dos Pods.

Decisão guiada por métricas. O que decide promover ou reverter são métricas em tempo real: taxa de erro (5xx), latência (p95 e p99, as latências abaixo das quais ficam 95% e 99% das requisições), uso de recursos, métricas de negócio. Isso fecha um laço de realimentação que pode ser automatizado: se o erro do canário fica abaixo do limite, aumenta o peso; se viola, volta para a v1.

Ferramentas. O Argo Rollouts e o Flagger implementam os passos (pesos, pausas, análises) como objetos do Kubernetes. No Argo Rollouts, o objeto Rollout substitui o Deployment e declara a estratégia em steps. Sem um roteador de tráfego configurado (trafficRouting), o setWeight é aproximado por meio do número de réplicas, igual à técnica nativa; com Istio ou um ingress compatível, o peso é exato.

Vocabulário de teoria, para saber que existe:

• Teste A/B contínuo: o canário é um experimento estatístico entre a v1 (controle) e a v2. A hipótese nula é "não há diferença"; avalia-se com testes de significância (teste z de proporções, qui-quadrado, Mann-Whitney). O Kayenta, usado com o Spinnaker na Netflix, faz análise de canário com o teste de Mann-Whitney.
• Testes sequenciais (SPRT de Wald): avaliam continuamente e param cedo quando há evidência suficiente para promover ou abortar, reduzindo a exposição dos usuários.
• Teoria de filas: mesmo 10% do tráfego pode degradar a latência se esses 10% quase saturam os poucos Pods da v2. O tempo de espera cresce muito rápido perto da saturação, o que também serve para estimar se a v2 aguenta 100%.
• Multi-armed bandits (Thompson Sampling): alocam tráfego de forma adaptativa, equilibrando testar e favorecer a melhor versão.

Casos relatados. O material de origem cita a Shopify (cerca de 5% do tráfego por alguns minutos, com análise automática antes de ir a 100%), a Netflix (canary analysis automatizada com Kayenta no Spinnaker) e o Nubank (feature flags combinadas com canário). Os números exatos vêm do relato original e não foram verificados aqui. A tendência é guiar o canário por SLOs (frear se a meta de erro for violada).

Os conceitos-chave

Exemplos comentados

 # canario.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-stable
spec:
  replicas: 4                         # 4 de 5 Pods: cerca de 80% do tráfego
  selector:
    matchLabels:
      app: myapp
      track: stable
  template:
    metadata:
      labels:
        app: myapp                    # label comum, usado pelo Service
        track: stable                 # label que distingue a versão
    spec:
      containers:
        - name: app
          image: hashicorp/http-echo:1.0
          args: ["-text=v1 estavel"]
          ports:
            - containerPort: 5678
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-canary
spec:
  replicas: 1                         # 1 de 5 Pods: cerca de 20% do tráfego
  selector:
    matchLabels:
      app: myapp
      track: canary
  template:
    metadata:
      labels:
        app: myapp
        track: canary
    spec:
      containers:
        - name: app
          image: hashicorp/http-echo:1.0
          args: ["-text=v2 canario"]
          ports:
            - containerPort: 5678
---
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp                        # sem o label "track": o Service enxerga os dois Deployments
  ports:
    - port: 80
      targetPort: 5678

Comandos essenciais desta etapa

Mão na massa

1. Aplique canario.yaml e rode kubectl get endpoints myapp. Observe os 5 endpoints (4 estáveis e 1 canário).
2. Rode o laço de 20 requisições com o Pod cliente. Observe a contagem aproximada de 80% para v1 estavel e 20% para v2 canario. Rode de novo e observe que os números mudam: a divisão é estatística, não exata.
3. Aborte o canário com kubectl scale deployment myapp-canary --replicas=0 e repita o laço. Observe que só v1 estavel responde.
4. Reflita sobre o limite da técnica: para um canário de 1%, quantas réplicas seriam necessárias? Esse é o motivo de existirem service mesh e Argo Rollouts com roteamento por peso.
5. Limpe: kubectl delete -f canario.yaml.

Etapa 07 escala de nós

Escalabilidade de nós com Karpenter

O problema

O conceito

O Karpenter (criado pela AWS, open source, com providers para outras nuvens) provisiona nós sob demanda, dimensionados para os Pods que estão pendentes, sem grupos fixos. Reage em segundos a poucos minutos, escolhe o tipo de instância mais adequado (incluindo Spot) e remove nós ociosos sozinho. Empresas relatam economias de até 30% em custo de computação, valor que depende do ambiente.

O fluxo de provisionamento:

1. Pods ficam unschedulable: o scheduler não encontrou nó (Pending, com o evento FailedScheduling).
2. O Karpenter observa esses Pods e soma as requisições de recursos deles.
3. Calcula que tipo de instância acomoda melhor o conjunto, dentro das regras do NodePool.
4. Provisiona o nó (via um NodeClaim), e os Pods são agendados nele.

O fluxo inverso, a consolidação: o Karpenter identifica nós subutilizados, move os Pods para outros nós e remove o nó que sobrou, ou troca uma instância cara por uma mais barata. A consolidação espera um tempo configurável (consolidateAfter) antes de agir, para não reagir a oscilações curtas.

Configuração em dois objetos:

• NodePool: define as regras dos nós que o Karpenter pode lançar (tipos de instância permitidos, zonas, Spot ou On-Demand, limites de recursos). Versões antigas chamavam esse objeto de Provisioner. A recomendação é restringir o mínimo possível, para dar liberdade de otimização.
• EC2NodeClass (na AWS): define o que é específico do provedor (AMI, sub-redes, security groups, IAM role dos nós). O NodePool aponta para ele por nodeClassRef.

O problema de fundo é bin packing multidimensional (cada Pod é um item com um vetor de CPU e memória, e cada nó é um recipiente), que é NP-difícil. O Karpenter usa heurística gulosa: descarta tipos que não servem (sem GPU quando o Pod pede GPU, zona errada), ordena por custo e adequação e busca uma solução com pouca sobra, parecida com First-Fit Decreasing. A diferença-chave para o Cluster Autoscaler é o right-sizing: nó pequeno para Pod pequeno, nó grande quando chegam Pods grandes, misturando tipos conforme a necessidade.

Custos e Spot. Instâncias Spot custam bem menos que On-Demand (a ordem de 70% a 90% de desconto, conforme o tipo e o momento), mas o provedor pode retirá-las com aviso curto (2 minutos na AWS). O Karpenter lida com isso com interrupção proativa: detecta o aviso, marca o nó como terminando, aplica taint e drena os Pods para outro nó antes do corte. Duas precisões importantes:

• Para disrupções voluntárias (consolidação, drift, expiração), o Karpenter respeita os PodDisruptionBudgets e não derruba Pods além do que o orçamento permite.
• A interrupção Spot é involuntária: o provedor vai retirar a máquina de qualquer forma, e o prazo de 2 minutos pode não bastar para drenar tudo. Por isso, o PDB reduz o risco, mas não o elimina.

Boas práticas: PDB para limitar quantos Pods saem juntos, Topology Spread para distribuir réplicas entre nós e zonas, e NodePools separados para cargas críticas (On-Demand) e cargas tolerantes a interrupção (Spot).

Casos relatados. O material de origem cita o Mercado Livre (uso do Karpenter para misturar tipos de instância e usar Spot e capacidade reservada, eliminando dezenas de grupos de nós) e a Tinybird (corte de cerca de 20% da conta AWS, 90% no ambiente de CI, ao consolidar tudo em dois NodePools: um crítico On-Demand e outro stateless 100% Spot). Os números vêm do relato original.

Os conceitos-chave

Exemplos comentados

 # nodepool.yaml
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]      # permite os dois; o Karpenter prioriza Spot quando é possível
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
      nodeClassRef:                          # em v1 o nodeClassRef precisa de group, kind e name
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  limits:
    cpu: "1000"                              # teto de CPU somada dos nós deste NodePool
    memory: 1000Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized   # consolida nós vazios ou subutilizados
    consolidateAfter: 30s                    # espera 30s antes de agir
---
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: default
spec:
  role: "KarpenterNodeRole-meu-cluster"      # IAM role dos nós (marcador)
  amiSelectorTerms:
    - alias: al2023@latest                   # AMI Amazon Linux 2023
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: meu-cluster  # descobre as sub-redes por tag
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: meu-cluster

Comandos essenciais desta etapa

Mão na massa

1. Aplique pod-grande.yaml no Minikube e rode kubectl get pods. Observe o Pod em Pending.
2. Rode kubectl describe pod -l app=grande e observe em Events a mensagem FailedScheduling com Insufficient cpu. Esse é o sinal que o Karpenter usa para decidir criar um nó.
3. Rode kubectl get nodes -L karpenter.sh/capacity-type e observe a coluna vazia: nenhum nó foi provisionado pelo Karpenter, o que confirma que ele não está instalado.
4. Leia o NodePool do exemplo e responda: o que acontece se limits.cpu for atingido? (Resposta: o Karpenter não cria novos nós nesse NodePool e os Pods seguem Pending.)
5. Limpe: kubectl delete -f pod-grande.yaml.

Etapa 08 escala por eventos

Escalabilidade de aplicações com KEDA

O problema

O conceito

O KEDA (Kubernetes Event-driven Autoscaler) escala com base em eventos externos: filas (RabbitMQ, SQS, Kafka, Redis), métricas do Prometheus, cron, entre outros, e suporta scale-to-zero.

O objeto central é o ScaledObject. Ele aponta para um Deployment alvo e define um ou mais triggers. Como funciona na prática:

1. O KEDA consulta a fonte do trigger a cada pollingInterval segundos.
2. Fila vazia: mantém o Deployment em 0 réplicas (se minReplicaCount: 0).
3. Chega um evento: o KEDA ativa o Deployment (de 0 para 1).
4. A partir de 1, quem calcula o número de réplicas é um HPA que o próprio KEDA cria: por exemplo, com value: "10" no modo QueueLength, 40 mensagens resultam em 4 Pods.
5. A fila fica vazia e permanece assim por cooldownPeriod segundos: o KEDA leva o Deployment de volta a 0.

Três pontos de precisão. Primeiro, o HPA sozinho não consegue ir a zero (o mínimo é 1), então a ativação de 0 para 1 e o retorno a 0 são responsabilidades do KEDA. Segundo, o cooldownPeriod (padrão 300 segundos) conta o tempo em que o gatilho está inativo (fila vazia) e só vale para a ida a zero. Terceiro, a diferença entre as duas formas de descer: quando o gatilho fica inativo, o KEDA zera o Deployment direto, de qualquer número de réplicas (de 4 para 0, por exemplo), ao fim do cooldownPeriod; já a janela de estabilização de scale down do HPA (padrão de 5 minutos, ajustável no ScaledObject em advanced.horizontalPodAutoscalerConfig.behavior) vale para reduções enquanto a fila ainda está ativa, como ir de 5 para 3 réplicas com a fila diminuindo, mas ainda com itens.

Teoria de filas. Chamando de λ a taxa de chegada de eventos e de μ a taxa com que cada Pod processa, com c Pods a capacidade é c·μ. A condição de estabilidade é λ < c·μ: se a chegada for sustentadamente maior que a capacidade, a fila cresce sem limite e nenhum autoscaling resolve. A Lei de Little (L = λ·W) relaciona o número médio de itens no sistema L, a taxa de chegada λ e o tempo médio no sistema W: se o backlog cresce com λ constante, W está aumentando, ou seja, faltam Pods.

Oscilação. Um desafio de controle é evitar o sobe e desce de réplicas, causado pelo atraso da realimentação (um Pod novo leva tempo para ficar pronto) e por limiares fixos. Mecanismos que o HPA e o KEDA oferecem: uma tolerância (o HPA padrão só reage quando a métrica passa de cerca de 110% ou cai abaixo de cerca de 90% do alvo, uma margem de 10%), janelas de estabilização e o cooldownPeriod. Um conceito geral de controle é a banda morta (escalar para cima em um limiar e para baixo em outro, mais baixo); ele ilustra a ideia de histerese, mas não é uma configuração direta do HPA ou do KEDA, que usam tolerância e janelas. Como filas absorvem rajadas, aceita-se um backlog temporário enquanto os Pods novos sobem.

O KEDA é independente de provedor (AKS, EKS, GKE, on-premises) e complementa o HPA, sem substituí-lo. Um caso típico: workers de pedidos escalados pela fila do SQS ou do Service Bus em promoções relâmpago, voltando a zero na madrugada. Para fontes de eventos que o KEDA não suporta, existem scalers externos via gRPC.

Os conceitos-chave

Exemplos comentados

 # scaledobject-rabbitmq.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: worker-scaler
spec:
  scaleTargetRef:
    name: worker               # Deployment alvo
  minReplicaCount: 0           # permite scale-to-zero
  maxReplicaCount: 5
  cooldownPeriod: 60           # fila vazia por 60s antes de ir a zero
  pollingInterval: 15          # consulta a fila a cada 15s
  triggers:
    - type: rabbitmq
      metadata:
        queueName: pedidos
        protocol: amqp
        mode: QueueLength      # escala pelo tamanho da fila
        value: "10"            # um Pod para cada 10 mensagens
        hostFromEnv: RABBITMQ_URL   # variável com a URL do broker, definida no container do Deployment alvo

Comandos essenciais desta etapa

Mão na massa

1. Instale o KEDA com o Helm e aplique keda-lab.yaml. Rode kubectl get scaledobject e observe READY True e ACTIVE False (nenhum trabalho).
2. Rode kubectl get deployment worker e observe 0/0: o worker foi a zero, algo que o HPA sozinho não faz.
3. Em um segundo terminal, rode kubectl get deployment worker -w. No primeiro, empurre 20 itens com LPUSH. Observe o número de réplicas subir até 4, e confira com kubectl get hpa o HPA criado pelo KEDA.
4. Apague a fila com redis-cli DEL fila e observe o Deployment ir de 4 réplicas direto para 0 depois de cerca de 30 segundos (o cooldownPeriod do exercício). Isso é mais rápido que os 5 minutos de estabilização do HPA porque, com a fila vazia, o gatilho fica inativo e o KEDA zera o Deployment sem passar pela descida gradual; a janela do HPA só valeria se a fila estivesse diminuindo, mas ainda com itens.
5. Empurre 100 itens e observe o limite maxReplicaCount: 5: mesmo com a fila pedindo 20 Pods, o KEDA respeita o teto.
6. Limpe: kubectl delete -f keda-lab.yaml e helm uninstall keda -n keda.

Etapa 09 rbac + identidade + tls

Segurança no cluster

O problema

O conceito

Identidade: ServiceAccounts. Cada aplicação deve ter a sua própria ServiceAccount, nunca a default do namespace. A ServiceAccount dá ao Pod um token para falar com o API Server. Identidades separadas por aplicação permitem delimitar o estrago quando um Pod é comprometido. Se a aplicação nunca fala com o API Server, desligue até a montagem do token com automountServiceAccountToken: false.

Autorização: RBAC. Permissões são concedidas por Roles (restritas a um namespace) ou ClusterRoles (em todo o cluster) e ligadas a sujeitos por RoleBindings (ou ClusterRoleBindings). O modelo é um grafo: sujeito, binding, role e permissão. Regras de menor privilégio:

• Prefira Role (namespaced) a ClusterRole.
• Conceda só os verbos necessários (get, list) e só os recursos necessários.
• Evite o curinga * em verbos e recursos.

O RBAC do Kubernetes é aditivo: só existem regras que dão permissão, não há regras de negação, e o que não foi concedido está negado. Isso o torna auditável: é possível listar de forma determinística quem pode fazer o quê. O ABAC (baseado em atributos) é mais expressivo, porém opaco, e é um mecanismo legado, raramente usado. Para políticas condicionais ("negar Pod sem limits", "só aceitar imagens de determinado registro"), usa-se um mecanismo de admission como OPA/Gatekeeper, com a linguagem Rego (política como código), ou os recursos nativos de admission policy do Kubernetes. Quanto mais expressiva a política, mais difícil provar suas propriedades.

Identidade federada com a nuvem. Aplicações precisam acessar S3, buckets e cofres de segredos sem embutir chaves estáticas no container. A solução é federar a ServiceAccount do Kubernetes com uma identidade da nuvem por meio de OIDC, recebendo credenciais de curta duração:

• IRSA (IAM Roles for Service Accounts) no EKS: a ServiceAccount recebe uma annotation com o ARN de uma IAM Role. Cada aplicação tem a sua Role, com o mínimo necessário. (O EKS também oferece o EKS Pod Identity como alternativa mais recente.)
• Workload Identity no GKE e no AKS: a ServiceAccount é associada a uma identidade de nuvem (conta de serviço no GKE, identidade gerenciada no AKS).

Isso elimina segredos estáticos e restringe a credencial ao contexto do Pod. O mesmo princípio vale para o IAM: o ataque conhecido como SCARLETEEL (2023, documentado pela Sysdig) usou credenciais obtidas de containers para se mover em ambientes de nuvem, e o episódio reforça a lição de manter permissões do IAM no mínimo e não deixar segredos estáticos nos Pods.

TLS automatizado: cert-manager. Gerenciar certificados à mão não escala: eles expiram e ficam inconsistentes. O cert-manager automatiza o ciclo de vida por CRDs: Issuer e ClusterIssuer (quem emite: autoassinado, CA interna, ACME/Let's Encrypt, Vault) e Certificate (o que emitir, com nome, SANs, duração e renewBefore para renovação antecipada). Ele gera a requisição, obtém a assinatura, preenche um Secret com tls.crt e tls.key e renova sozinho. O certificado é X.509, parte de uma cadeia de confiança que termina em uma CA raiz. O próprio Kubernetes usa mais de uma CA (etcd, API server, front-proxy) para compartimentalizar: se uma vaza, as outras seguem intactas.

Rotação de segredos. Segredos devem ser trocados para reduzir a janela de exposição. Uma troca instantânea é impraticável em sistemas distribuídos (não há bloqueio global), então usa-se um período de convivência: a credencial nova e a antiga valem ao mesmo tempo até todos migrarem, e então a antiga é invalidada. Segredos dinâmicos (Vault, tokens curtos) já são efêmeros e quase dispensam rotação. Na rotação da chave de criptografia do etcd, todos os API servers precisam conhecer a nova chave *antes* de ela passar a ser usada para escrever, senão um API server que não a conhece não consegue ler os dados gravados com ela.

Os conceitos-chave

Exemplos comentados

 # rbac-analytics.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: analytics-sa
  namespace: analytics
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/S3Reader   # IRSA: só funciona no EKS; ARN fictício
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role                             # restrita ao namespace, não é ClusterRole
metadata:
  name: analytics-read
  namespace: analytics
rules:
  - apiGroups: [""]                    # grupo "core" da API
    resources: ["pods"]
    verbs: ["get", "list"]             # só leitura, sem "*"
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: bind-analytics-read
  namespace: analytics
roleRef:                               # qual Role
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: analytics-read
subjects:                              # para quem
  - kind: ServiceAccount
    name: analytics-sa
    namespace: analytics

Comandos essenciais desta etapa

Mão na massa

1. Crie o ambiente de teste de RBAC: kubectl create namespace lab, kubectl create serviceaccount leitor -n lab, kubectl create role ler-pods --verb=get,list --resource=pods -n lab e kubectl create rolebinding bind-leitor --role=ler-pods --serviceaccount=lab:leitor -n lab.
2. Teste com kubectl auth can-i list pods -n lab --as=system:serviceaccount:lab:leitor. Observe yes.
3. Teste delete pods e get secrets (que não foram concedidos). Observe no nos dois. Teste também list pods -n default: observe no, porque a Role só vale no namespace lab.
4. Aplique rbac-analytics.yaml (depois de criar o namespace analytics) e rode kubectl create token analytics-sa -n analytics. Observe que o token é gerado na hora, com validade limitada, em vez de uma credencial permanente.
5. Instale o cert-manager, aplique pki.yaml e rode kubectl get certificate. Observe READY True nos dois certificados e confira com o openssl o issuer do certificado do serviço (o openssl precisa estar instalado na sua máquina; sem ele, use kubectl describe certificate service-a-cert). Isso demonstra a emissão automática; a renovação acontece sozinha, renewBefore antes do vencimento.
6. Leia o exemplo de IRSA sem executar e liste o que faltaria para funcionar (cluster EKS, provedor OIDC, IAM Role com a relação de confiança com a ServiceAccount).
7. Limpe: kubectl delete namespace lab analytics, kubectl delete -f pki.yaml, kubectl delete secret ca-interna-tls service-a-tls (o cert-manager não apaga por padrão os Secrets que criou) e helm uninstall cert-manager -n cert-manager.

Etapa 10 bônus · podinfo em produção

Bônus, o podinfo do módulo básico vai para produção

O problema

O conceito

Esta etapa transforma os manifestos da Etapa 09 do básico em um chart Helm e reforça o Deployment com as peças deste guia. Cada peça vem da etapa que a ensinou:

• Helm (Etapa 04): o ConfigMap, o Service e o HPA entram no chart sem mudanças relevantes, como templates. O mesmo chart serve dev, staging e produção, trocando apenas o arquivo de values.
• ServiceAccount mínima (Etapa 09): o podinfo ganha uma ServiceAccount própria. Ele é um servidor HTTP que nunca chama o API Server, então não recebe nenhum Role nem RoleBinding, e o token nem é montado no Pod (automountServiceAccountToken: false). É o menor privilégio levado ao limite: nenhuma credencial onde nenhuma é necessária.
• Sem limit de CPU (Etapa 01): o podinfo é sensível a latência, então o chart mantém requests de CPU e memória e um limit só de memória, para evitar throttling. O Pod fica Burstable.
• Topology Spread (Etapa 02): espalha as réplicas entre nós com maxSkew: 1, para que a queda de um nó não leve todas as réplicas. Em produção multi-nó, use DoNotSchedule; no Minikube, de um nó só, ScheduleAnyway, porque DoNotSchedule deixaria as réplicas além da primeira em Pending para sempre.
• PodDisruptionBudget (Etapa 02): garante um piso de réplicas durante disrupções voluntárias (drain, upgrade de nó, consolidação do Karpenter). Como visto na Etapa 02, ele não protege contra despejo por pressão de recursos.
• Rollout ajustado (Etapa 03): maxUnavailable: 0 para nunca reduzir a capacidade, maxSurge: 1 para criar um Pod extra por vez, minReadySeconds e a annotation change-cause para registrar cada troca.
• Canário (Etapa 06): uma segunda release do mesmo chart, com 1 réplica e a versão nova, recebe uma fração do tráfego do mesmo Service (a técnica nativa por proporção de réplicas). A promoção é um helm upgrade --atomic.

Por que o chart precisa distinguir o canário. Duas releases do mesmo chart não podem criar objetos com o mesmo nome (o Helm recusa, porque o objeto pertence a outra release). Por isso, o nome do Deployment vem de .Release.Name, e Service, ConfigMap, HPA, ServiceAccount e PDB só são criados pela release estável (canary: false). Os Pods distinguem a versão com um label track (stable ou canary), usado no selector de cada Deployment, para que dois Deployments não disputem os mesmos Pods. O Service seleciona só por app: podinfo, então enxerga os dois.

O que fica de fora, e por quê:

• Karpenter e IRSA ou Workload Identity são conceitos de nuvem, sem efeito num Minikube de um nó; ficam só na leitura das Etapas 07 e 09.
• cert-manager: sem ingress com TLS neste laboratório, não há o que emitir ou renovar.
• KEDA: o HPA que já existe cobre o perfil do podinfo, uma API HTTP que não deve ir a zero; o scale-to-zero por fila faz sentido para workers de fila.
• Blue/Green: para um único Service público, escolhe-se uma estratégia de promoção. O canário, progressivo e guiado por métricas, combina melhor com um serviço que já expõe /healthz e /readyz.
• PVC: continua fora, pelo mesmo motivo do guia básico (volume ReadWriteOnce compartilhado entre várias réplicas).
• podAntiAffinity: o chart segue o conselho da Etapa 02 e usa Topology Spread em vez de afinidade entre Pods.

Os conceitos-chave

Exemplos comentados

 # Chart.yaml
apiVersion: v2
name: podinfo
description: podinfo em formato de produção
type: application
version: 0.1.0                     # versão do chart
appVersion: "6.14.1"               # versão da aplicação

Comandos essenciais desta etapa

Mão na massa

1. Monte a pasta podinfo-chart/ com Chart.yaml, values.yaml e os seis arquivos de templates/. Rode helm lint ./podinfo-chart e helm template podinfo ./podinfo-chart e observe o YAML renderizado, com o Deployment, o Service, o HPA, a ServiceAccount e o PDB.
2. Rode helm template podinfo-canary ./podinfo-chart --set canary=true e observe que só o Deployment aparece como objeto (com nome podinfo-canary e track: canary); os outros arquivos aparecem vazios ou só com o comentário da primeira linha, sob # Source:. É isso que evita colisão de nomes entre as duas releases.
3. Confira as tags com docker manifest inspect stefanprodan/podinfo:6.14.1 e docker manifest inspect stefanprodan/podinfo:6.15.0. Com as duas confirmadas, instale a produção: helm install podinfo ./podinfo-chart -n podinfo --create-namespace, e confirme 3 Pods Running com kubectl get pods -n podinfo -o wide.
4. Rode as três chamadas kubectl auth can-i para podinfo-sa. Observe no nas três: o app não tem motivo para chamar o API Server, então não recebeu credencial alguma.
5. Rode kubectl get pdb podinfo -n podinfo e observe ALLOWED DISRUPTIONS 1 (3 Pods saudáveis, mínimo de 2).
6. Suba o canário com helm install podinfo-canary ... --set canary=true --set replicaCount=1 --set image.tag=6.15.0 e observe em kubectl get endpoints podinfo -n podinfo os 4 IPs, um deles com a versão nova servindo tráfego real.
7. Promova com helm upgrade podinfo ... --set image.tag=6.15.0 --atomic, remova o canário com helm uninstall podinfo-canary -n podinfo e confirme em kubectl rollout history deployment/podinfo -n podinfo que a troca ficou registrada.
8. Limpe as duas releases: o canário já saiu no passo 7, então rode helm uninstall podinfo -n podinfo e kubectl delete namespace podinfo.

Etapa 11 · revisão

Checklist de autoavaliação

Próximos passos: com todos os itens marcados, refaça a Etapa 10 do zero sem consultar o guia, desta vez num perfil do Minikube com vários nós (como o da Etapa 02) e com whenUnsatisfiable: DoNotSchedule, e confira a distribuição das réplicas com kubectl get pods -o wide. Depois, se tiver acesso a uma conta de nuvem de teste, execute os trechos que aqui foram só leitura: o NodePool do Karpenter, o IRSA ou o Workload Identity e o canário com peso exato do Istio ou do Argo Rollouts.