Kubernetes: arquitetura, Pods, Deployments, Services e escalabilidade

Depois que uma aplicação é empacotada em uma imagem de container, surge outra questão:

como executar e administrar vários containers de forma confiável em diferentes servidores?

Em ambientes pequenos, iniciar alguns containers manualmente pode ser suficiente. Mas, à medida que a aplicação cresce, surgem problemas de escala, disponibilidade e automação:

• onde cada workload deve executar?

• como manter o número desejado de réplicas?

• como substituir containers que falham?

• como distribuir tráfego?

• como atualizar versões sem interromper o serviço?

• como escalar quando a demanda aumenta?

É nesse cenário que entra o Kubernetes.

O Kubernetes é uma plataforma de código aberto para automatizar deployment, escalabilidade e gerenciamento de aplicações em containers.

Seu papel está acima do runtime:

orquestrar workloads containerizados em um cluster.

Kubernetes não é um runtime de containers

Kubernetes não executa containers diretamente.

Os nodes utilizam um container runtime compatível com a Container Runtime Interface, como:

• containerd;

• CRI-O.

O fluxo pode ser entendido assim:

Código + Dockerfile → Imagem → Registry → Kubernetes → Pod → Container Runtime → Container

O Docker pode construir a imagem.

O registry armazena essa imagem.

O Kubernetes decide onde o workload deverá executar.

O runtime do node baixa a imagem e inicia os containers.

Cluster: a unidade básica do Kubernetes

Um ambiente Kubernetes é organizado como um cluster.

De forma simplificada, ele possui duas grandes partes:

Control Plane

e

Worker Nodes

O Control Plane coordena o cluster.

Os Nodes executam os workloads.

Control Plane ↓ Node 1 Node 2 Node 3 ↓ ↓ ↓ Pods Pods Pods

Control Plane coordena o cluster

O Control Plane recebe configurações, armazena o estado do cluster, decide onde workloads serão executados e reconcilia continuamente o ambiente.

Entre os principais componentes estão:

API Server

O kube-apiserver é a porta de entrada da API do Kubernetes.

Usuários, automações e componentes do próprio cluster interagem com o ambiente por meio dele.

etcd

O etcd armazena o estado do cluster em um banco distribuído chave-valor.

Informações sobre objetos, configurações e estado desejado são persistidas ali.

Scheduler

O kube-scheduler analisa Pods ainda não atribuídos a um node e decide onde eles deverão executar.

A decisão pode considerar:

• recursos disponíveis;

• requests de CPU e memória;

• afinidade e anti-afinidade;

• taints e tolerations;

• restrições de topologia.

Controller Manager

O kube-controller-manager executa controladores que observam continuamente o estado do cluster.

Se o estado atual não corresponde ao estado desejado, os controladores tentam corrigir essa diferença.

Worker Nodes executam os workloads

Os Worker Nodes são as máquinas onde os Pods realmente executam.

Podem ser:

• máquinas físicas;

• máquinas virtuais;

• instâncias em cloud.

Cada node possui componentes importantes.

kubelet

O kubelet é o agente executado em cada node.

Ele trabalha para garantir que os containers definidos para os Pods estejam em execução.

Container Runtime

É responsável por baixar imagens e executar containers.

Exemplos comuns:

containerd

CRI-O

kube-proxy

O kube-proxy participa da implementação de conectividade e regras de rede relacionadas aos Services.

Pod é a menor unidade implantável

O Pod é a menor unidade implantável do Kubernetes.

Um Pod pode conter um ou mais containers que compartilham recursos como:

• rede;

• endereço IP;

• volumes;

• contexto de execução.

Na maioria das aplicações existe um container principal por Pod, embora existam padrões com containers auxiliares, como sidecars.

Pods são efêmeros.

Podem ser recriados, substituídos ou movidos para outro node.

Por isso, aplicações não deveriam depender da identidade permanente de um Pod específico.

Deployment gerencia réplicas e atualizações

O Deployment é muito utilizado para aplicações stateless.

Exemplo:

Aplicação Web Réplicas desejadas: 3 Imagem: app:2.4.0

O Kubernetes trabalha para manter três Pods correspondentes em execução.

Se um Pod falhar, outro pode ser criado.

Por trás de um Deployment normalmente existe um ReplicaSet, responsável por manter a quantidade desejada de Pods.

Rolling Update reduz indisponibilidade

Quando a imagem da aplicação muda, o Deployment pode substituir as réplicas gradualmente.

3 Pods v1 ↓ 2 Pods v1 + 1 Pod v2 ↓ 1 Pod v1 + 2 Pods v2 ↓ 3 Pods v2

Essa estratégia reduz o impacto da atualização.

Service fornece um ponto estável de acesso

Pods podem ser recriados e receber novos endereços IP.

Então surge a pergunta:

como outros componentes encontram uma aplicação cujo conjunto de Pods pode mudar?

É aí que entra o Service.

Em vez de acessar Pods diretamente:

Cliente → Pod 1 Cliente → Pod 2 Cliente → Pod 3

a aplicação acessa:

Cliente → Service → Pods

O Service fornece um endpoint estável e direciona tráfego para os Pods correspondentes.

Labels e selectors conectam objetos

Kubernetes utiliza labels para identificar recursos.

Um Pod pode ter:

app=portal env=production

Um Service pode selecionar:

app=portal

Assim, qualquer Pod compatível com esse selector pode receber tráfego daquele Service.

Tipos de Service

Os tipos mais comuns incluem:

ClusterIP

Expõe o Service internamente no cluster.

NodePort

Expõe uma porta em cada node.

LoadBalancer

Solicita um balanceador externo quando a infraestrutura oferece integração compatível.

ExternalName

Representa um serviço externo por meio de DNS.

Ingress organiza acesso HTTP e HTTPS

Quando várias aplicações precisam ser expostas externamente, o Ingress permite definir regras de roteamento.

empresa.com/api → Service API empresa.com/site → Service Frontend

É importante diferenciar:

Ingress é o recurso de configuração.

Ingress Controller é o componente que implementa essas regras.

ConfigMap separa configuração da imagem

Uma imagem deveria ser reutilizável.

ConfigMaps permitem armazenar configurações não sensíveis fora da imagem, como:

• URL de API;

• nome do ambiente;

• feature flags;

• parâmetros da aplicação.

Assim, a mesma imagem pode ser usada em desenvolvimento, homologação e produção com configurações diferentes.

Secrets armazenam informações sensíveis

Secrets são utilizados para fornecer dados como:

• senhas;

• tokens;

• chaves;

• credenciais.

Mas um Secret não deve ser tratado automaticamente como um cofre completo.

É preciso considerar:

• criptografia em repouso;

• RBAC;

• rotação de credenciais;

• acesso ao cluster;

• integração com secret managers.

Requests e Limits ajudam a controlar recursos

Containers podem declarar:

requests

e

limits

Requests ajudam o Scheduler a decidir onde o workload cabe.

Limits restringem consumo máximo de determinados recursos.

Exemplo:

CPU request: 250m CPU limit: 500m Memory request: 256Mi Memory limit: 512Mi

Sem esse planejamento, o cluster pode sofrer com contenção e consumo imprevisível.

Probes ajudam o Kubernetes a avaliar saúde

Kubernetes utiliza probes para verificar diferentes estados da aplicação.

Liveness Probe

Responde:

o container ainda está saudável ou precisa ser reiniciado?

Readiness Probe

Responde:

esse Pod está pronto para receber tráfego?

Startup Probe

Ajuda aplicações que precisam de mais tempo para inicializar.

Um processo estar ativo não significa que a aplicação esteja pronta para atender usuários.

Self-healing depende de controladores e sinais

Kubernetes pode reagir a falhas como:

• container falha → reinício;

• Pod desaparece → nova réplica;

• node fica indisponível → workload pode ser recriado;

• readiness falha → Pod deixa de receber tráfego.

Isso é o que normalmente chamamos de self-healing.

Mas a qualidade das probes e da configuração continua sendo essencial.

Escalabilidade pode ser horizontal

O Horizontal Pod Autoscaler (HPA) pode aumentar ou reduzir o número de Pods com base em métricas.

3 Pods ↓ aumento de carga 6 Pods ↓ redução de carga 3 Pods

CPU é um exemplo comum, mas também podem existir métricas customizadas e externas.

Escalar Pods não significa escalar nodes

HPA pode solicitar mais Pods.

Mas, se não houver capacidade nos nodes, alguns podem permanecer pendentes.

Por isso existem mecanismos separados de escalabilidade de infraestrutura, como:

• Cluster Autoscaler;

• Karpenter em determinados ambientes;

• recursos gerenciados dos provedores cloud.

Pod autoscaling e node autoscaling são camadas diferentes.

Volumes continuam importantes

Pods não devem ser tratados como armazenamento permanente de dados.

Kubernetes possui abstrações próprias para storage persistente.

Os conceitos principais são:

PersistentVolume (PV)

e

PersistentVolumeClaim (PVC)

Uma aplicação solicita storage por meio de um PVC.

A infraestrutura fornece o volume correspondente.

StorageClasses podem permitir provisionamento dinâmico.

StatefulSet atende workloads com identidade persistente

Deployments funcionam muito bem para workloads stateless.

Mas alguns serviços precisam de:

• identidade estável;

• nomes previsíveis;

• volumes persistentes específicos;

• ordem controlada de criação.

Para esses casos existe o StatefulSet.

Namespaces ajudam a organizar o cluster

Namespaces criam divisões lógicas dentro de um cluster.

Podem separar:

• equipes;

• ambientes;

• aplicações.

Exemplo:

development staging production

Eles também podem ser combinados com RBAC, quotas e políticas de rede.

Kubernetes trabalha com estado desejado

Um dos conceitos centrais da plataforma é o desired state.

Você declara:

quero três réplicas da aplicação usando a imagem 2.4.0.

Se o estado atual for:

Desejado: 3 Atual: 2

o Kubernetes tenta criar outra réplica.

Esse processo de comparar estado atual com estado desejado e agir para reduzir a diferença é chamado de reconciliation.

Esse conceito será essencial quando chegarmos a GitOps.

Manifestos transformam configuração em código

Objetos Kubernetes normalmente são descritos em YAML.

apiVersion: apps/v1 kind: Deployment metadata: name: portal spec: replicas: 3

Esses manifestos podem ser versionados no Git.

Isso permite:

• histórico de alterações;

• revisão por Pull Request;

• auditoria;

• automação;

• integração com CI/CD;

• integração com GitOps.

Kubernetes e CI/CD são complementares

CI/CD e Kubernetes não são a mesma coisa.

Uma pipeline pode:

validar código → executar testes → construir imagem → verificar segurança → enviar imagem ao registry

Depois:

atualizar manifestos → aplicar mudança no Kubernetes

Kubernetes assume a execução e manutenção do workload.

Esse fluxo se conecta diretamente ao artigo sobre CI/CD e pipelines modernas e ao artigo sobre Docker e containers.

Observabilidade continua necessária

Kubernetes automatiza execução, mas não elimina a necessidade de monitoramento.

É importante acompanhar:

• nodes;

• Pods;

• containers;

• CPU;

• memória;

• rede;

• eventos;

• logs;

• latência;

• disponibilidade;

• erros.

Prometheus e Grafana são ferramentas muito comuns nesse ecossistema.

Kubernetes não elimina a infraestrutura

Por baixo do cluster continua existindo infraestrutura real:

• computação;

• rede;

• storage;

• DNS;

• identidade;

• segurança;

• backup;

• observabilidade.

Em cloud, isso pode envolver serviços como Amazon EKS, Azure Kubernetes Service e Google Kubernetes Engine.

Kubernetes não é obrigatório para todo projeto

Nem toda aplicação precisa de Kubernetes.

Ele faz mais sentido quando existem necessidades como:

• múltiplos workloads;

• alta disponibilidade;

• escalabilidade;

• automação de deployment;

• padronização operacional;

• governança;

• clusters distribuídos.

Complexidade também possui custo.

O objetivo deve ser adotar Kubernetes quando os problemas que ele resolve realmente existem.

O ciclo completo

Podemos conectar os principais elementos:

Código → Dockerfile → Build → Imagem → Registry → Deployment → Scheduler → Node → Pod → Container Runtime → Container → Service

Enquanto isso, o Control Plane observa continuamente o estado do cluster e tenta manter a configuração declarada.

Conclusão

Kubernetes adiciona uma camada de orquestração sobre aplicações containerizadas.

Os principais conceitos se conectam:

Control Plane coordena o cluster.

Nodes executam workloads.

Pods agrupam containers.

Deployments mantêm réplicas e atualizações.

Services fornecem acesso estável.

Ingress organiza entrada HTTP e HTTPS.

ConfigMaps e Secrets fornecem configuração.

Volumes preservam dados.

Probes ajudam a verificar saúde.

Autoscaling adapta capacidade.

Reconciliation mantém o estado atual próximo do estado desejado.

Com essa base, o próximo assunto fica muito mais fácil de entender:

GitOps: infraestrutura e aplicações controladas a partir do Git.