O que é Kubernetes: guia completo de arquitetura e operação

Autor: Pedro Tebaldi PM do KeepGreen| Revisão técnica: Ednilson Correa SRE

Publicado mai/2019Atualizado set/2026

Se você acompanha o dia a dia da infraestrutura moderna, já percebeu que Kubernetes deixou de ser moda para virar infraestrutura de base. Empresas que rodam cargas críticas em nuvem, de fintechs a varejistas, acabam cedo ou tarde diante da mesma decisão: adotar Kubernetes, entender como ele funciona e, sobretudo, como mantê-lo vivo em produção sem sofrer.

O problema é que a maioria das explicações para de contar a história na metade. Definem Kubernetes como “orquestrador de containers” e jogam o leitor direto no manual de kubectl. Este guia segue outro caminho. Vamos explicar o que é Kubernetes, como sua arquitetura funciona por dentro, quais são os objetos que você vai encontrar todos os dias e, principalmente, os desafios reais de operar um cluster em produção que quase ninguém conta antes do primeiro incidente.

No final, você vai entender não apenas o conceito, mas também quando adotar, quando evitar e como garantir visibilidade completa de um ambiente Kubernetes.

O que é Kubernetes?

Kubernetes é uma plataforma open source para automação de implantação, escalonamento e operação de aplicações em containers. O nome vem do grego kubernḗtēs, que significa “timoneiro” ou “piloto”. A abreviação K8s surgiu porque existem exatamente oito letras entre o K e o s.

O projeto nasceu dentro do Google, inspirado no sistema interno chamado Borg, usado há mais de uma década para gerenciar a infraestrutura de bilhões de containers por semana. Em 2014, o Google liberou o código como projeto open source e, em 2015, transferiu a governança para a Cloud Native Computing Foundation. Desde então, virou o padrão de fato para orquestração de containers em nuvem pública, privada e ambientes híbridos.

Na prática, Kubernetes responde a uma pergunta simples: quando você tem dezenas ou milhares de containers rodando em vários servidores, quem garante que eles estão saudáveis, quem reinicia o que falha, quem escala quando há pico de tráfego e quem roteia o tráfego entre réplicas? A resposta é o Kubernetes.

Por que o Kubernetes surgiu

O Kubernetes surgiu porque os containers resolveram o empacotamento e criaram um problema novo: a escala. Um container carrega a aplicação com suas dependências e compartilha o kernel do host, então sobe em segundos. Docker popularizou esse formato e deixou a conta da orquestração em aberto.

Rodar cinco containers numa máquina é trivial. Rodar cinco mil, distribuídos entre dezenas de nós, com balanceamento de carga, reinício automático, rolling updates e tolerância a falhas, é outro planeta. É exatamente esse vácuo que o Kubernetes preenche. Para entender a camada logo abaixo dele, vale se aprofundar em Docker e o ecossistema de containers.

Como funciona a arquitetura do Kubernetes

A arquitetura do Kubernetes é dividida em duas grandes camadas: o control plane (plano de controle) e os worker nodes (nós de trabalho). Juntos, eles formam o que se chama de cluster.

Control plane: o cérebro do cluster

O control plane toma todas as decisões globais do cluster. Ele é composto por alguns componentes principais. O API server é a porta de entrada para qualquer operação. Tudo passa por ele: kubectl apply, webhooks, controllers, integrações externas. O etcd é o banco de dados chave-valor distribuído que armazena o estado completo do cluster. Se o etcd cair, o cluster perde a memória. O scheduler decide em qual nó cada novo pod vai rodar, levando em conta recursos disponíveis, afinidade e restrições. O controller manager roda loops de reconciliação que comparam o estado desejado com o estado real e agem para igualá-los.

Worker nodes: onde a aplicação roda

Cada worker node é uma máquina física ou virtual que executa containers de fato. Três componentes principais rodam em cada nó. O kubelet é o agente que recebe ordens do control plane e garante que os containers declarados estejam vivos. O kube-proxy gerencia a rede interna do cluster, permitindo que pods conversem entre si e que serviços sejam expostos. O container runtime (containerd, CRI-O, entre outros) é quem executa de fato os containers, seguindo o padrão definido pela Open Container Initiative.

O modelo é declarativo. Você descreve o estado desejado em arquivos YAML (por exemplo, “quero três réplicas desta aplicação, com 512MB de RAM cada, expostas na porta 80”) e o Kubernetes cuida de materializar esse estado e mantê-lo. Se um nó cair, ele reescalona os pods. Se uma réplica morrer, ele cria outra. Essa lógica de estado desejado é parte do que torna Kubernetes robusto e, ao mesmo tempo, complexo de operar.

A arquitetura, vista de dentro de um cluster

Para este guia, subimos um cluster com kind 0.33.0 e Kubernetes 1.37.0, em 1º de setembro de 2026. São um control plane e dois workers. Os componentes descritos acima não vivem apenas no diagrama: eles rodam como pods comuns, que o próprio cluster lista.

# o cluster do laboratório: 1 control plane e 2 workers
$ kubectl get nodes
NAME                   STATUS   ROLES           AGE   VERSION
op-lab-control-plane   Ready    control-plane   10m   v1.37.0
op-lab-worker          Ready    <none>          10m   v1.37.0
op-lab-worker2         Ready    <none>          10m   v1.37.0

# os componentes do control plane são pods como qualquer outro
$ kubectl get pods -n kube-system
NAME                                           READY   STATUS    RESTARTS   AGE
coredns-559f6c778d-c8cww                       1/1     Running   0          10m
coredns-559f6c778d-qzg8j                       1/1     Running   0          10m
etcd-op-lab-control-plane                      1/1     Running   0          10m
kindnet-2h877                                  1/1     Running   0          10m
kindnet-558x8                                  1/1     Running   0          10m
kindnet-srbtb                                  1/1     Running   0          10m
kube-apiserver-op-lab-control-plane            1/1     Running   0          10m
kube-controller-manager-op-lab-control-plane   1/1     Running   0          10m
kube-proxy-7lvxs                               1/1     Running   0          10m
kube-proxy-bmrnp                               1/1     Running   0          10m
kube-proxy-sz6vz                               1/1     Running   0          10m
kube-scheduler-op-lab-control-plane            1/1     Running   0          10m

Repare no sufixo dos nomes. O etcd, o kube-apiserver, o kube-scheduler e o kube-controller-manager carregam o nome do nó de control plane, porque rodam somente nele. Em contrapartida, o kube-proxy aparece uma vez por nó.

Os objetos principais do Kubernetes

Kubernetes expõe dezenas de tipos de recursos, mas cinco ou seis deles concentram 90% do uso diário. Entender esse núcleo é meio caminho andado.

O Pod é a menor unidade implantável. Um pod agrupa um ou mais containers que compartilham rede e armazenamento. Na prática, a maioria dos pods roda um único container, mas é possível ter “sidecars”, containers auxiliares que fazem logging, proxy ou autenticação.

O Deployment descreve o estado desejado de um conjunto de pods idênticos. Ele é quem habilita rolling updates, rollbacks e controle de réplicas. Você raramente cria um Pod sozinho; o normal é criar um Deployment e deixar o Kubernetes gerenciar os pods.

O Service expõe um conjunto de pods por trás de um endereço IP estável e um nome DNS. Como pods sobem e descem o tempo todo, o Service garante que clientes saibam sempre onde encontrar a aplicação. Existem tipos diferentes: ClusterIP, NodePort, LoadBalancer e Ingress.

O ConfigMap e o Secret armazenam configurações e credenciais separadas do código da aplicação. O Namespace isola recursos dentro do cluster, permitindo que equipes ou ambientes convivam sem se pisar.

Esses objetos cabem num arquivo só. O manifesto abaixo declara um Deployment de três réplicas, com limite de memória e sonda de prontidão. Em seguida, declara o Service que expõe essas réplicas por um nome DNS estável.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: catalogo
  namespace: loja
spec:
  replicas: 3
  selector:
    matchLabels:
      app: catalogo
  template:
    metadata:
      labels:
        app: catalogo
    spec:
      containers:
        - name: web
          image: nginx:1.29-alpine
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 50m
              memory: 32Mi
            limits:
              memory: 64Mi
          readinessProbe:
            httpGet:
              path: /
              port: 80
            periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: catalogo
  namespace: loja
spec:
  selector:
    app: catalogo
  ports:
    - port: 80
      targetPort: 80

Um comando aplica o arquivo. O cluster responde com o que criou:

$ kubectl apply -f catalogo.yaml
deployment.apps/catalogo created
service/catalogo created

$ kubectl -n loja get deploy,pod,svc
NAME                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/catalogo   3/3     3            3           9m44s

NAME                           READY   STATUS    RESTARTS   AGE
pod/catalogo-dd46dccdf-fdbns   1/1     Running   0          8m44s
pod/catalogo-dd46dccdf-qw577   1/1     Running   0          8m48s
pod/catalogo-dd46dccdf-vj9xt   1/1     Running   0          8m38s

NAME               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/catalogo   ClusterIP   10.96.212.207   <none>        80/TCP    9m44s

O Deployment subiu com três réplicas prontas. Os pods herdaram o nome do ReplicaSet mais um sufixo aleatório, porque são descartáveis por definição. Por outro lado, o Service ganhou um IP fixo, o 10.96.212.207, que sobrevive à troca dos pods.

Quem já trabalha com infraestrutura como código percebe que o Kubernetes leva o paradigma ao próximo nível: tudo vira YAML versionado, revisável em pull request e auditável como qualquer outro artefato de software.

Benefícios reais do Kubernetes em produção

Os benefícios listados nas homepages dos provedores costumam soar genéricos. Na prática, há quatro ganhos concretos que justificam a complexidade de adotar Kubernetes.

O primeiro é auto-recuperação. Pods que falham em health checks são reiniciados automaticamente. Nós que ficam indisponíveis têm suas cargas reagendadas em outros nós. O cluster converge sozinho para o estado desejado, o que reduz drasticamente o tempo em que humanos precisam intervir em incidentes banais.

Drasticamente é um advérbio, não um número. Por isso, medimos: apagamos um pod à mão três vezes seguidas e cronometramos até o Deployment voltar às três réplicas prontas.

$ kubectl -n loja delete pod catalogo-dd46dccdf-qw577
pod "catalogo-dd46dccdf-qw577" deleted from loja namespace

$ kubectl -n loja get pods
NAME                       READY   STATUS              RESTARTS   AGE
catalogo-dd46dccdf-6spjx   0/1     ContainerCreating   0          0s
catalogo-dd46dccdf-fdbns   1/1     Running             0          8m56s
catalogo-dd46dccdf-qw577   1/1     Terminating         0          9m
catalogo-dd46dccdf-vj9xt   1/1     Running             0          8m50s

# quatro segundos depois
$ kubectl -n loja get pods
NAME                       READY   STATUS    RESTARTS   AGE
catalogo-dd46dccdf-6spjx   1/1     Running   0          5s
catalogo-dd46dccdf-fdbns   1/1     Running   0          9m1s
catalogo-dd46dccdf-vj9xt   1/1     Running   0          8m55s

Nas três rodadas, o substituto nasceu entre 164 e 383 milissegundos depois do comando. Ele passou a receber tráfego entre 0,96 e 1,68 segundo. Durante toda a janela, o Service manteve dois dos três endereços prontos, portanto nenhuma requisição caiu.

Esse número é otimista de propósito. A imagem já estava em cache no nó. Um nginx sobe em menos de um segundo. Em produção, some a isso o tempo de baixar a imagem e o aquecimento da sua aplicação.

O segundo é escalabilidade horizontal automática. O Horizontal Pod Autoscaler ajusta o número de réplicas com base em métricas de CPU, memória ou métricas customizadas. Para aplicações com picos sazonais, como e-commerce em datas de alta demanda, o impacto em capex e opex é mensurável. Garantir a disponibilidade durante esses picos depende de uma boa estratégia de alta disponibilidade. Kubernetes é uma peça central dessa estratégia.

O terceiro é deploy seguro. Rolling updates permitem subir uma nova versão gradualmente, monitorando saúde da aplicação. Se algo dá errado, o rollback é um comando só. Isso reduz o medo de deployar e habilita práticas de entrega contínua de verdade.

O quarto é portabilidade. Um mesmo workload descrito em YAML roda em qualquer distribuição de Kubernetes conforme, seja ela on-premises, AWS EKS, Google GKE ou Azure AKS. Essa abstração é uma das principais razões pelas quais Kubernetes virou o denominador comum do ecossistema de cloud computing moderno.

Desafios e armadilhas que ninguém conta sobre Kubernetes

Esta é a seção que quase nenhum artigo introdutório escreve. É também a mais importante. Kubernetes entrega muito, mas cobra caro em complexidade operacional.

O primeiro desafio é a curva de aprendizado. O universo de conceitos é vasto: pods, deployments, services, ingress, network policies, RBAC, admission controllers, operators, CRDs. Equipes que adotam Kubernetes sem investir em capacitação tendem a repetir erros previsíveis e a acumular dívida técnica silenciosa.

O segundo é o custo financeiro. Clusters gerenciados têm custo por hora do control plane, custo dos nós worker e custo de rede. Sem boas práticas de bin packing, limites de recursos e autoscaling bem configurado, as contas em nuvem escalam mais rápido que o tráfego. Gestão de recursos é tão relevante quanto arquitetura.

O terceiro é a observabilidade. Quanto mais dinâmico o ambiente, mais difícil responder perguntas simples como “por que esse pod morreu?” ou “qual foi o caminho desse request?”. Monitorar Kubernetes exige correlacionar métricas de cluster, métricas de aplicação, logs estruturados e traces distribuídos, o que torna a disciplina de observabilidade essencial desde o dia zero, não uma preocupação para depois. Estratégias maduras de monitoramento de Kubernetes combinam visibilidade de control plane, nodes e aplicações num único plano correlacionado. Sem isso, o cluster vira uma caixa preta onde incidentes se prolongam e causa raiz fica escondida.

O quarto é segurança. Por padrão, o Kubernetes é permissivo. RBAC, network policies, pod security standards e gestão de secrets precisam ser configurados ativamente. Um cluster mal configurado é um vetor de ataque enorme, especialmente se expõe APIs ou dashboards na internet.

O quinto é a complexidade de troubleshooting. Quando algo dá errado, o caminho para a causa raiz passa por várias camadas: aplicação, container, pod, node, rede e control plane. Sem ferramental adequado, um incidente que em uma VM monolítica demoraria 15 minutos pode consumir horas em Kubernetes. É aqui que soluções de monitoramento de servidores e visibilidade de clusters fazem a diferença prática no MTTR.

Os três incidentes que aparecem primeiro

No mesmo cluster, provocamos de propósito três falhas clássicas. Um pod não chega a ser agendado, outro estoura o limite de memória e o terceiro sobe sem entrar no Service. Cada uma se manifesta de um jeito diferente na lista de pods. Portanto, é a diferença entre elas que diz onde olhar.

Em seguida, o bloco traz as três falhas lado a lado, com o detalhe das duas primeiras:

$ kubectl -n falhas get pods
NAME                           READY   STATUS             RESTARTS       AGE
estoura-memoria                0/1     CrashLoopBackOff   5 (105s ago)   5m18s
pedido-grande                  0/1     Pending            0              8m36s
sonda-errada-b54479795-g8vpp   0/1     Running            0              8m36s
sonda-errada-b54479795-rrj8c   0/1     Running            0              8m36s

# 1) o pod que não sai do Pending: o scheduler explica no evento
$ kubectl -n falhas describe pod pedido-grande | tail -4
Events:
  Type     Reason            Age                  From               Message
  ----     ------            ----                 ----               -------
  Warning  FailedScheduling  12s (x5 over 8m36s)  default-scheduler  0/3 nodes are available: 1 node(s) had untolerated taint(s), 2 Insufficient cpu. preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling.

# 2) o pod que reinicia sem parar: a causa está no estado anterior
$ kubectl -n falhas describe pod estoura-memoria | grep -A5 "Last State"
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Tue, 01 Sep 2026 19:43:37 -0300
      Finished:     Tue, 01 Sep 2026 19:43:43 -0300
    Ready:          False

O terceiro caso é o mais traiçoeiro. Os dois pods do sonda-errada aparecem como Running, sem reinício e sem erro no log. A sonda de prontidão aponta para a porta 8080, o nginx escuta na 80, então eles nunca ficam prontos.

Ainda assim, o Service continua existindo, com IP e nome DNS. De dentro do cluster, ele recusa conexão:

# de dentro do cluster, num pod temporário com curl
$ curl -s -o /dev/null -w "HTTP %{http_code} em %{time_total}s\n" http://catalogo.loja.svc.cluster.local/
HTTP 200 em 0.003333s

# o Service da sonda errada recusa conexão, com os dois pods em Running
$ curl -sS -m 5 http://sonda-errada.falhas.svc.cluster.local/
curl: (7) Failed to connect to sonda-errada.falhas.svc.cluster.local port 80 after 2 ms: Could not connect to server

# a coluna ENDPOINTS lista os dois endereços como se tudo estivesse no lugar
$ kubectl -n falhas get endpointslice -l kubernetes.io/service-name=sonda-errada
NAME                 ADDRESSTYPE   PORTS   ENDPOINTS               AGE
sonda-errada-xkx68   IPv4          80      10.244.2.6,10.244.1.6   10m

# quem decide é a condição ready, que a coluna não mostra
$ kubectl -n falhas get endpointslice -l kubernetes.io/service-name=sonda-errada -o jsonpath='{range .items[*].endpoints[*]}{.addresses[0]}{" ready="}{.conditions.ready}{"\n"}{end}'
10.244.2.6 ready=false
10.244.1.6 ready=false

Aqui mora a armadilha de diagnóstico. O kubectl get endpoints, que nesse caso mostrava a coluna vazia, está deprecado desde a versão 1.33 e emite aviso. No entanto, o substituto lista os dois endereços, mesmo com os pods reprovando a sonda.

Na 1.37, quem confere apenas a coluna conclui que o Service está servindo. A condição ready é o que separa um endereço listado de um endereço em uso, como descreve a documentação do EndpointSlice.

Quando adotar e quando evitar Kubernetes

Kubernetes não é solução universal. Vale adotar quando sua aplicação é composta por múltiplos serviços, quando há necessidade real de escalonamento dinâmico, quando a equipe já tem maturidade com containers e quando o custo de complexidade operacional é menor que o ganho de agilidade. Em ambientes multi-cloud ou híbridos, o benefício é ainda maior, porque Kubernetes abstrai diferenças entre provedores.

Pense duas vezes antes de adotar se sua aplicação é um monólito estável, se o tráfego é previsível, se a equipe tem poucos engenheiros ou se o ciclo de entrega é mensal. Nesses casos, uma solução mais simples (como instâncias gerenciadas ou PaaS) costuma entregar mais valor por menos esforço. A decisão precisa ser pragmática, não movida por modismo.

Quem vai adotar deve planejar três frentes em paralelo: capacitação da equipe, padrão de entrega (CI/CD, GitOps) e, sobretudo, estratégia de monitoramento. Tratar essas três frentes como dependentes entre si (não como etapas sequenciais) é o que separa uma adoção bem-sucedida de um incidente que vira caso clássico. Uma boa base de monitoramento de TI aplicada a clusters Kubernetes reduz drasticamente o tempo de detecção e resolução de problemas.

Conclusão

Responder à pergunta “o que é Kubernetes” exige ir além da definição técnica. Kubernetes é uma plataforma de orquestração de containers com arquitetura elegante, modelo declarativo e um ecossistema vasto de ferramentas. Mas é também uma plataforma exigente, que cobra maturidade operacional, investimento em observabilidade e disciplina de segurança.

A boa notícia é que, bem implementado, Kubernetes entrega agilidade, resiliência e escala difíceis de replicar com outras abordagens. A má notícia é que a complexidade não desaparece sozinha; ela precisa ser administrada com processos, ferramentas e visibilidade em tempo real. Se sua equipe está iniciando a jornada ou já opera clusters em produção e quer reduzir o tempo em que incidentes permanecem obscuros, fale com os especialistas da OpServices em nossa página de contato e descubra como garantir observabilidade completa de seus workloads containerizados.