Arquitetura do Kubernetes: control plane e nodes

1. Visão Geral da Arquitetura do Kubernetes

O Kubernetes é um sistema de orquestração de containers que organiza clusters em dois grandes grupos de componentes: o Control Plane (plano de controle) e os Nodes (nós trabalhadores). Essa arquitetura distribuída permite gerenciar centenas ou milhares de containers de forma automatizada, garantindo alta disponibilidade, escalabilidade e resiliência.

A comunicação entre todos os componentes acontece através do API Server, que funciona como o ponto central de todas as operações. Cada requisição, seja de um usuário, de um componente interno ou de uma ferramenta externa, passa pelo API Server, que autentica, autoriza e valida a ação antes de processá-la.

O papel do Kubernetes como orquestrador é garantir que o estado real do cluster corresponda ao estado desejado definido pelo usuário. Se um container falha, o sistema automaticamente o substitui; se a carga aumenta, novos Pods são criados; se um Node cai, as cargas de trabalho são movidas para outros Nodes.

2. Control Plane: O Cérebro do Cluster

O Control Plane é o conjunto de processos que tomam decisões globais sobre o cluster. Ele detecta eventos, responde a mudanças e mantém o cluster funcionando conforme o esperado.

API Server (kube-apiserver)

É o componente central que expõe a API do Kubernetes. Todas as operações internas e externas passam por ele. O API Server é stateless e pode ser escalado horizontalmente para suportar alta carga.

# Verificando o API Server em um cluster
kubectl get pods -n kube-system | grep api-server

# Exemplo de requisição direta ao API Server
kubectl get --raw /api/v1/nodes | head -20

etcd

É o banco de dados chave-valor que armazena todo o estado do cluster: configurações, segredos, definições de Pods, Services e muito mais. O etcd é a única fonte da verdade no Kubernetes. Em produção, deve ser configurado em cluster de 3 ou 5 nós para garantir alta disponibilidade.

# Verificando o estado do etcd (requer acesso ao cluster)
kubectl exec -n kube-system etcd-master -- etcdctl endpoint health

Scheduler (kube-scheduler)

Responsável por decidir em qual Node cada Pod será executado. Ele considera requisitos de recursos (CPU, memória), restrições de afinidade, taints/tolerations e políticas de prioridade.

# Visualizando decisões do scheduler nos eventos
kubectl get events --sort-by='.lastTimestamp' | grep -i schedule

3. Componentes Internos do Control Plane

Controller Manager (kube-controller-manager)

Executa diversos controladores que monitoram o estado do cluster e fazem ajustes para atingir o estado desejado. Os principais controladores incluem:

  • Node Controller: monitora a saúde dos Nodes
  • Replication Controller: garante o número correto de réplicas
  • Endpoint Controller: atualiza os Endpoints dos Services
  • Service Account Controller: gerencia contas de serviço e tokens
# Listando controladores ativos no cluster
kubectl get pods -n kube-system | grep controller-manager

# Verificando logs do Controller Manager
kubectl logs -n kube-system kube-controller-manager-master --tail=50

Cloud Controller Manager (cloud-controller-manager)

Integra o Kubernetes com provedores de nuvem (AWS, GCP, Azure). Gerencia Load Balancers, volumes persistentes e roteamento de rede específico da nuvem. Em clusters on-premise, esse componente pode ser omitido.

Alta Disponibilidade do Control Plane

Em produção, o Control Plane deve ser replicado para evitar ponto único de falha:

# Configuração mínima para HA (3 instâncias do API Server)
# Exemplo de health check do API Server
curl -k https://192.168.1.10:6443/healthz

4. Nodes: Os Trabalhadores do Cluster

Os Nodes são as máquinas (físicas ou virtuais) que executam as cargas de trabalho. Cada Node contém três componentes essenciais.

Kubelet

É o agente principal que roda em cada Node. Ele se comunica com o API Server, recebe especificações de Pods e garante que os containers estejam rodando conforme definido.

# Verificando o status do Kubelet em um Node
kubectl get nodes

# Visualizando logs do Kubelet (acesso no Node)
journalctl -u kubelet -n 100 --no-pager

Kube-proxy

Gerencia as regras de rede em cada Node, implementando o roteamento para Services. Ele mantém as regras de iptables ou IPVS que direcionam o tráfego para os Pods corretos.

# Verificando regras do kube-proxy (iptables)
kubectl get pods -n kube-system | grep kube-proxy

# Listando regras de rede para um Service específico
iptables-save | grep -i "kubernetes" | head -5

Container Runtime

É o software responsável por executar os containers. O Kubernetes suporta múltiplos runtimes:

  • Docker: runtime tradicional, amplamente utilizado
  • containerd: runtime leve e padrão da CNCF
  • CRI-O: runtime otimizado para Kubernetes
# Verificando qual runtime está em uso
kubectl get nodes -o jsonpath='{.items[*].status.nodeInfo.containerRuntimeVersion}'

5. Pods e a Interação com Nodes

Os Pods são a menor unidade de execução no Kubernetes. Cada Pod contém um ou mais containers que compartilham o mesmo namespace de rede e recursos de armazenamento.

Ciclo de Vida dos Pods

O Kubelet gerencia cada Pod desde sua criação até sua remoção:

# Criando um Pod simples
kubectl run nginx-pod --image=nginx --restart=Never

# Acompanhando o ciclo de vida
kubectl get pods -w

# Verificando detalhes do Pod
kubectl describe pod nginx-pod

Compartilhamento de Recursos

Os Pods em um mesmo Node competem por CPU, memória e I/O de disco. Para evitar conflitos, o Kubernetes permite definir limites e requisições de recursos:

apiVersion: v1
kind: Pod
metadata:
  name: resource-demo
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

6. Rede e Comunicação no Cluster

O Kubernetes adota um modelo de rede plano onde cada Pod recebe um IP único e pode se comunicar com qualquer outro Pod sem tradução de endereços.

CNI (Container Network Interface)

O plugin de rede implementa o modelo de rede do Kubernetes. Os mais comuns são Calico, Flannel, Weave e Cilium.

# Verificando o plugin CNI instalado
kubectl get pods -n kube-system | grep -E "calico|flannel|weave|cilium"

# Testando comunicação entre Pods
kubectl exec pod-a -- ping pod-b-ip

Service Discovery e DNS Interno

O Kubernetes fornece DNS interno para que os Pods encontrem Services pelo nome:

# Criando um Service
kubectl expose deployment nginx --port=80 --target-port=80

# Testando resolução DNS de dentro de um Pod
kubectl run test-dns --image=busybox --rm -it -- nslookup nginx

7. Monitoramento e Manutenção da Arquitetura

Verificando a Saúde dos Componentes

# Comando legado para verificar componentes (depreciado)
kubectl get componentstatuses

# Alternativa moderna: verificar Pods do sistema
kubectl get pods -n kube-system

# Health check do cluster
kubectl cluster-info

Logs e Métricas

# Logs do Control Plane (acesso no master)
sudo journalctl -u kube-apiserver -n 50
sudo journalctl -u etcd -n 50

# Métricas dos Nodes
kubectl top nodes
kubectl top pods --all-namespaces

Backup do etcd e Recuperação

# Backup do etcd (executar no nó master)
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# Restaurando backup
ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-snapshot.db \
  --data-dir=/var/lib/etcd-restored

Conclusão

A arquitetura do Kubernetes, dividida entre Control Plane e Nodes, oferece uma base sólida para orquestração de containers em produção. O Control Plane gerencia o estado desejado enquanto os Nodes executam as cargas de trabalho. Compreender essa separação é fundamental para operar clusters resilientes, diagnosticar problemas e otimizar recursos.

Referências