Os três conceitos fundamentais do Kubernetes — Cluster, Node e Pod — formam uma hierarquia simples. Entender o que cada um é, e o que roda dentro de cada um, é o ponto de partida para tudo mais no K8s.
A analogia física
Antes de entrar nos termos técnicos, uma analogia que funciona:
Pense em um datacenter. O datacenter inteiro é o Cluster — todo o ambiente que o Kubernetes gerencia. Dentro do datacenter existem servidores — esses são os Nodes. E dentro de cada servidor, rodam processos — esses são os Pods.
Mas ao contrário de um datacenter convencional, onde você decide manualmente em qual servidor cada processo vai rodar, o Kubernetes tem um sistema inteligente que faz isso por você, com base nos recursos disponíveis e nas suas regras.
Cluster: o universo do Kubernetes
O Cluster é o conjunto de todas as máquinas (físicas ou virtuais) que o Kubernetes gerencia. Quando você opera Kubernetes, você está operando um Cluster.
Um Cluster Kubernetes tem dois tipos de componentes: o Control Plane e os Worker Nodes. O Control Plane é o cérebro — toma decisões, mantém o estado desejado, responde às suas instruções. Os Worker Nodes são o músculo — onde suas aplicações realmente rodam.
Em produção, um Cluster saudável tem no mínimo 3 máquinas de Control Plane (para alta disponibilidade) e qualquer número de Worker Nodes, dependendo da carga.
Node: as máquinas do Cluster
Um Node é uma máquina (física ou VM) dentro do Cluster. Existem dois tipos:
Control Plane Nodes
O Control Plane é composto por quatro componentes principais que rodam nos seus próprios Nodes (geralmente separados dos Workers):
API Server (kube-apiserver): o ponto de entrada do Kubernetes. Todo comando que você dá via kubectl, todo objeto que você cria, passa pelo API Server. Ele valida as requisições, as autentica e as persiste no etcd.
etcd: o banco de dados distribuído do Kubernetes. Armazena o estado completo do Cluster — todos os objetos criados, configurações, status de cada Pod. É o componente mais crítico: se o etcd for perdido sem backup, o Cluster perde toda sua memória.
Scheduler (kube-scheduler): decide em qual Worker Node cada Pod vai rodar. Quando você cria um Pod, o Scheduler analisa os recursos disponíveis em cada Node (CPU, memória), as restrições que você definiu (affinity, taints) e escolhe o Node mais adequado.
Controller Manager (kube-controller-manager): executa os “controllers” — loops de controle que monitoram o estado do Cluster e agem quando o estado real diverge do estado desejado. O ReplicaSet Controller, por exemplo, monitora se o número de Pods está correto e cria ou destrói Pods conforme necessário.
Worker Nodes
Os Worker Nodes são onde suas aplicações rodam. Cada Worker Node tem três componentes:
kubelet: o agente do Kubernetes em cada Node. Recebe instruções do API Server, garante que os containers descritos nos Pods estão rodando e reporta o estado de volta ao API Server.
kube-proxy: gerencia as regras de rede no Node para implementar os Services do Kubernetes. Garante que o tráfego para um Service seja distribuído corretamente entre os Pods correspondentes.
Container Runtime: o motor que realmente executa os containers (containerd é o padrão atual). O kubelet instrui o runtime, que cria e gerencia os containers em si.
Pod: a unidade mínima do Kubernetes
O Pod é a menor unidade de implantação no Kubernetes. Um Pod é um grupo de um ou mais containers que:
- Compartilham a mesma rede: todos os containers de um Pod se enxergam via
localhost. Do ponto de vista de rede, eles estão na mesma máquina. - Compartilham o mesmo armazenamento: volumes montados no Pod são acessíveis por todos os containers dentro dele.
- Sempre rodam juntos no mesmo Node: o Kubernetes não divide um Pod entre Nodes. Se o Node falha, o Pod inteiro falha e é recriado em outro Node.
Na grande maioria dos casos, um Pod tem um único container — a sua aplicação. O modelo “um Pod, um container” é o mais comum e mais simples de gerenciar.
O caso de uso para múltiplos containers no mesmo Pod é o padrão sidecar: um container principal (sua aplicação) e um container auxiliar que fornece funcionalidade de suporte — um log forwarder, um proxy de segurança, um container de métricas. O sidecar precisa estar no mesmo contexto de rede e armazenamento que a aplicação, por isso vai no mesmo Pod.
Como o Scheduler decide onde um Pod roda
Quando você cria um Pod, o processo é:
- Você aplica o manifesto via
kubectl apply - O API Server valida e persiste o Pod no etcd com status “Pending”
- O Scheduler percebe o Pod pendente e avalia todos os Worker Nodes disponíveis
- O Scheduler filtra Nodes que não atendem os requisitos (recursos insuficientes, taints incompatíveis, affinity rules)
- Entre os Nodes elegíveis, o Scheduler pontua e escolhe o melhor (aquele com mais recursos disponíveis, respeitando balanceamento)
- O Scheduler atualiza o Pod no etcd indicando o Node escolhido
- O kubelet no Node escolhido percebe o Pod e instrui o runtime a criar o container
- O Pod entra em estado “Running”
Você pode influenciar o Scheduler com:
- nodeSelector: “rode esse Pod apenas em Nodes com a label X”
- affinity/anti-affinity: “prefira Nodes com label Y” ou “não rode no mesmo Node que o Pod Z”
- taints e tolerations: Nodes podem ser marcados com taints que repelem Pods que não têm a toleração correspondente (útil para Nodes especializados, como Nodes com GPU)
- resource requests: ao declarar quanto CPU e memória seu Pod precisa, você guia o Scheduler a escolher Nodes com capacidade suficiente
Precisa de Kubernetes em cloud privada com control plane gerenciado e suporte em português? A Adentro tem a solução certa para o seu ambiente.