Entendendo a Diferença Fundamental entre Pods e Nodes no Kubernetes

Se você é novo no Kubernetes, a distinção entre pod e node é uma das primeiras coisas que faz o resto do sistema fazer sentido. Um node é a máquina. Um pod é a carga de trabalho que o Kubernetes coloca nessa máquina. Os contêineres são executados dentro de pods, e os pods são executados em nodes.

Isso parece simples, mas explica muitas situações comuns de solução de problemas. Se um pod está Pending, o Kubernetes pode não ter encontrado um node adequado. Se um node está NotReady, todos os pods nele estão em risco. Se seu aplicativo precisa de alta disponibilidade, executar mais contêineres não é suficiente; você precisa de réplicas distribuídas em diferentes nodes.

Visão Geral da Arquitetura do Cluster Kubernetes

Um cluster Kubernetes é composto por um conjunto de máquinas (físicas ou virtuais) trabalhando juntas. Essas máquinas são amplamente categorizadas em Control Plane (o cérebro que gerencia o estado do cluster) e Worker Nodes (o músculo que executa as cargas de trabalho reais). O Pod e o Node interagem dentro dessa estrutura.

Node: A máquina física ou virtual que fornece CPU, memória, disco e rede.
Pod: A menor unidade implantável que o Kubernetes agenda. Ele hospeda um ou mais contêineres.

Entender essa hierarquia—onde Nodes hospedam Pods, e Pods hospedam Contêineres—é o ponto de partida para o domínio do Kubernetes.

O Node Kubernetes: A Base do Poder Computacional

Um Node Kubernetes (às vezes chamado de Worker Machine) é uma máquina que fornece os recursos computacionais necessários—CPU, RAM e rede—para executar seus aplicativos. Um cluster deve ter pelo menos um Node, embora ambientes de produção normalmente utilizem muitos para redundância e escalabilidade.

Principais Responsabilidades de um Node

Cada Node executa componentes essenciais que permitem a comunicação com o Control Plane e hospedar cargas de trabalho de aplicativos:

Kubelet: Um agente executado em cada Node responsável por se comunicar com o Control Plane. Ele trabalha com o runtime de contêiner para garantir que os contêineres descritos nos PodSpecs estejam em execução e saudáveis em seu Node.
Container Runtime: O software responsável por baixar imagens e executar contêineres, comumente containerd ou CRI-O em clusters modernos.
Kube-proxy: Mantém regras de rede no Node, permitindo a comunicação de e para Pods, tanto interna quanto externamente.

Exemplo Prático: Representação de Node

Quando você inspeciona os Nodes em seu cluster, está vendo a infraestrutura subjacente que o Kubernetes está utilizando:

kubectl get nodes

NAME           STATUS   ROLES    AGE     VERSION
worker-node-01 Ready    <none>   2d1h    v1.27.4
worker-node-02 Ready    <none>   2d1h    v1.27.4

Conclusão Principal: Um Node é a camada da máquina onde a execução ocorre.

O Pod Kubernetes: A Menor Unidade Implantável

Um Pod é a unidade atômica de implantação no Kubernetes. Não é um contêiner em si, mas sim um invólucro em torno de um ou mais contêineres que são garantidos de estar co-localizados no mesmo Node e compartilhar recursos.

Por que Pods em Vez de Contêineres Diretos?

O Kubernetes gerencia Pods, não contêineres individuais, por várias razões críticas:

Contexto Compartilhado: Todos os contêineres dentro de um único Pod compartilham o mesmo namespace de rede (endereço IP e intervalo de portas) e podem se comunicar facilmente via localhost.
Armazenamento Compartilhado: Contêineres no mesmo Pod podem acessar os mesmos volumes de armazenamento montados.
Gerenciamento de Ciclo de Vida: O Kubernetes trata o Pod como uma única entidade. Se algum contêiner dentro do Pod falhar, o Kubernetes lida com a reinicialização ou recriação de toda a estrutura do Pod.

Anatomia de um Pod

Na maioria das vezes, um Pod contém um único contêiner de aplicativo principal. No entanto, eles são frequentemente usados para o Padrão Sidecar, onde um contêiner secundário auxilia o primário (por exemplo, um agente de log, um proxy de malha de serviço).

Exemplo de Definição de Pod (YAML Simplificado)

O YAML a seguir define um Pod que envolve um único contêiner Nginx:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80

Conclusão Principal: Um Pod é o host lógico para seus contêineres de aplicativo e é a unidade que é agendada em um Node.

A Relação Central: Agendamento e Posicionamento

A interação fundamental entre Pods e Nodes é governada pelo Kubernetes Scheduler, que reside no Control Plane.

Como os Pods Chegam aos Nodes

Criação do Pod: Um usuário envia uma definição YAML para um Pod (ou um objeto de nível superior como um Deployment, que cria Pods) para o API Server.
Decisão de Agendamento: O Scheduler identifica o melhor Node disponível para executar esse Pod com base em solicitações de recursos, restrições e capacidade disponível.
Vinculação: Uma vez que um Node é escolhido, o Pod é vinculado a esse Node específico.
Execução: O Kubelet no Node designado percebe a nova atribuição do Pod, baixa as imagens necessárias e inicia os contêineres.

Ponto Crucial: Uma vez que um Pod é agendado em um Node, ele permanece nesse Node até ser encerrado, falhar permanentemente ou o Node falhar. O Kubernetes normalmente não migra Pods em execução entre Nodes.

Recurso	Node Kubernetes	Pod Kubernetes
Função	Fornece recursos computacionais físicos/virtuais.	Executa um ou mais contêineres de aplicativo.
Escopo	Nível de infraestrutura do cluster.	Nível de carga de trabalho do aplicativo.
Unidade de Agendamento	Recebe Pods do Scheduler.	A unidade que é agendada em um Node.
Componentes	Kubelet, Container Runtime, Kube-proxy.	Contêineres de Aplicativo, volumes compartilhados, IP compartilhado.
Quantidade	Geralmente alguns a muitos por cluster.	Pode ser centenas ou milhares dependendo da carga de trabalho.

Um Exemplo de Implantação Real

Imagine um aplicativo web com este Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: storefront
spec:
  replicas: 3
  selector:
    matchLabels:
      app: storefront
  template:
    metadata:
      labels:
        app: storefront
    spec:
      containers:
      - name: web
        image: example/storefront:v1
        ports:
        - containerPort: 8080

Isso não cria três nodes. Cria três réplicas de pod. O scheduler então decide quais nodes existentes devem executar esses pods. Em um cluster pequeno, você pode ver isso:

kubectl get pods -o wide

NAME                          READY   STATUS    NODE
storefront-6d8f8c7f9b-2xk9p   1/1     Running   worker-node-01
storefront-6d8f8c7f9b-7hxm4   1/1     Running   worker-node-02
storefront-6d8f8c7f9b-q4zpt   1/1     Running   worker-node-02

Existem três pods, mas apenas dois nodes estão envolvidos. Se worker-node-02 falhar, duas réplicas desaparecem de uma vez. O Deployment tentará substituí-las, mas precisa de capacidade de node saudável para fazer isso. É por isso que o posicionamento do node é importante mesmo quando seu Deployment tem várias réplicas.

Se você quiser incentivar o Kubernetes a distribuir réplicas entre nodes, use restrições de propagação de topologia ou anti-afinidade de pod. Você não precisa disso para toda ferramenta interna pequena, mas deve considerar para serviços voltados ao cliente onde a falha de um node não deve remover a maior parte da capacidade.

Pods São Descartáveis; Nodes São Capacidade Gerenciada

Uma mentalidade saudável do Kubernetes é que os pods são substituíveis. Deployments, ReplicaSets, StatefulSets, Jobs e DaemonSets criam e substituem pods o tempo todo. Um nome de pod com um sufixo aleatório não é algo em que você deve confiar para sempre.

Nodes também são substituíveis em um cluster bem gerenciado, mas são unidades de capacidade. Eles precisam de patches do sistema operacional, saúde do kubelet, espaço em disco suficiente, um runtime de contêiner funcional e conectividade de rede. Quando um node tem um problema, muitos pods podem sentir isso ao mesmo tempo.

Essa diferença aparece em como você depura:

Se um pod falha e outros pods no mesmo node estão saudáveis, comece pelos logs, configuração, probes, imagem e limites de recursos do pod.
Se muitos pods não relacionados no mesmo node falham, comece pelo node: pressão de disco, pressão de memória, status do kubelet, saúde do CNI e logs do runtime de contêiner.
Se novos pods não podem ser iniciados em lugar nenhum, observe a capacidade geral do cluster, cotas, regras de agendamento e saúde do control plane.

Equívocos Comuns

O primeiro equívoco é pensar que um pod é a mesma coisa que um contêiner. A maioria dos pods contém um contêiner principal, então o atalho parece inofensivo. Mas os sidecars tornam a distinção importante. Um proxy de malha de serviço, coletor de logs ou contêiner auxiliar pode ser executado no mesmo pod que o aplicativo. Eles compartilham o namespace de rede do pod, então localhost entre esses contêineres funciona dentro desse pod.

O segundo equívoco é pensar que o Kubernetes move um pod em execução para outro node como uma migração de VM ao vivo. Geralmente não faz isso. Se um node é drenado ou falha, o Kubernetes encerra ou perde o pod antigo e cria um pod substituto em outro lugar. Esse substituto tem uma identidade de pod diferente, e quaisquer alterações no sistema de arquivos local do contêiner do pod antigo são perdidas, a menos que tenham sido escritas em armazenamento persistente.

O terceiro equívoco é assumir que um Service é executado em um node. Um Service é uma abstração de rede estável na frente dos pods. Ele seleciona pods por rótulos e roteia o tráfego para seus IPs. Os Nodes fornecem o lugar onde esses pods são executados, mas o Service em si não está "em" um worker node da mesma forma que um pod está.

Como Isso Afeta o Design Diário

Quando você escolhe um número de réplicas, está escolhendo quantas cópias de pod o Kubernetes deve tentar manter em execução. Você não está escolhendo quantos nodes existirão. Um Deployment com dez réplicas ainda pode colocar vários pods no mesmo node, a menos que você adicione regras de distribuição e o cluster tenha capacidade de node suficiente.

Quando você escolhe o tamanho do node, está escolhendo a forma do pool de capacidade. Alguns nodes grandes podem ser eficientes, mas a falha de um node remove uma parcela maior de seus pods em execução. Mais nodes menores podem melhorar o isolamento de falhas, mas adicionam sobrecarga e podem tornar o empacotamento menos eficiente. Não há uma resposta universal; a escolha certa depende do tamanho da carga de trabalho, necessidades de disponibilidade e custo.

Cargas de trabalho com estado adicionam outra complexidade. Um StatefulSet ainda cria pods, e esses pods ainda são executados em nodes, mas cada pod pode ter uma identidade estável e um volume persistente. Se o node morrer, o Kubernetes pode recriar o pod em outro lugar, mas a camada de armazenamento precisa suportar a anexação ou acesso ao volume do novo local.

Melhores Práticas e Insights de Solução de Problemas

Entender essa arquitetura ajuda no gerenciamento prático do cluster:

Gerenciamento de Recursos

Resource Requests/Limits: Sempre defina requests e limits de recursos em suas especificações de Pod. Isso permite que o Scheduler corresponda com precisão os Pods aos Nodes que têm capacidade suficiente, evitando contenção de recursos.
Node Pressure: Se um Node ficar sobrecarregado (sem espaço em disco ou memória), o Kubelet relata essa condição. O Kubernetes pode então expulsar Pods desse Node para manter a estabilidade.

Alta Disponibilidade (HA)

Redundância: Para alcançar HA, você deve executar várias cópias (réplicas) de seus Pods, gerenciadas por Deployments ou StatefulSets. O Scheduler tentará colocar essas réplicas em Nodes diferentes para garantir que a falha de um Node não derrube todo o aplicativo.

Solução de Problemas

Quando um aplicativo não está iniciando:

Verifique o Status do Pod: Use kubectl describe pod <nome-do-pod>. Veja a seção 'Events' para saber em qual Node o Pod foi agendado.
Verifique o Status do Node: Se o Pod estiver preso em Pending, o problema geralmente está relacionado ao agendamento (por exemplo, nenhum Node atende às restrições necessárias). Se o Pod está em execução mas falhando, verifique os logs do Kubelet no Node específico onde ele está.

Comandos úteis:

kubectl get pods -o wide
kubectl describe pod <nome-do-pod>
kubectl get nodes
kubectl describe node <nome-do-node>

A saída -o wide é subestimada. Ela mostra em qual node cada pod está, o que muitas vezes é a pista que separa um problema de aplicativo de um problema de infraestrutura.

A Versão Resumida

Um node responde "onde isso pode ser executado?" Um pod responde "o que deve ser executado junto?" O scheduler conecta essas duas ideias colocando pods em nodes. Depois que você vê essa relação, os erros do Kubernetes se tornam mais fáceis de ler: pods pendentes são frequentemente problemas de posicionamento, pods com falha são frequentemente problemas de carga de trabalho, e nodes não saudáveis podem criar muitos problemas de pod ao mesmo tempo.