Quais são os principais componentes da arquitetura do Kubernetes e do que cada um é responsável?

Um cluster Kubernetes consiste em um plano de controle mais um conjunto de máquinas de trabalho, chamadas nós, que executam aplicações em contêineres em Pods. Todo cluster precisa de pelo menos um nó de trabalho para executar Pods.

Conceitualmente, o Kubernetes é declarativo: você envia o estado desejado ao servidor de API (armazenado no etcd), e os controladores executam loops contínuos de reconciliação que observam diferenças e agem para direcionar o estado real ao estado desejado.

Componentes do plano de controle

O plano de controle toma decisões globais sobre o cluster (como o agendamento) e responde a eventos do cluster. Em produção, normalmente ele é executado em várias máquinas para alta disponibilidade.

• kube-apiserver — o componente central que expõe a API HTTP do Kubernetes. Ele é a interface do plano de controle e o ponto único de contato: toda autenticação, autorização, validação de solicitações e leituras/gravações do estado do cluster passam por ele. Ele escala horizontalmente. Em implantações normais, é o único componente do Kubernetes que lê e grava diretamente o estado do cluster no etcd; todos os outros componentes interagem com o estado por meio do servidor de API.
• etcd — um armazenamento de chave-valor consistente e altamente disponível usado como repositório de base do Kubernetes para todos os dados do cluster: configuração, estado e metadados. O etcd é obrigatório e é a única fonte da verdade — perdê-lo significa perder todo o estado do cluster, portanto ele deve operar com quorum (um número ímpar de membros) e ser submetido a backups regularmente.
• kube-scheduler — observa Pods ainda não vinculados a um nó e atribui cada Pod a um nó adequado, considerando recursos, restrições e políticas.
• kube-controller-manager — executa controladores que implementam o comportamento da API do Kubernetes (por exemplo, Node controller, Job controller, EndpointSlice controller). Cada controlador observa o estado desejado e reconcilia o estado real em direção a ele.
• cloud-controller-manager (opcional) — integra-se ao provedor de nuvem subjacente, isolando a lógica específica da nuvem dos componentes centrais do Kubernetes.

Componentes do nó

Eles são executados em cada nó, mantendo os Pods em funcionamento e fornecendo o ambiente de execução.

• kubelet — o agente que garante que os Pods estejam em execução, inclusive seus contêineres. Ele observa o servidor de API em busca de atribuições de Pods, inicia contêineres por meio do runtime, monta volumes, executa verificações de liveness/readiness e relata o status do nó.
• kube-proxy — implementa a rede de Services programando regras de iptables ou IPVS nos nós para que o tráfego destinado a um Service seja encaminhado para os IPs corretos dos Pods. Ele é marcado como opcional porque alguns plugins CNI (por exemplo, Cilium em modo eBPF) assumem sua função, mas em um cluster padrão ele é necessário.
• Runtime de contêiner — o software responsável por executar contêineres (containerd, CRI-O etc., por meio da interface CRI).

Complementos

Os complementos estendem a funcionalidade do cluster: DNS do cluster (CoreDNS por padrão), a interface web Dashboard, monitoramento de recursos de contêiner e logging em nível de cluster.

Pergunta de acompanhamento comum: toda comunicação passa pelo servidor de API — o scheduler, os controladores e os kubelets simplesmente o observam e reagem — o que faz do servidor de API o hub crítico do cluster.