Conceitos · Arquitetura

O Reconciliation Loop

O princípio mais fundamental do Kubernetes. Tudo — Deployments, Services, HPAs, Karpenter — funciona com o mesmo loop: observe → diff → act → repita.

// SIMULAÇÃO INTERATIVA — REPLICASET CONTROLLER
Deployment com replicas: 3. Estado atual: 2 pods
👁️Observe
🔍Diff
Act
🔄Loop

1. Observar o estado atual

O controller lê o estado atual do cluster via API Server. Ex: ReplicaSet controller conta quantos Pods com seus labels estão Running.

Estado atual: 2 pods rodando
// Controller observa via watch
informer.AddEventHandler(cache.ResourceEventHandlerFuncs{
  AddFunc:    controller.enqueue,
  UpdateFunc: controller.enqueue,
  DeleteFunc: controller.enqueue,
})
Pods:
📦
📦
2/3 aguardando...

💡 Por que isso importa na prática

É declarativo, não imperativo

Você diz QUAL é o estado desejado, não COMO chegar lá. 'Quero 3 réplicas' — o K8s descobre como fazer.

É auto-healing por design

Se um pod morrer, o controller detecta a divergência e cria um novo. Não há 'modo manual' — o loop nunca para.

Controllers são idempotentes

Aplicar o mesmo manifest N vezes tem o mesmo resultado que aplicar 1 vez. Safe to retry.

Tudo é um controller

Deployment, HPA, cert-manager, Karpenter, ArgoCD — todos usam o mesmo padrão. Entendeu um, entendeu todos.

Controllers no EKS — todos seguem o mesmo padrão

Deployment Controller
observa →Deployments
age →ReplicaSets
ReplicaSet Controller
observa →ReplicaSets
age →Pods
Node Controller
observa →Nodes
age →marca pods Unknown
Service Controller
observa →Services
age →ELB na AWS
Job Controller
observa →Jobs
age →Pods até conclusão
Karpenter
observa →Pods Pending
age →EC2 instances