Kubernetes: pod, Deployment × StatefulSet × DaemonSet, Service × Ingress, HPA, control plane

A ideia que organiza o assunto

O contêiner resolveu o empacotamento. Sobrou o problema difícil: operar centenas deles em dezenas de máquinas. Quem reinicia o processo que morreu às três da manhã? Quem descobre em que máquina ele subiu de novo, já que o endereço mudou?

O Kubernetes responde de um jeito específico, e é esse jeito que organiza o assunto inteiro: você não manda executar nada. Declara o estado desejado — “quero seis réplicas desta imagem” — e o cluster compara continuamente esse desejo com a realidade, corrigindo a diferença. É o reconciliation loop.

Tudo o mais é consequência. Self-healing não é um recurso separado: um contêiner morto já é uma diferença, e será corrigida. Um rollout não é um comando, é uma mudança no estado desejado que o cluster persegue. Um rollback é declarar de novo o estado anterior. Guardado o laço, metade das questões deste tópico se responde sem decorar nada.

Por que se usa (e o que custa)

Ganha-se operação declarativa e versionável: a infraestrutura passa a ser um arquivo que se revisa, e não uma sequência de comandos que alguém executou e ninguém registrou.

Paga-se em dois lugares. O modelo só funciona se houver onde guardar o estado desejado — daí o etcd, e daí a fragilidade de um cluster cujo etcd ninguém sabe restaurar. E paga-se em superfície de configuração: um Deployment mínimo já tem quatro níveis de aninhamento em YAML, e nada no arquivo avisa quando o label selector está errado.

A formulação honesta para a prova: o Kubernetes troca complexidade operacional distribuída por complexidade de configuração centralizada. Ele não elimina a dificuldade; move-a para onde ela é declarada.

Como funciona

O cluster tem duas metades, e quase toda questão mora na fronteira entre elas.

O plano de controle decide. O kube-apiserver é a única porta de entrada: tudo fala com ele, e só ele fala com o etcd, o banco chave-valor onde o estado vive. O kube-scheduler escolhe em que nó cada pod novo vai rodar — e apenas escolhe, não inicia nada. O kube-controller-manager abriga os laços de reconciliação propriamente ditos.

O nó executa. O kubelet recebe do apiserver os pods que lhe couberam e pede ao container runtime que os suba. O kube-proxy programa as regras de rede que fazem um Service virar tráfego real.

A unidade mínima não é o contêiner: é o pod, um ou mais contêineres que compartilham network namespace — logo, o mesmo IP e o mesmo espaço de portas — e podem compartilhar volumes. Daí dois contêineres do mesmo pod conversarem por localhost, e daí não poderem escutar a mesma porta.

O acesso à rede tem dois andares. O Service opera em camada 4: dá nome DNS e IP virtual estáveis a um conjunto de pods escolhidos por label selector. O Ingress opera em camada 7: roteia por host e por caminho HTTP e termina TLS. Ele não substitui o Service — encaminha para um. Por fim o HPA ajusta o número de réplicas a partir de uma métrica observada.

O que decide os itens

Um item de Certo/Errado não é decidido por um assunto, e sim por uma distinção. Estas são as que decidem aqui.

Cargas de trabalho — o par que a banca mais troca:

	usa quando	o que garante
Deployment	aplicação sem estado	N réplicas intercambiáveis, via ReplicaSet; rolling update e rollback
StatefulSet	aplicação com estado	identidade estável (web-0), ordem de criação e término, volume por réplica
DaemonSet	agente de infraestrutura	uma cópia por nó — não há número de réplicas a definir

Quem faz o quê — decidir × guardar × executar:

componente	faz	não faz
kube-scheduler	escolhe o nó	não inicia o contêiner
etcd	guarda o estado	não agenda, não executa
kubelet	executa no nó	não escolhe o nó
kube-apiserver	única porta de entrada	não executa carga de trabalho
HPA	muda a quantidade de pods	não muda o tamanho de cada um

Exposição — ClusterIP (padrão, só dentro do cluster) × NodePort (mesma porta em todos os nós) × LoadBalancer (balanceador do provedor) × Ingress (camada 7, roteia por host e caminho).

Pod — um ou mais contêineres; um IP por pod, não por contêiner; recriado, o pod recebe outro IP, e é por isso que se fala com ele através de um Service.

Como a CEBRASPE derruba você aqui

Inversão de papéis — 33%, a mais frequente por larga margem. “cada pod gerencia os kubelets e os contêineres que estiverem contidos nos nós do cluster” — a cadeia de comando ao contrário: o pod é o objeto gerenciado, nunca o gerente. “A ferramenta Kubeadm é responsável por criar e gerenciar diretamente todos os pods e contêineres no cluster” — o kubeadm inicializa e adiciona nós (init, join); quem cria e mantém pod em cada nó é o kubelet. “Worker nodes têm a função de coordenar tarefas dos pods e manter a saúde do cluster, sendo o master node o local onde os pods são executados” — as duas metades da arquitetura trocadas. E “cada Pod necessita de pelo menos um cluster para executar um nó de trabalho” — a hierarquia de cabeça para baixo. A defesa é uma só: monte a cadeia antes de ler o item. Cluster contém nó, nó executa pod, pod contém contêiner; plano de controle manda no kubelet, kubelet manda no runtime, runtime roda o contêiner. Qualquer seta apontando para cima está errada.

Troca de termo — 27%, quase sempre dentro do comando ou do manifesto. Não é o conceito que muda de nome: é o que está escrito no YAML ou na linha do kubectl. Um manifesto com kind: Service e a afirmação de que “será criado um deployment” — o kind decide o objeto, e aquele arquivo não implanta imagem nenhuma. “o comando kubectl get nodes permite que se crie um pod” — o verbo get nunca escreve; criar é run ou apply. Um replicas: 2 apresentado como “dois contêineres serão executados dentro de um único pod” — replicas conta pods, cada um com seu IP; contêiner no mesmo pod é entrada da lista containers. E o kubectl cordon, que “permite anexar ao nodeX processo associado ao podY” — cordon marca o nó como não escalonável; anexar é attach, executar é exec. Leia o kind e o verbo antes do substantivo da frase.

Atribuição errada — 20%. Ação real, componente errado. “o componente etcd” descrito como quem observa pods sem nó atribuído e escolhe um nó para eles — isso é o kube-scheduler; o etcd guarda estado, não decide. O kube-scheduler descrito como quem passa a “controlar o aumento e a diminuição da quantidade de pods” — quem varia réplicas conforme o consumo é o HorizontalPodAutoscaler. E a negação de capacidade: o Kubernetes “ainda que não ofereça autenticação centralizada” — todo acesso passa pelo kube-apiserver, com certificado de cliente, token de service account ou OIDC, e autorização por RBAC. Decidir × guardar × executar resolve quase todos: scheduler decide, etcd guarda, kubelet executa.

Generalização — 13%. O plano de controle que “deve ser executado em uma única máquina (virtual ou física)” — em produção ele roda replicado justamente para tolerar falha; máquina única é cenário de laboratório, minikube ou kind. E “o Kubernetes garantirá que nenhum pod seja interrompido durante operações de manutenção”, dito de um PodDisruptionBudget — o orçamento só governa disrupção voluntária: falha de hardware, kernel panic ou pressão de recursos não pedem licença.

Causa inventada — uma vez em quinze. “o Kubernetes utiliza armazenamento do tipo NTFS” para se integrar a ambientes Windows — o Kubernetes não escolhe sistema de arquivos; volume, PersistentVolume e driver CSI abstraem o armazenamento, e o sistema de arquivos é o do backend que provisionou o volume. Quando o item oferece um porquê, confira se o mecanismo citado sequer existe antes de aceitar a causa.

Erros clássicos

Achar que o Kubernetes executa contêineres. Ele agenda e reconcilia; quem executa é o runtime, chamado pelo kubelet. Muita questão se resolve sozinha depois que essa separação está firme.

Confundir “sem estado” com “sem volume”. Um Deployment pode montar volume. O que ele não dá é identidade estável e um volume por réplica.

Contar réplicas em DaemonSet. Não há campo de réplicas: a quantidade é o número de nós elegíveis.

Tratar Ingress como substituto de Service. O Ingress aponta para um Service e exige um ingress controller instalado — sem ele, o cluster aceita o YAML e não roteia coisa alguma.

Esquecer que o etcd é o único estado. Nó cai, você repõe. etcd sem backup, você perdeu o cluster.