Figura 1 — Kubernetes relacionando desired state, control plane, Worker Nodes e serviço observável.

Prefácio

O roadmap fornecido organiza os principais assuntos de Kubernetes: containers, instalação, Pods, controllers, configuração, services, networking, security, resource management, observability, storage, scheduling, autoscaling, deployment patterns, extensões e operações de cluster. Como mapa, ele indica a direção. Como formação técnica, deixa perguntas essenciais sem resposta: quem reconcilia o estado, como uma requisição encontra um Pod, o que acontece durante um OOMKill, por que um Secret não é automaticamente seguro e como recuperar um cluster cujo etcd foi perdido.

Este estudo transforma o mapa em uma trajetória de engenharia. Kubernetes é tratado como um sistema distribuído orientado por APIs declarativas, não como uma coleção de comandos kubectl. Cada recurso será relacionado ao problema que resolve, à falha que pode introduzir e à evidência necessária para operá-lo.

Em 4 de setembro de 2026, a versão corrente é Kubernetes v1.37, lançada em 26 de agosto de 2026 com 67 enhancements. Recursos Alpha, Beta, GA, APIs e defaults mudam entre releases; por isso, todo manifesto crítico deve ser confrontado com a documentação correspondente à versão real do cluster [1–2].

Tese central: Kubernetes não torna uma aplicação confiável por hospedá-la. Ele fornece mecanismos para declarar, observar e reconciliar estado. Confiabilidade surge quando a aplicação, a plataforma e a operação usam esses mecanismos de forma coerente.

Como estudar este material

Use quatro perspectivas simultâneas:

1. Modelo mental: API, desired state, reconciliation loop, control plane e data plane.
2. Desenvolvimento: imagem, configuração, probes, recursos, rollout e observabilidade.
3. Plataforma: networking, storage, security, policy, scheduling e autoscaling.
4. Operação: incidentes, capacity, backup, upgrade, disaster recovery e custo.

Os exemplos usam YAML e comandos reproduzíveis, mas não devem ser aplicados diretamente em produção. Pratique em cluster local, namespace exclusivo e repositório versionado. Antes de qualquer comando, confira o contexto:

kubectl config current-context
kubectl cluster-info
kubectl auth can-i --list --namespace laboratorio

Objetivos de aprendizagem

Ao final, você deverá conseguir:

• explicar control plane, worker node e reconciliation loop;
• distinguir container, Pod, ReplicaSet, Deployment, StatefulSet, DaemonSet, Job e CronJob;
• construir manifestos com labels, selectors, resources, probes e security context;
• explicar o caminho de rede de um cliente até um container;
• escolher entre Service, Ingress e Gateway API;
• aplicar ConfigMaps, Secrets e external secret management com limites claros;
• raciocinar sobre requests, limits, QoS, scheduling, preemption e eviction;
• escolher StorageClass, PV, PVC, StatefulSet e estratégia de backup;
• implementar least privilege com RBAC, ServiceAccounts, Pod Security e NetworkPolicy;
• correlacionar Events, logs, metrics e traces durante troubleshooting;
• comparar HPA, VPA e Cluster Autoscaler;
• estruturar Helm, Kustomize, CI/CD e GitOps;
• compreender CRDs, controllers e Operator pattern;
• decidir entre cluster managed e self-managed;
• planejar upgrade, backup de etcd, high availability e disaster recovery.

Capítulo 1 — Por que Kubernetes existe

1.1 Do container isolado ao sistema distribuído

Um container empacota processo, filesystem e dependências. Ele não decide em qual servidor deve executar, não recria a si mesmo após falha da máquina, não distribui tráfego, não atualiza várias réplicas com segurança e não mantém uma API global de estado.

Kubernetes é um sistema open source para automatizar deployment, scaling e management de aplicações em containers [1]. Seu problema central é coordenação: muitas cargas, máquinas, versões, identidades e dependências mudando ao mesmo tempo.

1.2 O que Kubernetes fornece

• API declarativa e extensível;
• scheduling de Pods em Nodes;
• controllers que reconciliam desired state;
• service discovery e abstração de endpoints;
• rollout e rollback de workloads;
• integração com networking e storage por plugins;
• primitives de configuração, identidade, policy e isolamento;
• sinais de estado para observabilidade e automação.

1.3 O que Kubernetes não fornece sozinho

Kubernetes não inclui automaticamente:

• pipeline CI/CD;
• registry privado;
• estratégia de backup da aplicação;
• banco altamente disponível;
• observability stack completa;
• secrets manager externo;
• segurança de supply chain;
• SLO, runbook e processo de incidente;
• arquitetura correta do software.

O cluster é uma plataforma de primitives. A organização compõe controllers, plugins e processos sobre essas primitives.

1.4 Quando usar

Kubernetes é coerente quando existem múltiplos serviços ou equipes, necessidade de portabilidade, automação consistente, scaling variável, workloads heterogêneos e capacidade para operar a plataforma.

1.5 Quando não usar

Uma aplicação pequena, estável e mantida por uma equipe reduzida pode ser mais simples em VM, container host, Platform as a Service ou serviço serverless. Se a equipe não consegue manter imagens, observabilidade, backup e segurança, adicionar Kubernetes aumenta failure modes antes de gerar valor.

Exercícios

1. Liste três problemas que Docker sozinho não resolve em um cluster.
2. Compare uma aplicação Flask única em VM e em Kubernetes.
3. Identifique um cenário em que Kubernetes seria complexidade sem retorno.

Nota Zettelkasten — ZK-K8S-001

Título: Kubernetes como sistema de coordenação

Kubernetes coordena estado desejado, placement, rede, storage e lifecycle de workloads; ele não substitui arquitetura, segurança ou operação.

Capítulo 2 — Containers, imagens e runtime

2.1 Imagem não é container

Uma image é um artefato imutável composto por layers e metadata. Um container é uma execução dessa imagem com isolamento de namespaces, controle de recursos por cgroups e filesystem gravável efêmero.

O mesmo digest identifica o mesmo conteúdo. Uma tag como app:latest pode apontar para conteúdo diferente ao longo do tempo. Produção deve preferir versão imutável e, quando necessário, digest:

image: registry.example.com/portal@sha256:3a1f...c92d

2.2 OCI, CRI e runtime

• OCI padroniza formatos de image e runtime;
• CRI é a interface entre kubelet e container runtime;
• runtimes como containerd ou CRI-O criam containers;
• Kubernetes não usa Docker Engine como requisito para Nodes modernos.

O kubelet pede ao runtime que faça pull da image e crie o sandbox do Pod. Essa separação permite trocar implementações sem alterar a API do workload.

2.3 Construção para Kubernetes

Uma boa image:

• possui base mínima e atualizada;
• executa como usuário sem privilégio;
• não contém secret;
• expõe processo em foreground;
• responde corretamente a SIGTERM;
• grava logs em stdout e stderr;
• possui Software Bill of Materials quando exigido;
• é escaneada e assinada no pipeline;
• não depende de escrita em filesystem de root.

2.4 Multi-stage build

FROM python:3.13-slim AS builder
WORKDIR /build
COPY requirements.txt .
RUN pip wheel --no-cache-dir --wheel-dir /wheels -r requirements.txt

FROM python:3.13-slim
RUN useradd --system --uid 10001 appuser
WORKDIR /app
COPY --from=builder /wheels /wheels
RUN pip install --no-cache-dir /wheels/* && rm -rf /wheels
COPY app ./app
USER 10001
CMD ["gunicorn", "--bind=0.0.0.0:8000", "app:create_app()"]

Esse exemplo reduz dependências de build na image final, mas ainda exige pinning, scan, provenance e teste.

2.5 Processo principal e graceful shutdown

Quando um Pod termina, o kubelet sinaliza o processo. Se a aplicação ignora SIGTERM, requisições podem ser interrompidas no fim do grace period. O processo PID 1 deve propagar sinais, parar de aceitar novas conexões e finalizar trabalho em andamento dentro de um limite conhecido.

Exercícios

1. Explique por que tag mutável prejudica rollback e auditoria.
2. Revise um Dockerfile e identifique privilégios e artefatos desnecessários.
3. Desenhe um graceful shutdown para uma API com requests de até 20 segundos.

Nota Zettelkasten — ZK-K8S-002

Título: Imagem como unidade de supply chain

Uma image confiável é imutável, mínima, rastreável, testada e executável sem privilégio; o cluster não corrige uma image insegura.

Capítulo 3 — Arquitetura do cluster

3.1 Control plane e worker nodes

Figura 2 — Componentes do control plane e do Worker Node, com responsabilidades separadas.

O cluster separa decisão global de execução local [3]:

3.2 API server como centro

Componentes não formam uma cadeia rígida de chamadas. Eles observam objetos pela API, registram estado e reagem. O API server aplica autenticação, autorização, admission e validação antes de persistir.

3.3 etcd e quorum

etcd é um key-value store distribuído. Alta disponibilidade requer número ímpar de membros e latência previsível entre eles. Três membros toleram a perda de um; cinco toleram a perda de dois. Adicionar membros aumenta tolerância, mas também custo de consenso.

Uma forma simples de expressar o quorum é:

onde N é o total de membros e Q é o mínimo que precisa concordar. Para N = 3, Q = 2.

Backup de volumes da aplicação não substitui snapshot de etcd; snapshot de etcd não substitui backup consistente dos dados da aplicação.

3.4 Node não é Pod

Node é máquina física ou virtual registrada no cluster. Pod é unidade agendada sobre um Node. Se o Node se torna indisponível, o control plane atualiza sua condição e pode iniciar eviction dos Pods após os tempos configurados [4].

3.5 Add-ons

DNS, Metrics Server, Ingress/Gateway controller, observability agents e storage provisioners normalmente são add-ons. Eles não devem ser confundidos com todos os componentes core.

Exercícios

1. Trace o que ocorre desde kubectl apply até o container iniciar.
2. Calcule o quorum para 1, 3, 5 e 7 membros de etcd.
3. Explique por que um Node Ready não prova que a aplicação está saudável.

Nota Zettelkasten — ZK-K8S-003

Título: Control plane orientado pela API

Kubernetes coordena componentes independentes por meio de objetos persistidos e observados na API; o sistema converge sem depender de uma única sequência síncrona.

Capítulo 4 — API declarativa e Reconciliation Loop

4.1 Desired state e current state

Figura 3 — Reconciliation Loop comparando desired state e current state até convergir ou registrar degradação.

Um manifesto declara intenção. O controller compara desired state e current state, executa uma ação e observa novamente. Esse Reconciliation Loop torna o sistema resiliente a falhas temporárias e mudanças concorrentes.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: portal
  namespace: laboratorio
spec:
  replicas: 3
  selector:
    matchLabels:
      app: portal
  template:
    metadata:
      labels:
        app: portal
    spec:
      containers:
        - name: web
          image: registry.example.com/portal:1.4.2

O arquivo não diz “crie Pod A, depois B”. Declara três réplicas que correspondem a um selector. O Deployment controller e o ReplicaSet controller convergem para esse resultado [5].

4.2 spec, status e metadata

• metadata: identidade, namespace, labels, annotations e ownership;
• spec: intenção declarada;
• status: observação registrada por controllers;
• generation: versão desejada do objeto;
• observedGeneration: geração que o controller processou.

Um objeto existir não significa que seu estado foi aplicado. Compare conditions e observedGeneration.

4.3 Labels e selectors

Labels identificam objetos para agrupamento e seleção. Um selector incorreto pode direcionar Service ao Pod errado ou impedir controller de reconhecer seus Pods. Labels precisam de taxonomia estável, como:

labels:
  app.kubernetes.io/name: portal
  app.kubernetes.io/instance: portal-producao
  app.kubernetes.io/component: api
  app.kubernetes.io/version: "1.4.2"

Annotations armazenam metadata não seletiva: links, checksums, owner ou instruções de integração.

4.4 Ownership, garbage collection e finalizers

ownerReferences permite que dependentes sejam coletados quando o owner desaparece. finalizers adiam a remoção física até uma limpeza ser concluída. Um finalizer cujo controller não funciona deixa objeto em Terminating; remover o finalizer manualmente pode abandonar recurso externo.

4.5 Imperativo versus declarativo

Comandos imperativos são úteis para diagnóstico e laboratório. Para produção, manifests versionados oferecem review, history e reconciliação. kubectl edit em produção cria configuração difícil de reproduzir.

4.6 Server-Side Apply e field ownership

Vários controllers e ferramentas podem gerenciar campos do mesmo objeto. Server-Side Apply registra field managers e detecta conflitos. “Último YAML vence” é uma simplificação perigosa quando HPA, GitOps controller e operador escrevem no mesmo recurso.

Exercícios

1. Diferencie spec.replicas, status.replicas e status.availableReplicas.
2. Explique um objeto preso em Terminating por finalizer.
3. Crie uma taxonomia de labels para web, worker e scheduler.

Nota Zettelkasten — ZK-K8S-004

Título: Reconciliation Loop

Controllers observam estado, calculam diferença e agem até aproximar current state de desired state; status e conditions mostram a convergência real.

Capítulo 5 — Ambientes, instalação e primeira aplicação

5.1 Local, managed e self-managed

Kind e minikube são úteis em laboratório. Eles não simulam integralmente load balancer, storage, failure domains e IAM do ambiente produtivo.

5.2 kubeconfig e contexts

kubectl usa kubeconfig para agrupar cluster, identidade e namespace em um context [6]. Executar comando destrutivo no context errado é uma falha operacional comum.

kubectl config get-contexts
kubectl config use-context laboratorio
kubectl config set-context --current --namespace=laboratorio

Não compartilhe kubeconfig administrativo. Prefira autenticação temporária e RBAC por função.

5.3 Primeiro deployment

kubectl create namespace laboratorio
kubectl apply -f deployment.yaml
kubectl rollout status deployment/portal -n laboratorio
kubectl get pods -n laboratorio -o wide
kubectl describe deployment portal -n laboratorio

apply aceito prova apenas que a API validou o objeto. rollout status, conditions, Events, endpoints e teste funcional fornecem evidência adicional.

5.4 Expondo apenas no laboratório

kubectl port-forward -n laboratorio service/portal 8080:80

Port-forward é canal temporário para debug. Não é desenho de exposição em produção.

5.5 Cleanup seguro

kubectl delete namespace laboratorio

Antes de excluir, confirme context, namespace, recursos persistentes e reclaim policy. Namespace não é fronteira absoluta: objetos cluster-scoped e recursos externos podem permanecer.

Exercícios

1. Compare Kind, serviço managed e kubeadm para um portal corporativo.
2. Crie dois contexts com namespaces distintos e confirme o ativo.
3. Explique por que kubectl apply sem erro não é Definition of Done.

Nota Zettelkasten — ZK-K8S-005

Título: Contexto operacional do kubectl

Todo comando Kubernetes é relativo a cluster, identidade e namespace; confirmar context reduz mudanças corretas no ambiente errado.

Capítulo 6 — Pods, lifecycle e health checks

6.1 Pod é a unidade de scheduling

Um Pod agrupa um ou mais containers que compartilham network namespace, endereço IP e volumes declarados. Containers no mesmo Pod comunicam-se por localhost. Eles devem possuir lifecycle fortemente acoplado; colocar frontend e banco no mesmo Pod impede scaling, atualização e recuperação independentes.

Pods são efêmeros. Um Pod substituto recebe novo UID e geralmente novo IP. A identidade durável deve vir de Service, volume persistente ou controller apropriado, não do Pod individual.

6.2 Fases, states e conditions

Figura 4 — Lifecycle do Pod, efeito das probes e sequência de encerramento gracioso.

• Pod phase: Pending, Running, Succeeded, Failed ou Unknown;
• container state: Waiting, Running ou Terminated;
• conditions: sinais como PodScheduled, Initialized, ContainersReady e Ready;
• restart count: quantas vezes o container reiniciou no mesmo Pod.

Running não significa pronto para tráfego. Um container pode estar executando enquanto a aplicação ainda carrega cache ou está incapaz de responder.

6.3 Init Containers e sidecars

Init Containers executam sequencialmente antes dos containers de aplicação. Servem para preparação curta e idempotente, não para migration global que vários Pods podem executar ao mesmo tempo.

Sidecar é um container auxiliar com lifecycle relacionado ao principal: proxy, log shipper ou sincronizador. O custo de CPU e memória do sidecar participa do scheduling e deve ser declarado.

6.4 Probes

Uma liveness probe que depende de banco remoto pode reiniciar todos os Pods durante falha do banco, agravando o incidente. Readiness deve refletir capacidade de atender aquela requisição; liveness deve detectar estado que reinício local consegue corrigir.

startupProbe:
  httpGet:
    path: /health/startup
    port: http
  failureThreshold: 30
  periodSeconds: 2
readinessProbe:
  httpGet:
    path: /health/ready
    port: http
  periodSeconds: 5
livenessProbe:
  httpGet:
    path: /health/live
    port: http
  periodSeconds: 10
  failureThreshold: 3

6.5 Restart não é rescheduling

Kubelet pode reiniciar um container dentro do mesmo Pod conforme restartPolicy. Se o Node falhar, um controller cria outro Pod em Node disponível. Um Pod criado diretamente não ganha replicação automática.

6.6 Termination graciosa

Durante término, o Pod recebe deletionTimestamp, endpoints deixam de ser usados e o kubelet inicia o encerramento. A aplicação deve:

1. falhar readiness para não aceitar nova carga;
2. receber SIGTERM;
3. concluir requests e jobs em andamento;
4. sair antes de terminationGracePeriodSeconds;
5. tolerar que encerramento e remoção de endpoint não sejam instantâneos.

preStop pode ajudar, mas seu tempo conta dentro do grace period. Sleep arbitrário não substitui protocolo correto.

6.7 Debug básico

kubectl get pod portal-abc -n laboratorio -o yaml
kubectl describe pod portal-abc -n laboratorio
kubectl logs portal-abc -n laboratorio -c web --previous
kubectl exec -n laboratorio portal-abc -c web -- printenv

--previous é essencial quando o container reiniciou. exec deve ser limitado por RBAC, pois permite executar código dentro do workload.

Exercícios

1. Defina startup, readiness e liveness para uma API Flask.
2. Explique por que banco e aplicação no mesmo Pod são um acoplamento inadequado.
3. Diferencie container restart, Pod replacement e Node recovery.

Nota Zettelkasten — ZK-K8S-006

Título: Health check com semântica

Startup, readiness e liveness respondem perguntas diferentes; probe errada transforma dependência externa em restart loop.

Capítulo 7 — Controllers e tipos de workload

7.1 Relação entre objetos

Figura 5 — Relação de ownership entre Deployment, ReplicaSet e Pods, e seleção independente pelo Service.

Deployment cria e gerencia ReplicaSets; ReplicaSet mantém Pods intercambiáveis; Service seleciona Pods por labels. Os objetos são relacionados por selectors e ownership, não por ordem textual do YAML.

7.2 Comparação

Deployments gerenciam workloads normalmente stateless por updates declarativos [5]. StatefulSets preservam identidade aderente e são úteis para aplicações stateful [7]. DaemonSets executam facilidades locais do Node, como agentes de rede ou logs [8]. Jobs representam tarefas que chegam à conclusão [9].

Figura 6 — Matriz de decisão entre Deployment, StatefulSet, DaemonSet, Job e CronJob.

7.3 Rolling update

maxUnavailable limita indisponibilidade durante rollout; maxSurge permite Pods adicionais. Ambos interagem com capacity, readiness e termination.

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0
    maxSurge: 1

Esse desenho tenta preservar capacidade, mas exige espaço para o Pod extra. Se requests ocupam todos os Nodes, o rollout pode ficar bloqueado.

7.4 Rollback

kubectl rollout status deployment/portal -n producao
kubectl rollout history deployment/portal -n producao
kubectl rollout undo deployment/portal -n producao

Rollback do Deployment troca Pod template. Ele não reverte automaticamente migration, mensagem publicada ou contrato externo.

7.5 StatefulSet não transforma banco em distribuído

StatefulSet fornece nome e volume estáveis. Replicação, election, consistency, backup e failover pertencem ao banco ou Operator. Executar PostgreSQL com três réplicas idênticas não cria um cluster PostgreSQL válido.

7.6 Jobs e idempotência

Jobs podem recriar Pods e repetir execução. CronJobs podem atrasar ou sobrepor instâncias conforme concurrencyPolicy. Qualquer efeito externo deve usar chave de idempotência, checkpoint ou transação apropriada.

Exercícios

1. Escolha o controller para API, worker, log agent, migration e backup.
2. Explique por que rollback de image não reverte schema do banco.
3. Projete um Job seguro para importar registros sem duplicação.

Nota Zettelkasten — ZK-K8S-007

Título: Controller conforme semântica do workload

O controller correto representa identidade, duração, placement e estratégia de atualização; escolher apenas pelo número de réplicas perde essas garantias.

Capítulo 8 — ConfigMaps, Secrets e configuração

8.1 Separar image e configuração

Uma mesma image deve atravessar ambientes. URL, feature flag não sensível e nível de log entram por configuração. Senhas, tokens e chaves exigem gestão de secrets.

8.2 ConfigMap

ConfigMap armazena pares de configuração não confidencial. O objeto tem limite de 1 MiB e não foi projetado como file store [10]. Pode ser consumido por environment variables, argumentos ou volume.

apiVersion: v1
kind: ConfigMap
metadata:
  name: portal-config
data:
  LOG_LEVEL: INFO
  WORKER_QUEUE: default

Environment variables são capturadas no início do processo. Volume projetado pode atualizar depois, mas a aplicação precisa reler e existe atraso de propagação. Rollout por checksum torna a mudança explícita e auditável.

8.3 Secret não significa criptografado

Secret separa dado sensível do PodSpec, mas seu conteúdo base64 não é criptografia. Por padrão, Secrets podem permanecer sem criptografia no etcd; habilite encryption at rest, TLS, RBAC mínimo e restrição de acesso [11].

kubectl create secret generic portal-db \
  --from-literal=username=portal \
  --from-file=password=./senha.txt \
  --dry-run=client -o yaml

Mesmo com --dry-run, o YAML resultante contém o secret codificado. Não faça commit dele.

8.4 External secret management

Em produção, é comum integrar Vault ou secret manager do cloud provider por CSI driver ou controller. O cluster recebe referência ou cópia sincronizada. Avalie:

• quem autentica o Pod;
• onde o valor é materializado;
• como ocorre rotation;
• se o secret aparece em environment, volume, log ou core dump;
• comportamento quando o provider fica indisponível;
• revogação e auditoria.

8.5 Downward API

Downward API expõe metadata do próprio Pod, como namespace, name e labels. É útil para logs e telemetry sem duplicar configuração.

8.6 Configuration drift

Editar ConfigMap com kubectl edit quebra rastreabilidade. Prefira Git, review e deployment tool. Reiniciar Pods sem registrar por que a configuração mudou corrige sintoma e preserva drift.

Exercícios

1. Classifique dez valores entre image, ConfigMap, Secret e serviço externo.
2. Explique por que base64 não protege uma senha.
3. Desenhe rotation de token sem indisponibilidade.

Nota Zettelkasten — ZK-K8S-008

Título: Configuração tem lifecycle

Configuração e secret possuem criação, distribuição, atualização, observação, rotation e revogação; injetar valor no Pod é apenas uma etapa.

Capítulo 9 — Services, DNS e service discovery

9.1 Por que Service existe

Pods mudam de IP. Service cria identidade virtual estável e seleciona backends por labels. O controller mantém EndpointSlices, que representam endpoints elegíveis [12].

Figura 7 — Caminho completo de uma requisição, do cliente ao processo dentro do container.

9.2 Tipos de Service

9.3 Selector e portas

apiVersion: v1
kind: Service
metadata:
  name: portal
spec:
  selector:
    app.kubernetes.io/name: portal
  ports:
    - name: http
      port: 80
      targetPort: http

port é a porta do Service; targetPort é a porta no backend. Nomear portas reduz acoplamento numérico. Selector errado produz zero endpoint ou aponta para versão indevida.

9.4 DNS

Dentro do mesmo namespace, portal normalmente resolve o Service. Entre namespaces, use portal.atendimento; a forma completa segue portal.atendimento.svc.cluster.local, considerando o cluster domain configurado.

DNS bem-sucedido não prova conectividade. Diagnóstico separa:

1. resolução do nome;
2. presença de EndpointSlices;
3. rota e NetworkPolicy;
4. porta e processo;
5. protocolo e TLS;
6. resposta da aplicação.

9.5 Service não é health check de negócio

Readiness decide se o Pod entra nos endpoints. Service distribui tráfego entre endpoints disponíveis; ele não compreende transação ou sessão da aplicação. Sticky session pode existir em implementações específicas, mas estado de usuário deve preferir store externo.

Exercícios

1. Explique o caminho de portal.atendimento até um Pod.
2. Diagnostique um Service sem endpoints.
3. Compare ClusterIP, headless Service e LoadBalancer.

Nota Zettelkasten — ZK-K8S-009

Título: Service desacopla identidade e instância

Service oferece identidade estável sobre Pods efêmeros; selectors, EndpointSlices e readiness determinam os backends reais.

Capítulo 10 — Exposição externa: Ingress e Gateway API

10.1 Camadas de exposição

• Service LoadBalancer: exposição de protocolo L4 suportado;
• Ingress: roteamento HTTP/HTTPS consolidado;
• Gateway API: conjunto extensível e orientado a papéis para infraestrutura e routes.

Figura 8 — Comparação estrutural entre Ingress e o modelo orientado a papéis da Gateway API.

10.2 Ingress precisa de controller

Criar um objeto Ingress não configura tráfego sem Ingress controller. A API Ingress permanece GA, mas está congelada; o projeto recomenda Gateway API para evolução de recursos [13].

10.3 Gateway API

Gateway API separa responsabilidades:

• GatewayClass: implementação administrada pela plataforma;
• Gateway: listener e infraestrutura compartilhada;
• HTTPRoute/TCPRoute: regra controlada pela equipe da aplicação;
• ReferenceGrant: autorização explícita para referência cross-namespace.

Essa divisão evita entregar configuração integral do load balancer a cada equipe [14].

10.4 TLS

Decida onde TLS termina:

• no load balancer externo;
• no Gateway/Ingress controller;
• novamente no backend por TLS ou mTLS.

Certificado, private key, hostname, redirect HTTP→HTTPS, cipher policy e rotation precisam ser operados. “Ingress com TLS” não prova criptografia até o Pod.

10.5 Preservação de origem e headers

Aplicação deve confiar em X-Forwarded-* somente quando a cadeia de proxies é conhecida. Aceitar header do cliente diretamente permite falsificar scheme ou IP. Configure proxy trust e logs de correlação.

10.6 Teste por camadas

kubectl get gateway,httproute -A
kubectl describe httproute portal -n atendimento
kubectl get endpointslice -n atendimento -l kubernetes.io/service-name=portal
curl -vk --resolve portal.example.com:443:203.0.113.10 \
  https://portal.example.com/health/ready

O IP é ilustrativo. Em produção, valide DNS, certificado, route status, policy e backend.

Exercícios

1. Compare Service LoadBalancer, Ingress e Gateway API.
2. Desenhe ownership entre platform team e application team.
3. Explique por que TLS no edge pode não proteger tráfego interno.

Nota Zettelkasten — ZK-K8S-010

Título: Exposição externa orientada por papéis

Gateway API separa infraestrutura compartilhada e rotas da aplicação, tornando ownership e referências entre namespaces explícitos.

Capítulo 11 — Pod networking, CNI e NetworkPolicy

11.1 Modelo de rede

O modelo Kubernetes pressupõe que cada Pod tenha IP próprio e possa comunicar-se com outros Pods sem NAT entre eles, salvo policy ou implementação que restrinja. O CNI plugin cria interfaces, atribui endereços e programa o data plane. Kubernetes define o modelo e as APIs; o plugin implementa a rede.

11.2 Quatro caminhos diferentes

1. container → container no mesmo Pod: localhost;
2. Pod → Pod: rede CNI;
3. Pod → Service: ClusterIP, DNS e data plane do Service;
4. cliente externo → workload: LB/Gateway/Ingress → Service → Pod.

Confundir os caminhos leva a diagnóstico aleatório. Um Pod pode alcançar outro por IP e falhar via Service por selector ou porta; pode alcançar Service internamente e falhar externamente por route ou TLS.

11.3 NetworkPolicy

NetworkPolicy controla tráfego L3/L4 entre Pods e redes externas, desde que o network plugin implemente enforcement [15]. Criar o objeto em CNI sem suporte produz falsa sensação de segurança.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-ingress
  namespace: atendimento
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/component: api
  policyTypes: [Ingress, Egress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: gateway-system
      ports:
        - protocol: TCP
          port: 8000
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: data
      ports:
        - protocol: TCP
          port: 5432

O exemplo omite DNS; em um default-deny real, a aplicação pode deixar de resolver nomes. Políticas precisam considerar DNS, APIs externas, telemetry e endpoints de autenticação.

11.4 Default deny e allowlist

Uma estratégia madura começa com inventário de fluxos e aplica default-deny por etapas. Bloquear tudo em produção sem observação prévia pode interromper health checks, DNS e monitoring. Use audit, ambiente de homologação e testes de conectividade.

11.5 NetworkPolicy não é firewall universal

Ela normalmente atua sobre tráfego de Pods em L3/L4. Não interpreta usuário HTTP, payload malicioso ou regra de negócio. Combine com:

• autenticação e autorização na aplicação;
• Gateway/WAF quando apropriado;
• mTLS/service mesh conforme ameaça;
• firewall de cloud/VPC;
• egress gateway ou proxy;
• runtime e node hardening.

11.6 Troubleshooting de rede

kubectl get pod -n atendimento -o wide
kubectl get svc,endpointslice -n atendimento
kubectl get networkpolicy -A
kubectl run net-debug --rm -it --image=curlimages/curl -- sh

Imagens de debug também fazem parte da supply chain. Não deixe Pod privilegiado permanente apenas por conveniência.

Exercícios

1. Desenhe os quatro caminhos de rede de uma API.
2. Corrija a policy de exemplo para permitir DNS de forma controlada.
3. Explique por que policy existente pode não estar sendo aplicada.

Nota Zettelkasten — ZK-K8S-011

Título: Rede Kubernetes depende de implementação

As APIs descrevem intenção; CNI, service data plane e controllers implementam conectividade. Diagnóstico precisa identificar qual camada falhou.

Capítulo 12 — Requests, limits, QoS e quotas

12.1 Recursos são contrato de scheduling e execução

Figura 9 — Requests no scheduling, limits no runtime e influência de QoS durante pressão no Node.

requests influenciam placement: o scheduler procura Node com capacidade alocável. limits são aplicados no runtime pelo kubelet e kernel [16]. CPU e memória não se comportam da mesma forma:

• CPU acima do limit sofre throttling;
• memória acima do limit pode levar a OOM kill;
• uso acima do request pode ocorrer se houver capacidade;
• request muito baixo causa overcommit e instabilidade;
• request muito alto desperdiça capacity e bloqueia scheduling.

resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    cpu: "1"
    memory: 512Mi

250m representa 0,25 CPU. 256Mi usa unidade binária; 256M é unidade decimal e não é igual.

12.2 Utilização relativa ao request

Para HPA baseado em CPU, a utilização média costuma comparar uso com request:

onde CPU_uso é o consumo medido e CPU_request é a CPU solicitada. Se um container usa 200m e pediu 250m, a utilização relativa é 80%, ainda que o Node possua CPUs livres.

12.3 QoS classes

• Guaranteed: requests iguais a limits para CPU e memória em todos os containers elegíveis;
• Burstable: algum request/limit existe, mas não atende Guaranteed;
• BestEffort: nenhum request ou limit de CPU/memória.

QoS influencia eviction sob pressão, mas não é garantia absoluta de sobrevivência. Priority, consumo acima de request e tipo de pressão também importam.

12.4 LimitRange e ResourceQuota

LimitRange define defaults e mínimos/máximos por objeto no namespace. ResourceQuota limita consumo agregado e quantidade de recursos. Quota sem requests bem calibrados apenas converte erro de capacidade em erro de admissão.

12.5 Capacity, allocatable e utilization

Node capacity inclui recurso físico. allocatable desconta reservas do sistema e kubelet. Scheduler compara requests agregados com allocatable, não consumo instantâneo. Um Node com CPU ociosa pode rejeitar Pod porque toda CPU já foi solicitada.

12.6 Rightsizing

Use histórico de percentis, picos, startup, garbage collection e SLO. Não ajuste request ao uso médio exato. Considere:

• baseline e pico;
• tempo de reação do autoscaler;
• cold start;
• memória não compressível;
• sidecars;
• margem para rollout e falha de Node.

Exercícios

1. Calcule U_cpu para 300m usados sobre request de 200m.
2. Classifique três Pods em Guaranteed, Burstable e BestEffort.
3. Explique um Pod Pending em Node aparentemente ocioso.

Nota Zettelkasten — ZK-K8S-012

Título: Requests declaram demanda, não medem uso

Requests orientam scheduling e fairness; uso real orienta observação e rightsizing. Confundir os dois produz desperdício ou overcommit perigoso.

Capítulo 13 — Scheduling, placement e disruptions

13.1 Filtro, score e binding

O scheduler encontra Nodes viáveis, pontua os candidatos e registra o binding do Pod ao Node [17]. Depois, o kubelet daquele Node cria os containers.

13.2 Ferramentas de placement

Toleration não atrai o Pod; apenas remove uma restrição. Use junto com affinity quando o workload deve permanecer em pool dedicado [18].

13.3 Failure domains

Topology spread constraints distribuem Pods entre zonas, Nodes ou domínios definidos [19]. Três réplicas no mesmo Node oferecem replicação de processo, não tolerância à falha do Node.

13.4 Priority e preemption

PriorityClass influencia ordem e pode permitir preemption de Pods de menor prioridade. Usar prioridade máxima em todos os workloads elimina diferenciação. Preemption não cria capacity; apenas decide quem perde recurso.

13.5 Eviction

Eviction pode ocorrer por:

• pressão de memória, disco, inode ou PID no Node;
• drain administrativo;
• Node indisponível;
• preemption;
• policy ou manutenção.

Eventos, Pod status, Node conditions e logs do kubelet ajudam a distinguir OOMKilled, eviction por pressão e rollout normal.

13.6 PodDisruptionBudget

PDB limita indisponibilidade em disruptions voluntárias. Ele não impede falha física e não garante que um rollout mal configurado preserve SLO. Em preemption, respeito ao PDB pode ser best effort [20].

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: portal
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: portal

PDB incompatível com número de réplicas pode impedir drain e upgrade.

Exercícios

1. Distribua três réplicas entre duas zonas e vários Nodes.
2. Explique diferença entre taint, toleration e node affinity.
3. Crie cenário em que PDB bloqueia manutenção.

Nota Zettelkasten — ZK-K8S-013

Título: Placement expressa failure domains

Scheduling confiável combina demanda, restrições e topologia; número de réplicas sem distribuição não representa disponibilidade.

Capítulo 14 — Storage, PV, PVC, StorageClass e CSI

14.1 Container filesystem é efêmero

Dados gravados na layer do container desaparecem quando ele é substituído. Volume monta storage no Pod. Durabilidade, replicação e backup dependem do tipo e do backend.

Figura 10 — Fluxo de storage entre Pod, PVC, StorageClass, PV, CSI driver e backend.

14.2 Objetos e responsabilidades

• PersistentVolume (PV): capacidade de storage disponível ao cluster;
• PersistentVolumeClaim (PVC): solicitação de storage do workload;
• StorageClass: classe, provisioner e parâmetros definidos pela plataforma;
• CSI driver: implementação que provisiona, anexa e monta volumes;
• VolumeSnapshot: representação de snapshot quando suportado.

PVC desacopla aplicação dos detalhes do backend [21]. Dynamic provisioning cria volume sob demanda pela StorageClass [22].

14.3 Access modes não são garantia universal

ReadWriteOnce, ReadOnlyMany, ReadWriteMany e modos relacionados descrevem formas de montagem suportadas. Eles não substituem mecanismo de locking da aplicação nem transformam filesystem em banco distribuído.

14.4 Reclaim policy

• Delete: remover PV pode excluir storage do provider;
• Retain: storage permanece para recuperação manual.

Confirme policy antes de apagar namespace, PVC ou StatefulSet. “Recriar o manifesto” não recupera volume deletado.

14.5 StatefulSet e volumeClaimTemplates

Cada ordinal pode receber PVC próprio. Reduzir réplicas ou excluir StatefulSet normalmente não deve ser tratado como limpeza automática dos dados. Documente ownership, retenção e restore.

14.6 Snapshot não é backup completo

Snapshot pode ser crash-consistent e permanecer no mesmo failure domain ou account. Backup confiável possui:

• consistência da aplicação;
• cópia independente e criptografada;
• retenção e imutabilidade;
• inventário de metadata e secrets necessários;
• teste periódico de restore;
• RPO e RTO definidos.

14.7 Banco dentro ou fora do cluster

Banco managed reduz parte da operação de storage e failover. Banco no cluster pode ser válido com Operator maduro, storage adequado e equipe capacitada. A escolha depende de latência, compliance, custo, portability e responsabilidade operacional.

Exercícios

1. Trace StorageClass → PVC → PV → CSI → backend.
2. Compare Delete e Retain durante exclusão acidental.
3. Escreva um teste de restore para PostgreSQL.

Nota Zettelkasten — ZK-K8S-014

Título: Persistência exige restore demonstrável

PV e snapshot fornecem mecanismos; durabilidade operacional só existe quando consistência, retenção, independência e restore são testados.

Capítulo 15 — Security: identidade, policy e supply chain

15.1 Modelo em camadas

Figura 11 — Camadas complementares de security, da supply chain à infraestrutura.

Security em Kubernetes atravessa cloud/datacenter, cluster, container e aplicação. Um cluster privado não corrige image vulnerável; NetworkPolicy não corrige RBAC administrativo; RBAC não corrige SQL injection.

15.2 Autenticação, autorização e admission

O API server processa:

1. authentication: quem faz o pedido;
2. authorization: se pode executar verbo sobre recurso;
3. admission: valida ou modifica o objeto;
4. persistence: grava o objeto aceito.

RBAC associa Subjects a Roles/ClusterRoles por RoleBindings/ClusterRoleBindings. Evite curingas e cluster-admin; permissões para criar Pods podem permitir montar Secrets, usar ServiceAccounts ou alcançar Nodes, gerando privilege escalation [23].

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: atendimento
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]

15.3 ServiceAccounts

ServiceAccount é identidade de workload perante a Kubernetes API. Não monte token automaticamente quando o Pod não precisa:

automountServiceAccountToken: false

Quando precisa, use ServiceAccount exclusivo, audience e duração apropriadas. Compartilhar default entre aplicações impede least privilege.

15.4 Pod Security Standards

Os níveis privileged, baseline e restricted formam políticas cumulativas [24]. Um workload seguro normalmente busca:

securityContext:
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault
containers:
  - name: web
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]

O manifesto precisa de volumes graváveis para diretórios necessários. Ativar root filesystem read-only sem entender a aplicação apenas desloca a falha para runtime.

15.5 Secrets e encryption

Restrinja verbos get, list e watch sobre Secrets; uma lista pode revelar todos os valores autorizados. Habilite encryption at rest de etcd, proteja backups e rotacione chaves. Secrets expostos como environment podem aparecer em dumps e ferramentas de processo.

15.6 Network e multi-tenancy

Namespace organiza e delimita muitos recursos, mas não é VM. Multi-tenancy exige combinação de RBAC, quotas, Pod Security, NetworkPolicy, admission, node isolation e observability. Workload hostil pode exigir clusters separados ou runtime sandboxed.

15.7 Supply chain

Proteja:

• source e review;
• build runner;
• dependências e base image;
• registry e tags imutáveis;
• assinatura/provenance;
• admission policy;
• runtime e patching;
• SBOM e resposta a vulnerabilidade.

Scan sem policy vira relatório ignorado. Policy sem processo de exceção incentiva bypass.

15.8 Audit e break-glass

Audit logs registram chamadas à API conforme policy. Conta break-glass deve ser protegida, monitorada, testada e usada apenas por incidente. Credencial administrativa cotidiana não é break-glass.

Exercícios

1. Explique uma privilege escalation possível por criação de Pods.
2. Aplique restricted a uma API e registre incompatibilidades reais.
3. Desenhe a cadeia source → image → admission → runtime.

Nota Zettelkasten — ZK-K8S-015

Título: Segurança Kubernetes é composição

Identidade, RBAC, admission, Pod Security, network, secrets e supply chain reduzem riscos distintos; nenhuma camada isolada fornece boundary completa.

Capítulo 16 — Observability e troubleshooting

16.1 Os quatro sinais operacionais

Figura 12 — Sequência de troubleshooting apoiada por Events, logs, metrics e traces.

• Events: decisões e falhas recentes de objetos e componentes;
• logs: eventos discretos produzidos pela aplicação e plataforma;
• metrics: séries temporais agregáveis;
• traces: caminho de uma requisição entre serviços.

Nenhum sinal substitui os demais. kubectl logs mostra o processo, não a causa de um Pod nunca ter sido agendado. Events mostram FailedScheduling, mas não explicam uma query lenta dentro da aplicação.

16.2 Health não é observability

Probe responde uma pergunta binária operacional. Observability permite formular perguntas novas a partir do estado externo. Uma API pode passar readiness e ainda ter p99 acima do SLO.

16.3 Resource metrics

Metrics Server coleta CPU e memória dos kubelets, implementa Metrics API e alimenta kubectl top e autoscalers [25]. Ele não é uma plataforma completa de monitoramento histórico.

kubectl top nodes
kubectl top pods -n atendimento --containers

Em Kubernetes v1.37, Metrics API metrics.k8s.io/v1 tornou-se stable, mas o cluster ainda precisa de Metrics Server ou implementação compatível [2,25].

16.4 Golden Signals e RED

Para services, monitore:

• rate: requisições por segundo;
• errors: falhas por classe;
• duration: distribuição de latência, especialmente percentis;
• saturation: filas, pool, CPU, memória e conexões.

Média esconde cauda. Se 99 requests respondem em 100 ms e uma em 10 s, a média parece aceitável para muitos contextos, mas o p99 revela experiência ruim.

16.5 Logging estruturado

Inclua timestamp, severity, service, version, namespace, Pod, trace_id e correlation_id. Não registre token, cookie, conteúdo pessoal ou Secret. Pods são efêmeros; logs precisam sair do Node para retenção central.

16.6 Método de troubleshooting

1. confirme context, namespace e janela temporal;
2. descreva o sintoma observável;
3. verifique objeto desejado e conditions;
4. examine Events em ordem temporal;
5. identifique Node, Pod, container e versão;
6. leia logs atuais e anteriores;
7. teste DNS, endpoints e conectividade por camadas;
8. correlacione metrics e traces;
9. formule hipótese e experimento mínimo;
10. registre correção e teste de regressão.

16.7 Diagnósticos frequentes

16.8 Ephemeral containers

Ephemeral containers permitem debug quando a image não possui shell. Seu uso é poderoso e sensível; controle pods/ephemeralcontainers por RBAC e registre a ação.

Exercícios

1. Diagnostique Running com Service sem endpoint.
2. Diferencie CrashLoopBackOff por aplicação e por Secret ausente.
3. Defina Golden Signals para um worker RQ.

Nota Zettelkasten — ZK-K8S-016

Título: Troubleshooting orientado por camadas

Diagnóstico Kubernetes parte de estado e evidência: API, scheduler, Node, runtime, network, storage e aplicação são investigados separadamente antes da conclusão.

Capítulo 17 — Autoscaling: HPA, VPA e Nodes

17.1 Três decisões diferentes

Figura 13 — HPA, VPA e Cluster Autoscaler atuando em níveis diferentes do sistema.

HPA atualiza a escala de workloads como Deployment ou StatefulSet conforme métricas [26]. Horizontal scaling adiciona réplicas; vertical scaling altera recursos de cada réplica.

17.2 Fórmula conceitual do HPA

Uma aproximação documentada para o número desejado é:

onde R_d é o número desejado de réplicas, R_a é o número atual, M_a é a métrica atual e M_t é a meta. Com 4 réplicas em 80% para meta de 50%, o resultado aproximado é 7 réplicas.

O controller inclui tolerância, Pods ausentes, readiness e stabilization windows. A fórmula não deve ser usada como simulador completo.

17.3 Métrica certa

CPU funciona quando demanda se correlaciona com CPU. Para worker de fila, backlog por worker ou idade da mensagem pode representar melhor o risco. Para API limitada por banco, aumentar Pods pode esgotar connections e piorar latência.

17.4 Requests e HPA

HPA por utilização de CPU precisa de requests coerentes. Sem request, a utilização relativa pode ficar indefinida para containers relevantes. Rightsizing e autoscaling são partes do mesmo sistema.

17.5 Oscilação e atraso

Autoscaling reage depois que a métrica muda. Considere:

• scrape e aggregation delay;
• tempo de decisão do controller;
• provisioning de Node;
• pull da image;
• startup e readiness;
• aquecimento de cache;
• stabilization de scale-down.

Capacidade mínima deve absorver carga durante essa soma de atrasos.

17.6 Scale to zero

Kubernetes v1.37 introduziu suporte Beta para HPA escalar workloads a zero em condições específicas com object ou external metrics [2]. Não trate Beta como universal: confirme feature gate, API, adapter e comportamento da versão instalada.

17.7 Load test e failure test

Teste subida, descida, pico, falha de Node e indisponibilidade do metrics provider. Um HPA bem configurado em steady state pode falhar quando a telemetry desaparece.

Exercícios

1. Calcule R_d para 3 réplicas, métrica 90 e meta 60.
2. Escolha métrica para API, worker de fila e processamento batch.
3. Trace o atraso total do pico até um novo Pod ficar Ready.

Nota Zettelkasten — ZK-K8S-017

Título: Autoscaling é control loop atrasado

Autoscaler reage a sinais com atraso e limites; capacity mínima, métrica causal, requests e dependências determinam se novas réplicas ajudam.

Capítulo 18 — Deployment patterns, Helm, Kustomize e GitOps

18.1 Estratégias de release

Figura 14 — Comparação entre Recreate, Rolling Update, Blue-green e Canary.

Nenhuma estratégia resolve migration incompatível. Use expand/contract: adicionar estrutura compatível, migrar leitores/escritores, validar, depois remover legado.

18.2 CI e CD

CI deve produzir image uma vez, testar, escanear, assinar e publicar por digest. CD promove o mesmo digest entre ambientes. Rebuild por ambiente cria artefatos diferentes e enfraquece evidência.

Pipeline mínimo:

1. lint e unit tests;
2. build reproduzível;
3. dependency/image scan;
4. SBOM e provenance;
5. assinatura;
6. integration tests;
7. atualização declarativa do ambiente;
8. policy e admission;
9. rollout monitorado;
10. verificação e rollback/roll-forward.

18.3 Helm

Helm empacota manifests como charts e aplica templates [29]. É adequado para distribuir aplicação parametrizável. Complexidade excessiva em templates transforma YAML em linguagem de programação difícil de testar.

Mantenha values com schema, defaults seguros e documentação. Renderize antes:

helm lint ./chart
helm template portal ./chart -f values-homolog.yaml > rendered.yaml
kubectl apply --server-side --dry-run=server -f rendered.yaml

18.4 Kustomize

Kustomize compõe base e overlays por patches, sem template textual tradicional. É útil quando os ambientes compartilham manifests estruturais e variam poucos campos.

kubectl kustomize overlays/producao

Helm e Kustomize podem coexistir, mas cada camada adicional precisa de ownership e teste do output final.

18.5 GitOps

GitOps usa Git como fonte declarativa e um controller no cluster para reconciliar o estado. Os princípios OpenGitOps enfatizam declaração, versionamento, pull automático e reconciliação contínua [30]. O fluxo deve considerar:

• proteção de branch e review;
• assinatura e origem do artefato;
• secret management;
• drift detection;
• ordem e dependências;
• rollback versus roll-forward;
• credencial do controller;
• observação de health, não apenas sync.

Synced significa que o estado desejado foi aplicado; não significa que a aplicação atende seu SLO.

18.6 Canary orientado por métricas

Compare versão canary e baseline por error rate, latency e métricas de negócio. Volume insuficiente produz falsa confiança. Defina janela, threshold e ação antes do release.

Exercícios

1. Escolha estratégia para API compatível e migration incompatível.
2. Compare Helm e Kustomize em um produto interno.
3. Explique por que Git revert não reverte efeito externo ou dados.

Nota Zettelkasten — ZK-K8S-018

Título: Release separa artefato e configuração

CI produz artefato imutável; CD promove referência declarativa; rollout e análise decidem se o novo estado pode continuar.

Capítulo 19 — CRDs, controllers e Operator pattern

19.1 Estender a API

CustomResourceDefinition adiciona um novo tipo à Kubernetes API. Um custom resource sozinho armazena dados. Um controller transforma o objeto em API declarativa ao reconciliar desired state [27].

19.2 Operator pattern

Operator combina custom resources, controller e conhecimento operacional de um domínio. Exemplo: um PostgresCluster declara replicas, backup e versão; o Operator gerencia StatefulSets, Services, failover e status.

Isso não torna o Operator correto por definição. Ele vira parte do control plane da aplicação e precisa de:

• reconciliação idempotente;
• status e conditions úteis;
• retry com backoff;
• finalizers seguros;
• upgrade de CRD e dados;
• RBAC mínimo;
• métricas, logs e alertas;
• testes de falha;
• política de suporte.

19.3 spec e status de um CRD

apiVersion: platform.example.com/v1
kind: PortalEnvironment
metadata:
  name: homologacao
spec:
  image: registry.example.com/portal:1.4.2
  replicas: 2
status:
  observedGeneration: 7
  conditions:
    - type: Ready
      status: "True"

Schema OpenAPI deve validar campos. Versionamento exige conversion e compatibilidade. Remover campo sem migration pode deixar objetos persistidos que o controller novo não interpreta.

19.4 Quando não criar CRD

Prefira API standalone quando o domínio não é declarativo, não se encaixa em scope de cluster/namespace, exige transações complexas ou não precisa de kubectl. Usar Kubernetes como banco genérico aumenta carga no API server e etcd.

19.5 Admission webhooks

Validating admission rejeita objetos; mutating admission altera requests. Webhook lento ou indisponível pode bloquear deployments. Defina timeout, failure policy, namespace selector, availability e observability. Mutação invisível dificulta entender o manifesto final.

19.6 Custom scheduler e extender

Scheduler customizado só é justificável quando plugins e configurações nativas não atendem. Ele assume responsabilidade por placement correto. Um Pod indica schedulerName; se o scheduler correspondente não funciona, permanece Pending.

Exercícios

1. Diferencie CRD, controller e Operator.
2. Escolha entre CRD e API standalone para três domínios.
3. Modele conditions úteis para uma reconciliação parcialmente falha.

Nota Zettelkasten — ZK-K8S-019

Título: Operator codifica operação como control loop

Operator transforma conhecimento operacional em reconciliação contínua; por isso, seus erros têm alcance semelhante ao de componentes de plataforma.

Capítulo 20 — Operação de clusters, upgrades e disaster recovery

20.1 Managed versus self-managed

Escolher serviço managed terceiriza parte do control plane, não a responsabilidade por workloads, IAM, network, data, cost e incidentes. Self-managed exige domínio de Linux, PKI, etcd, load balancing, CNI, CSI, upgrades e hardening.

20.2 High availability

Um control plane HA normalmente usa múltiplas instâncias de API server atrás de load balancer e quorum de etcd. Em kubeadm, topologias stacked e external etcd apresentam trade-offs de custo, isolamento e operação [28].

Alta disponibilidade precisa atravessar failure domains. Três control-plane Nodes no mesmo host físico não toleram perda do host.

20.3 Upgrade

Plano de upgrade deve incluir:

1. support window das versões;
2. release notes, deprecations e API removals;
3. compatibilidade de CNI, CSI, Ingress/Gateway, metrics e Operators;
4. backup e restore testado;
5. canary de Node pool;
6. PodDisruptionBudgets e capacity para drain;
7. control plane antes/segundo regra da distribuição;
8. validação funcional e observability;
9. rollback suportado ou roll-forward;
10. comunicação e change record.

Nunca presuma que downgrade de etcd ou control plane será simples. Teste o procedimento específico do provider/distribuição.

20.4 Backup do cluster

Separe:

• estado da Kubernetes API em etcd;
• manifests e policies em Git;
• Secrets ou referências em secret manager;
• PVs e bancos com consistência própria;
• recursos externos criados por controllers;
• imagens no registry;
• configuração de DNS, IAM e network.

Disaster recovery precisa reconstruir relações, não apenas arquivos.

20.5 Multi-cluster

Multi-cluster pode oferecer isolamento, residency, failure domain e autonomia. Também multiplica upgrades, policy, observability, identity e custo. Não use múltiplos clusters apenas para simular namespaces mais fortes sem analisar o modelo de ameaça.

20.6 Capacity e custo

O custo total inclui compute, storage, egress, load balancers, observability, licenças, control plane e trabalho operacional.

onde C_t é custo total, C_c é compute, C_s é storage, C_n é network, C_o é observability/operação e C_p é plataforma e pessoas.

Otimizar apenas CPU pode aumentar latência, incidentes e tempo humano.

20.7 Runbooks essenciais

• API server indisponível;
• etcd sem quorum;
• NodeNotReady em massa;
• registry indisponível;
• DNS degradado;
• CNI ou CSI com falha;
• certificate expiration;
• esgotamento de IP, PID, inode, CPU, memória ou disco;
• restore de banco e de etcd;
• revogação de credencial comprometida.

20.8 Critério de maturidade

Uma plataforma madura consegue responder:

• quem é owner de cada workload e controller?
• qual versão e API estão em uso?
• qual SLO e error budget?
• quais permissions cada identidade possui?
• qual capacity resta após perder um Node ou zona?
• quando o último restore foi testado?
• como detectar e reverter uma mudança?
• qual risco permanece aceito?

Exercícios

1. Construa uma matriz managed versus self-managed para sua equipe.
2. Escreva um plano de upgrade com canary de Node pool.
3. Diferencie backup de etcd, manifests e dados da aplicação.

Nota Zettelkasten — ZK-K8S-020

Título: Cluster é um produto operacional

Operar Kubernetes significa manter lifecycle, segurança, capacity, recovery e experiência de desenvolvimento; instalar Nodes é apenas o início.

Estudo de Caso Integrador — Portal Flask corporativo no Kubernetes

Este laboratório aplica os conceitos a um portal corporativo com API Flask, PostgreSQL, Redis, workers RQ e integrações externas com GLPI e Slack. O desenho é exemplo técnico; hostnames, imagens, credenciais e sizing precisam ser adaptados.

1. Requisitos

• três réplicas da API durante produção;
• workers escaláveis por backlog;
• PostgreSQL com backup e restore testado;
• Redis para fila, não como fonte única de dados críticos;
• acesso externo HTTPS;
• GLPI e Slack acessíveis apenas pelos workers autorizados;
• nenhum secret no Git ou na image;
• zero downtime para updates compatíveis;
• logs correlacionados e metrics de API/fila;
• RPO de 15 minutos e RTO de 2 horas para dados do portal.

2. Arquitetura

Figura 15 — Arquitetura do laboratório Flask com workers RQ, PostgreSQL, Redis, GLPI, Slack e telemetry.

3. Namespaces e ownership

Use namespaces por boundary operacional, não um namespace por arquivo:

platform-system   Gateway, observability e policies da plataforma
portal-prod       API, workers, Services, HPA e PDB
data-prod         recursos de dados quando operados no cluster

Separar namespaces permite RBAC, quotas e NetworkPolicies distintas. Não autorize a equipe da aplicação a alterar GatewayClass ou componentes do control plane.

4. Deployment da API

apiVersion: apps/v1
kind: Deployment
metadata:
  name: portal-api
  namespace: portal-prod
  labels:
    app.kubernetes.io/name: portal
    app.kubernetes.io/component: api
spec:
  replicas: 3
  strategy:
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: portal
      app.kubernetes.io/component: api
  template:
    metadata:
      labels:
        app.kubernetes.io/name: portal
        app.kubernetes.io/component: api
    spec:
      serviceAccountName: portal-api
      automountServiceAccountToken: false
      terminationGracePeriodSeconds: 40
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: api
          image: registry.example.com/portal@sha256:SUBSTITUIR_DIGEST
          ports:
            - name: http
              containerPort: 8000
          envFrom:
            - configMapRef:
                name: portal-config
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: portal-runtime
                  key: database-url
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              cpu: "1"
              memory: 512Mi
          startupProbe:
            httpGet: {path: /health/startup, port: http}
            periodSeconds: 2
            failureThreshold: 30
          readinessProbe:
            httpGet: {path: /health/ready, port: http}
            periodSeconds: 5
            failureThreshold: 2
          livenessProbe:
            httpGet: {path: /health/live, port: http}
            periodSeconds: 10
            failureThreshold: 3
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ["ALL"]
          volumeMounts:
            - name: tmp
              mountPath: /tmp
      volumes:
        - name: tmp
          emptyDir:
            sizeLimit: 256Mi

Pontos importantes:

• digest torna o artefato inequívoco;
• automountServiceAccountToken: false reduz credencial desnecessária;
• root filesystem read-only exige volume para /tmp;
• probes possuem semânticas distintas;
• requests sustentam scheduling e HPA;
• maxSurge: 1 requer capacity adicional;
• DATABASE_URL vem de Secret, mas a forma de criar e rotacionar o Secret ainda precisa ser definida.

5. Service e HTTPRoute

apiVersion: v1
kind: Service
metadata:
  name: portal-api
  namespace: portal-prod
spec:
  selector:
    app.kubernetes.io/name: portal
    app.kubernetes.io/component: api
  ports:
    - name: http
      port: 80
      targetPort: http
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: portal
  namespace: portal-prod
spec:
  parentRefs:
    - name: corporate-gateway
      namespace: platform-system
  hostnames: ["portal.example.com"]
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: portal-api
          port: 80

O Gateway precisa permitir a route do namespace. Accepted=True não prova backend saudável; examine também ResolvedRefs, Service, EndpointSlices e readiness.

6. Workers e semântica de fila

Workers devem usar Deployment separado para atualizar e escalar sem afetar API. RQ implementa entrega que pode repetir job; integração GLPI precisa de idempotência e reconciliação.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: portal-worker
  namespace: portal-prod
spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: portal
      app.kubernetes.io/component: worker
  template:
    metadata:
      labels:
        app.kubernetes.io/name: portal
        app.kubernetes.io/component: worker
    spec:
      automountServiceAccountToken: false
      terminationGracePeriodSeconds: 90
      containers:
        - name: worker
          image: registry.example.com/portal@sha256:SUBSTITUIR_DIGEST
          command: ["rq", "worker", "default"]
          resources:
            requests: {cpu: 200m, memory: 256Mi}
            limits: {cpu: "1", memory: 768Mi}
          securityContext:
            allowPrivilegeEscalation: false
            capabilities: {drop: ["ALL"]}

O worker precisa interceptar SIGTERM, parar de buscar novo job e dar destino conhecido ao job em andamento. A duração máxima precisa caber no grace period ou permitir checkpoint/retry idempotente.

7. Migrations

Não coloque migration concorrente no startup de todas as réplicas. Opções:

• Job versionado antes do rollout;
• ferramenta de release com etapa única e lock;
• Operator da aplicação;
• migration administrada fora do cluster.

Use expand/contract. Exemplo:

1. adicionar coluna nullable;
2. deploy que escreve formato antigo e novo;
3. backfill observável;
4. deploy que lê novo formato;
5. tornar constraint obrigatória;
6. remover campo antigo em release posterior.

Rollback da API continua possível durante a janela de compatibilidade.

8. Security e network

Policies mínimas:

• Gateway → API na porta 8000;
• API → PostgreSQL e Redis;
• worker → PostgreSQL, Redis, GLPI, Slack e telemetry;
• DNS para workloads permitidos;
• nenhuma entrada direta no worker;
• default-deny para ingress e egress.

Como GLPI e Slack são endpoints externos, a allowlist pode exigir egress gateway, proxy ou controle por FQDN da solução de rede. IPs externos mutáveis tornam policy por CIDR frágil.

RBAC da API e do worker pode ser vazio se não chamam Kubernetes API. CI/CD e GitOps controller possuem identidades separadas. Acesso humano a pods/exec, Secrets e port-forward deve ser explícito e auditado.

9. Availability e disruptions

PDB da API:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: portal-api
  namespace: portal-prod
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: portal
      app.kubernetes.io/component: api

Adicione topology spread entre Nodes e, se houver infraestrutura multi-zone, entre zonas. Teste perda de uma réplica, drain de Node e falha de zona. O banco e Redis podem continuar como single points mesmo que a API tenha três Pods.

10. Autoscaling

API pode usar HPA por CPU como primeiro sinal, observando conexões do banco e latency. Worker deve preferir backlog e idade da mensagem por réplica. Antes de escalar:

• meça tempo médio e p95 do job;
• imponha limites de concorrência nas APIs externas;
• defina retry budget;
• garanta idempotência;
• limite máximo de réplicas conforme connections e rate limits.

Escalar worker para 100 réplicas contra GLPI com limite de 10 requests/s apenas transforma fila interna em throttling externo.

11. Observability

Dashboard mínimo:

Logs compartilham correlation_id; traces ligam Gateway, API, banco e enqueue. Job carrega o identificador para o worker. Alertas devem se apoiar em impacto/SLO, não apenas em CPU alta.

12. Backup e disaster recovery

• PostgreSQL: backup consistente, WAL quando aplicável e restore periódico;
• Redis: definir se é cache/fila reconstruível ou estado que precisa persistir;
• manifests: Git protegido e replicado;
• Secrets: backup/restore do secret manager e referências;
• volumes: snapshot mais cópia independente;
• cluster: procedimento de reconstrução;
• integrações: reconciliation para efeitos remotos ambíguos.

O teste final é restaurar em ambiente isolado e comprovar RPO/RTO, não verificar apenas se o arquivo de backup existe.

13. Pipeline e entrega

1. commit revisado;
2. testes de código e integração;
3. image build, scan, SBOM, assinatura e digest;
4. manifests renderizados e validados;
5. policy checks;
6. deploy em homologação;
7. testes funcionais e de falha;
8. promoção do mesmo digest;
9. canary/rolling update;
10. análise de metrics e decisão de continuar ou reverter.

14. Evidência de conclusão

Uma entrega deve responder:

• qual digest foi implantado?
• qual commit e quais manifests produziram o estado?
• quais conditions confirmam o rollout?
• quantos endpoints estão Ready?
• quais testes e policy checks passaram?
• qual migration ocorreu e como é revertida?
• quais dashboards e alertas foram observados?
• qual risco residual foi aceito?

Apêndice A — Templates reutilizáveis

A.1 Checklist de manifesto de workload

• [ ] image imutável por versão ou digest;
• [ ] labels e selectors coerentes;
• [ ] requests e limits fundamentados;
• [ ] startup, readiness e liveness com semântica;
• [ ] graceful shutdown e grace period;
• [ ] execução non-root e capabilities mínimas;
• [ ] ServiceAccount exclusiva ou token desabilitado;
• [ ] configuração separada de secrets;
• [ ] logs estruturados em stdout/stderr;
• [ ] topology e PDB compatíveis;
• [ ] rollout e rollback definidos;
• [ ] owner, SLO, runbook e dashboard registrados.

A.2 Template de Namespace com limites

apiVersion: v1
kind: Namespace
metadata:
  name: equipe-exemplo
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute
  namespace: equipe-exemplo
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "30"
---
apiVersion: v1
kind: LimitRange
metadata:
  name: defaults
  namespace: equipe-exemplo
spec:
  limits:
    - type: Container
      defaultRequest:
        cpu: 100m
        memory: 128Mi
      default:
        cpu: 500m
        memory: 512Mi

Defaults evitam ausência total, mas não substituem rightsizing por workload.

A.3 Template de change plan

Objetivo e comportamento esperado:
Versão atual → versão alvo:
APIs, CRDs e add-ons afetados:
Capacity necessária durante rollout:
Migration de dados:
PDB e drain:
Validações antes/durante/depois:
Critérios de abortar:
Rollback ou roll-forward:
Owner e janela:
Riscos residuais:

A.4 Template de incidente

Sintoma e impacto:
Início e detecção:
Clusters/namespaces/workloads afetados:
Mudanças recentes:
Estado de API, Nodes, Pods e endpoints:
Events, logs, metrics e traces:
Hipóteses e evidências:
Contenção aplicada:
Risco da contenção:
Próxima decisão e responsável:
```---
# Apêndice B — `kubectl` cheat sheet orientado a diagnóstico

Confirme context e namespace antes de qualquer comando. Comandos abaixo são de leitura, salvo quando indicado.

## B.1 Identidade e contexto

| Objetivo | Comando |
|---|---|
| context ativo | `kubectl config current-context` |
| todos os contexts | `kubectl config get-contexts` |
| trocar context | `kubectl config use-context NOME` |
| verificar autorização | `kubectl auth can-i get secrets -n NAMESPACE` |
| versões | `kubectl version` |

## B.2 Estado de workloads
```bash
kubectl get deploy,rs,pod -n NAMESPACE -o wide
kubectl describe pod POD -n NAMESPACE
kubectl get events -n NAMESPACE --sort-by=.metadata.creationTimestamp
kubectl logs POD -n NAMESPACE -c CONTAINER --since=30m
kubectl logs POD -n NAMESPACE -c CONTAINER --previous
kubectl rollout status deployment/APP -n NAMESPACE
kubectl rollout history deployment/APP -n NAMESPACE

B.3 Networking

kubectl get svc,endpointslice -n NAMESPACE
kubectl get networkpolicy -A
kubectl get gateway,httproute -A
kubectl describe httproute ROUTE -n NAMESPACE
kubectl port-forward -n NAMESPACE service/APP 8080:80

B.4 Resources e scheduling

kubectl top nodes
kubectl top pods -n NAMESPACE --containers
kubectl describe node NODE
kubectl get resourcequota,limitrange -n NAMESPACE
kubectl get pod POD -n NAMESPACE -o jsonpath='{.spec.nodeName}'

B.5 Storage

kubectl get storageclass
kubectl get pv
kubectl get pvc -n NAMESPACE
kubectl describe pvc CLAIM -n NAMESPACE
kubectl get volumesnapshot -A

B.6 Mudanças com cautela

Use --dry-run=server quando aplicável e revise o diff:
bash kubectl diff -f manifests/ kubectl apply --server-side --dry-run=server -f manifests/—

Apêndice C — Matrizes de decisão

C.1 Workload

C.2 Exposição

C.3 Configuração e dados

C.4 Scaling

Apêndice D — Antipatterns e correções

Apêndice E — Active Recall e Feynman

Responda sem consultar o texto. Depois confronte a resposta com o capítulo.

1. Qual problema Kubernetes resolve além de executar containers?
2. Qual a diferença entre image, container e Pod?
3. Como API server, etcd, scheduler e kubelet cooperam?
4. O que acontece entre desired state e current state?
5. Por que status.observedGeneration importa?
6. Como labels, selectors e ownerReferences relacionam objetos?
7. Por que Pod Running pode estar indisponível?
8. Quando startup probe protege liveness?
9. Quando usar Deployment, StatefulSet, DaemonSet ou Job?
10. Por que Job exige idempotência?
11. O que ConfigMap e Secret não resolvem?
12. Como Service encontra Pods?
13. Por que Ingress sem controller não funciona?
14. Que ownership Gateway API torna explícito?
15. Quais camadas formam o caminho cliente → container?
16. O que NetworkPolicy controla e o que não controla?
17. Por que request e uso real são medidas diferentes?
18. Como QoS influencia eviction?
19. Qual a diferença entre taint, toleration e affinity?
20. Por que réplicas precisam de topology spread?
21. O que PDB protege e o que não protege?
22. Como PVC, PV, StorageClass e CSI se relacionam?
23. Por que snapshot pode não ser backup suficiente?
24. Como autenticação, autorização e admission diferem?
25. Como criar Pod pode levar a privilege escalation?
26. Qual a diferença entre Events, logs, metrics e traces?
27. Como diagnosticar CrashLoopBackOff?
28. Qual fórmula conceitual orienta o HPA?
29. Por que mais Pods podem piorar um banco saturado?
30. Como rolling, blue-green e canary diferem?
31. O que GitOps reconcilia e o que Synced não prova?
32. Qual a diferença entre CRD, controller e Operator?
33. O que precisa ser salvo além do etcd?
34. Que responsabilidades permanecem em Kubernetes managed?

Técnica Feynman

Explique para uma pessoa que conhece Docker, mas nunca operou Kubernetes:

• “Kubernetes é uma API com control loops.”
• “Pod não é uma pequena VM.”
• “Service é identidade estável sobre endpoints efêmeros.”
• “Readiness controla tráfego; liveness controla reinício.”
• “Request é uma promessa usada pelo scheduler.”
• “Namespace não equivale a isolamento de máquina.”
• “Três réplicas podem continuar formando um single failure domain.”
• “Backup só existe quando restore foi demonstrado.”

Inclua em cada explicação um exemplo, um contraexemplo e uma falha operacional.

Apêndice F — Projeto prático e rubric

F.1 Projeto

Implante em cluster de laboratório uma API Flask, um worker e dependências falsas. Entregue:

1. Dockerfile non-root e image versionada;
2. Namespace, quotas e Pod Security;
3. Deployments separados para API e worker;
4. probes e graceful shutdown;
5. ConfigMap e referência a Secret sem valor no Git;
6. Services e Gateway/Ingress local;
7. default-deny e allowlists de network;
8. requests, limits, HPA e topology spread;
9. PDB e teste de drain;
10. dashboards, logs correlacionados e alerts;
11. rolling update e rollback;
12. backup e restore de dado de laboratório;
13. runbook de três falhas;
14. relatório com limitações e evidências.

F.2 Fault injection

Simule com segurança:

• processo travado;
• readiness falhando;
• image inexistente;
• Secret ausente;
• selector incorreto;
• DNS ou egress bloqueado;
• limite de memória excedido;
• Node drenado;
• metrics provider indisponível;
• timeout ambíguo no fake GLPI.

F.3 Rubric

Pontue de 0 a 2 por dimensão. Violação crítica de segurança, perda de dados ou ausência de restore impede classificação “Excelente” mesmo com nota numérica alta.

Apêndice G — Glossário

Apêndice H — Plano de revisão espaçada

Na revisão, tente recuperar a resposta antes de reler. Atualize flags, API versions e feature states conforme a versão do cluster, mas preserve os modelos mentais.

Referências oficiais

1. Kubernetes Documentation
2. Kubernetes v1.37: Garhwal
3. Kubernetes Components
4. Nodes
5. Deployments
6. Organizing Cluster Access Using kubeconfig
7. StatefulSets
8. DaemonSet
9. Jobs
10. ConfigMaps
11. Good Practices for Kubernetes Secrets
12. Services, Load Balancing and Networking
13. Ingress Controllers
14. Gateway API
15. Network Policies
16. Resource Management for Pods and Containers
17. Kubernetes Scheduler
18. Taints and Tolerations
19. Pod Topology Spread Constraints
20. Pod Priority and Preemption
21. Persistent Volumes
22. Dynamic Volume Provisioning
23. RBAC Good Practices
24. Pod Security Standards
25. Resource Metrics Pipeline
26. HorizontalPodAutoscaler Walkthrough
27. Custom Resources
28. Options for Highly Available Topology
29. Helm Documentation
30. OpenGitOps Principles
31. Security Checklist
32. Application Security Checklist
33. Storage Classes
34. Volume Snapshots
35. Scheduling, Preemption and Eviction

Encerramento

Kubernetes torna explícitas decisões que antes ficavam dispersas em scripts e máquinas: quantas réplicas devem existir, onde podem executar, como recebem tráfego, que recurso consomem, que storage montam e quais identidades podem agir. A plataforma não elimina falhas; ela oferece APIs e control loops para detectá-las, limitar seu alcance e recuperar estado.

O domínio profissional de Kubernetes não é medido pelo número de comandos memorizados. Ele aparece na capacidade de explicar por que um Pod está Pending, o que uma probe realmente significa, como um Service chega a seus endpoints, por que um retry pode duplicar um efeito e como restaurar dados depois de uma perda real.

Uma operação madura combina artefato imutável, desired state versionado, least privilege, capacity conhecida, observability correlacionada, progressive delivery e recovery testado. O resultado não é apenas um cluster funcionando hoje, mas uma plataforma que pode mudar, falhar e ser recuperada de maneira compreensível.