Descreva a arquitetura do Kubernetes: control plane vs worker nodes e seus componentes.

Question

IT Interview Practice · Accepted Answer

Um cluster Kubernetes tem dois tipos de máquinas: o **control plane** (o "cérebro" que toma decisões e armazena o estado) e os **worker nodes** (onde seus Pods realmente rodam). Cada um tem um pequeno conjunto de componentes bem definidos.

## O panorama geral

```text
┌──────────────── CONTROL PLANE (o cérebro) ────────────────┐
│                                                            │
│   kube-apiserver ── a porta de entrada; TODA comunicação passa por ele│
│        │                                                   │
│   etcd ───────── key-value store: a FONTE DA VERDADE do    │
│                  cluster (todos os objetos & desired state)│
│   kube-scheduler ── decide em QUAL node um novo Pod roda   │
│   controller-manager ── roda os control loops (reconcilers)│
└──────────────────────────┬─────────────────────────────────┘
                           │ (apiserver)
   ┌───────────────────────┼───────────────────────┐
┌──┴─── WORKER NODE ──┐ ┌──┴─── WORKER NODE ──┐  ...
│ kubelet             │ │ kubelet             │
│ kube-proxy          │ │ kube-proxy          │
│ container runtime   │ │ container runtime   │
│  └ Pods (seus apps) │ │  └ Pods (seus apps) │
└─────────────────────┘ └─────────────────────┘
```

## Componentes do control plane

```text
kube-apiserver        O ponto de entrada único. Expõe a REST API; valida &
                      persiste objetos no etcd. kubectl, controllers e kubelets
                      falam APENAS com o apiserver.
etcd                  Key-value store distribuído e consistente. Guarda TODO o
                      estado do cluster (desejado + atual). Perder o etcd = perder o cluster.
kube-scheduler        Observa Pods sem node atribuído e escolhe o melhor node
                      (com base em resource requests, affinity, taints, etc.).
kube-controller-      Roda os control loops: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints, etc. Cada loop conduz atual → desejado.
cloud-controller-     (Na cloud) integra com o provedor: load balancers, routes,
manager               ciclo de vida do node.
```

## Componentes do worker node

```text
kubelet          O agente do node. Fala com o apiserver, inicia/para containers via
                 o runtime, e reporta o status de Pods & node. Ele faz a realidade do
                 node corresponder aos Pods atribuídos a ele.
kube-proxy       Programa a rede do node (iptables/IPVS) para que os IPs virtuais dos
                 Services sejam balanceados para os endpoints de Pod corretos.
container runtime O software que realmente roda os containers (containerd, CRI-O).
```

## Como um "kubectl apply" flui pelo sistema

```text
1. kubectl → kube-apiserver: "Quero um Deployment com 3 replicas"
2. o apiserver valida & grava o objeto no etcd
3. o controller-manager (deployment→replicaset controller) o vê, cria 3 objetos Pod
4. o scheduler vê 3 Pods sem atribuição, atribui cada um a um node (grava de volta via apiserver)
5. o kubelet de cada node vê seus Pods, manda o runtime baixar imagens & iniciar containers
6. o kube-proxy conecta a rede do Service para o tráfego chegar aos novos Pods
Tudo é um loop de WATCH + RECONCILE mediado pelo apiserver.
```

```bash
kubectl get nodes                 # lista nodes (control-plane + workers)
kubectl get pods -n kube-system   # ver os componentes do control-plane / sistema
kubectl get componentstatuses     # saúde das peças centrais do control-plane
```

## Por que isso importa

Entender a divisão entre o control plane e os worker nodes — e o papel de cada componente — é o que transforma o Kubernetes de uma caixa-preta num sistema sobre o qual você consegue raciocinar e operar, então é conhecimento central para qualquer engenheiro de nível pleno ou acima. O **control plane** é o cérebro que toma decisões: o **kube-apiserver** é a única porta de entrada pela qual todo componente e usuário se comunica; o **etcd** é o key-value store consistente que guarda todo o estado do cluster e é a fonte da verdade (perdê-lo significa perder o cluster); o **scheduler** decide em qual node cada novo Pod aterrissa; e o **controller-manager** roda os reconciliation loops que conduzem continuamente o estado real em direção ao desired state. Em cada **worker node**, o **kubelet** é o agente que faz os containers do node corresponderem aos Pods atribuídos a ele, o **kube-proxy** programa a rede que faz os IPs virtuais dos Services rotearem para os Pods corretos, e um **container runtime** (containerd, CRI-O) realmente roda os containers. Ver como um único `kubectl apply` flui por esse sistema — apiserver para etcd, controllers criando objetos, scheduler posicionando Pods, kubelets iniciando containers, kube-proxy conectando a rede, tudo como loops de watch-and-reconcile — revela o design elegante e consistente por trás da plataforma. Esse modelo mental é exatamente o que você precisa para debugar por que um Pod está preso em Pending (scheduler), por que o cluster está sem resposta (apiserver/etcd) ou por que um Service não está roteando (kube-proxy), tornando-o indispensável para operar e diagnosticar clusters reais.

O panorama geral

Componentes do control plane

Componentes do worker node

Como um "kubectl apply" flui pelo sistema

Por que isso importa

Perguntas relacionadas