Arquitetura do Kubernetes

Kubernetes é um sistema de controle: você declara o estado desejado na API e controladores comparam esse desejo com o estado observado até reduzir a diferença. Não há uma sequência de comandos “executada uma vez”; a reconciliação continua após falha, restart e alteração manual.

Quem faz o quê

O kube-apiserver valida e expõe recursos. O etcd guarda o estado do cluster; trate seu backup, criptografia e acesso como críticos. Scheduler escolhe nó para Pods pendentes; controller manager mantém réplicas, endpoints e demais recursos convergentes. Em cada nó, o kubelet observa Pods atribuídos e pede ao runtime (como containerd) que execute containers.

kubectl get --raw='/readyz?verbose'
kubectl get nodes -o wide
kubectl get pods -A --field-selector=status.phase=Pending
kubectl get events -A --sort-by=.lastTimestamp | tail -30

Um Deployment não cria container diretamente: ele cria ReplicaSets, que criam Pods; o scheduler atribui o Pod; o kubelet então materializa os containers. Ao investigar, siga essa cadeia e leia eventos. Um Pod em Pending ainda não é problema de aplicação; um Pod atribuído que não sobe pode ser imagem, volume, probe ou runtime.

API declarativa não elimina responsabilidade

kubectl apply envia uma intenção, mas outros controladores podem modificá-la ou reconciliar uma versão do Git. Use kubectl diff -f manifest.yaml antes de aplicar e kubectl get recurso nome -o yaml para verificar o resultado real. Em produção, limite quem grava na API; credencial de admin no CI elimina a separação que GitOps oferece.

Nunca edite etcd diretamente. Backups devem ser consistentes, criptografados, testados em restauração e alinhados à versão do Kubernetes. Perder etcd é perder definições, segredos não externos e a identidade do cluster, mesmo que os discos dos nós existam.

Próximo passo: escolha o controlador correto e declare probes e recursos em Workloads. Para casos de falha, siga o Diagnóstico em Kubernetes.