Curso Kubernetes 01 — Kubernetes sem medo: o condomínio dos containers

“Na minha máquina funciona.”

Quem trabalha com software já ouviu essa frase. Containers resolveram parte do problema: a aplicação leva consigo bibliotecas, runtime e configuração. Mas container sozinho não responde perguntas como:

• Quem garante que a aplicação continua no ar se o processo morrer?
• Como distribuir 20 containers entre 6 servidores sem fazer planilha?
• Como atualizar uma versão sem derrubar tudo?
• Como dar um nome estável para um serviço cujos IPs mudam o tempo todo?

Kubernetes é a resposta para essas perguntas. Ele é um orquestrador: você declara o estado desejado e ele tenta manter a realidade alinhada a esse estado.

Selo do curso: conceitos válidos para Kubernetes 1.35. Os comandos do laboratório são testados em Ubuntu 24.04.

Container não é VM

Uma VM virtualiza o hardware: cada VM tem seu próprio kernel, seus drivers, seu boot. Um container compartilha o kernel do host e isola processos com namespaces e cgroups.

	VM	Container
Peso	GBs	MBs
Boot	segundos/minutos	milissegundos
Kernel	próprio	compartilha o do host
Isolamento	forte (hardware virtual)	bom (processo)
Densidade	dezenas por host	centenas por host

Isso explica por que containers são rápidos e por que uma imagem pequena importa. Também explica por que “container não é segurança absoluta”: o isolamento é do processo, não de hardware.

O que Kubernetes realmente faz

Kubernetes não “roda containers” no sentido de executar o binário. Quem executa é o container runtime (containerd, CRI-O, Docker via shim). Kubernetes decide onde, quantos e como eles rodam.

O modelo é declarativo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: portal
spec:
  replicas: 3
  selector:
    matchLabels:
      app: portal
  template:
    metadata:
      labels:
        app: portal
    spec:
      containers:
        - name: portal
          image: nginx:1.27
          ports:
            - containerPort: 80

Você diz “quero 3 réplicas”. O Kubernetes compara com a realidade. Se há 2, ele cria 1. Se há 4, ele remove 1. Esse ciclo se chama reconciliação.

O condomínio

Pense no cluster como um condomínio:

• API Server é a portaria: todo pedido passa por ele.
• etcd é o livro de registro: guarda o estado do condomínio.
• Scheduler é o síndico: decide em qual apartamento (nó) cada morador (pod) vai ficar.
• Controller Manager é a administração: cobra o que está fora do regulamento.
• kubelet é o zelador de cada torre: garante que os moradores do seu nó estejam lá.
• container runtime é a empresa que efetivamente entrega a mudança.
• CNI é o sistema de encanamento entre apartamentos.
• kube-proxy é a central de encaminhamento de visitas.

Cada peça tem um papel simples. A complexidade aparece quando muitas peças precisam concordar.

Control plane e workers

Componente	Onde roda	Função
kube-apiserver	control plane	ponto único de entrada e validação
etcd	control plane	banco chave-valor do estado
kube-scheduler	control plane	escolhe o nó do pod
kube-controller-manager	control plane	reconcilia controladores
kubelet	worker	executa e monitora pods do nó
container runtime	worker	baixa imagem e roda container
kube-proxy	worker	regras de rede para Services
CNI	worker	rede dos pods

Em um cluster de laboratório, control plane e workers podem estar na mesma máquina. Em produção, você separa. Neste curso, vamos separar desde o começo — inclusive para entender o que quebra quando um nó cai.

Pod: a menor unidade

Um pod é um ou mais containers que compartilham rede e volumes. Na prática, 90% dos pods têm um container. O pod é efêmero: ele nasce, morre e é recriado com outro IP.

Por isso você quase nunca cria pods diretamente. Você cria Deployments, que criam ReplicaSets, que criam pods. O Deployment garante o número de réplicas e o histórico de rollout.

Deployment -> ReplicaSet -> Pod(s)

O que Kubernetes não resolve

• Não escreve sua aplicação.
• Não substitui observabilidade: sem métricas e logs, você fica cego.
• Não substitui backup: persistência sem restore testado é fé.
• Não impede erro humano: YAML errado continua sendo YAML errado.
• Não é mágica de alta disponibilidade: se o banco é single-node, o cluster não o salva.

Laboratório do capítulo

Neste capítulo ainda não vamos montar o cluster. Vamos apenas preparar o cliente e entender o terreno.

1. Instale o kubectl

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
kubectl version --client

2. Instale o kind (opcional, para um cluster descartável)

curl -Lo ./kind https://kind.sigs.k8s.io/dl/latest/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind
kind create cluster --name curso
kubectl get nodes

Se você não quiser o kind agora, tudo bem: no capítulo 02 montamos o cluster real com kubeadm.

3. Explore a API

kubectl api-resources | head -30
kubectl explain pod.spec.containers | head -30

kubectl explain é a documentação que vive no cluster. Use e abuse.

4. Crie e observe um pod

kubectl run ola --image=nginx:1.27 --port=80
kubectl get pods -o wide
kubectl describe pod ola | tail -20
kubectl logs ola
kubectl delete pod ola

Repare: o pod ganhou um IP, foi agendado em um nó e, ao ser deletado, sumiu. Se você tivesse criado um Deployment, ele voltaria.

Erros comuns neste estágio

Sintoma	Causa provável
The connection to the server was refused	kubeconfig errado ou cluster desligado
error: You must be logged in	contexto/kubeconfig ausente
ImagePullBackOff	imagem inexistente, registry privado ou sem credencial
CrashLoopBackOff	container inicia e morre; veja kubectl logs --previous
Pod Pending	sem recursos, nodeSelector/taint ou PVC não vinculado
YAML “não aplica”	indentação, campo desconhecido ou kubectl apply no arquivo errado

Checklist

• [ ] Sei a diferença entre VM e container.
• [ ] Entendi estado desejado e reconciliação.
• [ ] Sei o papel de API server, etcd, scheduler, controller, kubelet, CNI e kube-proxy.
• [ ] Entendi que pod é efêmero e Deployment é o nível certo.
• [ ] Instalei kubectl e rodei kubectl version --client.
• [ ] Criei e removi um pod.

Glossário

• Cluster: conjunto de nós gerenciados por um control plane.
• Nó: máquina (física ou VM) que roda pods.
• Pod: menor unidade de execução.
• Deployment: controlador que garante réplicas e rollout.
• ReplicaSet: garante um número de pods de uma versão.
• CNI: plugin de rede dos pods.
• etcd: banco de estado do cluster.
• kubeconfig: arquivo de acesso ao cluster.

Próximo

No capítulo 02 vamos sair da teoria e montar o laboratório: 6 VMs, rede, containerd e o primeiro kubeadm init.

Próximo: Curso Kubernetes 02 — Montando o laboratório: 6 VMs e um cluster que cabe no bolso