Entenda como o Control Plane, o quórum RAFT do etcd, o kubelet e o loop declarativo transformam máquinas isoladas em um sistema operacional de nuvem — e suba seu cluster local multi-nó com kind e kubectl.
Se o player não carregar por restrição de sessão no navegador, clique em Abrir no Google Drive ↗.
OFICINA 01 · CAPÍTULO 1
O Que é Kubernetes & Por Que Ele Domina a Nuvem
Kubernetes (pronuncia-se "koo-ber-net-eez" e abrevia-se como K8s, ou "kates") é um orquestrador de aplicações nativas da nuvem baseadas em microsserviços e contêineres. Quando uma aplicação quebra em dezenas de contêineres espalhados por vários servidores, alguém precisa decidir onde cada peça roda, vigiar falhas e redistribuir carga sem intervenção manual.
Deploy e escala automática: sobe novas réplicas quando o tráfego cresce e reduz quando a demanda cai.
Autocorreção (self-healing): se um contêiner trava ou um servidor cai, outro é recriado automaticamente para manter o número desejado.
Rollouts e rollbacks: atualiza versões sem derrubar o serviço e reverte em segundos se algo falhar.
Sistema Operacional da Nuvem: abstrai AWS, Azure, GCP, Civo, Linode ou servidores locais (on-premises), viabilizando nuvem híbrida, multi-nuvem e migrações sem reescrever a aplicação.
Origem e governança: o Kubernetes nasceu no Google inspirado nos sistemas internos Borg e Omega (os 7 raios do leme no logotipo homenageiam sutilmente a personagem Seven of Nine dos Borg). Em 2014, foi aberto sob licença Apache 2.0 e doado à Cloud Native Computing Foundation (CNCF). A versão 1.0 saiu em julho de 2015 e a v1.32 em fevereiro de 2025, mantendo cerca de 3 lançamentos por ano.
Prática Rápida 01
Liste 2 aplicações que você já conhece (ou mantém em Docker) e anote qual dor de operação o orquestrador resolveria primeiro: escala em pico, queda de máquina ou atualização sem downtime.
OFICINA 02 · CAPÍTULO 1
Kubernetes, Docker, CRI & Runtimes Plugáveis
Um erro comum de iniciantes é achar que "Kubernetes substituiu o Docker". Na prática, eles atuam em camadas complementares: você usa ferramentas compatíveis com OCI (Open Container Initiative) para empacotar imagens, e o Kubernetes orquestra essas imagens em escala.
O segredo dessa flexibilidade é a CRI (Container Runtime Interface), uma camada plugável que desacopla o Kubernetes do motor que efetivamente baixa e executa contêineres.
Evolução e convivência de runtimes no mesmo cluster
Componente / Runtime
Papel no Ecossistema
Observação Importante (v1.32)
dockershim (removido)
Ponte antiga que adaptava o Docker Engine ao kubelet
Removido no Kubernetes 1.24; imagens construídas com docker build continuam 100% compatíveis por seguirem o padrão OCI.
containerd
Runtime padrão na maioria dos clusters modernos
Leve, estável e focado apenas em gerenciar o ciclo de vida de contêineres OCI.
gVisor / Kata
Runtimes de isolamento reforçado (sandboxing / micro-VMs)
Podem coexistir no mesmo cluster ao lado do containerd para workloads multi-tenant mais sensíveis.
Spin (Wasm)
Runtime WebAssembly no Kubernetes
Permite rodar módulos Wasm ultraleves no mesmo cluster (aprofundado na Etapa 4).
Por que a remoção do dockershim não quebrou seus Dockerfiles?
Porque o formato de imagem (camadas + manifesto) segue a especificação aberta OCI. Uma imagem gerada com docker build no seu notebook roda normalmente no containerd ou CRI-O dentro do cluster.
OFICINA 03 · CAPÍTULO 2
Control Plane: O Cérebro do Cluster
Um cluster Kubernetes é dividido em dois tipos de máquinas: nós do Control Plane (exclusivamente Linux; 1 nó em laboratórios, 3 ou 5 nós distribuídos em zonas de disponibilidade distintas em produção) e Worker Nodes. Em produção, nunca execute aplicações de usuário no Control Plane.
Os 5 serviços essenciais do Control Plane
Serviço
Função Principal
Detalhe Crítico de Operação
API Server
Porta de entrada RESTful via HTTPS para tudo no cluster
Recebe manifestos YAML, autentica, autoriza e grava no armazenamento do cluster. Nada conversa direto com o etcd sem passar por ele.
Cluster Store (etcd)
Única parte stateful do Control Plane; guarda o estado desejado
Usa consenso RAFT e exige número ímpar de réplicas (3 ou 5) para manter quórum e evitar split-brain.
Controller Manager
Executa loops contínuos de controle (Deployment, ReplicaSet, StatefulSet)
Vigia o API Server e age sempre que o estado observado diverge do estado desejado.
Scheduler
Aloca novos Pods nos Worker Nodes adequados
Filtra nós (taints, afinidade/antiafinidade, portas livres, CPU/RAM), ranqueia candidatos e atribui o nó (ou aciona o Cluster Autoscaler).
Cloud Controller Manager
Integra o cluster às APIs da nuvem (AWS, Azure, GCP, Linode)
Provisiona Load Balancers, volumes em bloco e registra nós da nuvem subjacente.
O que acontece em caso de split-brain no etcd? Se o quórum RAFT for perdido (por exemplo, apenas 1 de 3 nós do etcd sobrevive), o etcd entra em modo somente leitura. As aplicações já em execução nos Worker Nodes continuam atendendo usuários normalmente, mas você perde a capacidade de escalar, atualizar ou recriar Pods até restaurar o quórum — e backups periódicos do etcd continuam obrigatórios.
OFICINA 04 · CAPÍTULO 2
Worker Nodes, Empacotamento & O Loop Declarativo
Os Worker Nodes executam suas aplicações de fato e podem rodar Linux ou Windows (inclusive misturados no mesmo cluster). Cada Worker Node executa três componentes principais:
kubelet: o agente principal do nó; registra a máquina no cluster, observa tarefas enviadas pelo API Server, instrui o runtime a subir contêineres e reporta o status de volta.
Container Runtime (containerd, CRI-O): baixa imagens OCI, cria namespaces/cgroups e inicia ou encerra contêineres.
kube-proxy: implementa as regras de rede do cluster no nó e balanceia tráfego para os Pods.
Do Contêiner ao Service: a escada de abstração
Você raramente implanta um contêiner nu no Kubernetes. A cadeia segue uma hierarquia clara:
Contêiner empacota o processo da aplicação.
Pod envolve um ou mais contêineres que compartilham rede e armazenamento (Pods são mortais/efêmeros: quando morrem, não ressuscitam — outro Pod nasce com um novo IP).
Deployment envolve Pods para garantir contagem de réplicas, autocorreção, escala e atualizações graduais.
Service coloca um nome DNS e um ClusterIP estáveis na frente dos Pods efêmeros, evitando que clientes quebrem quando IPs mudam.
Declarativo vs. Imperativo: em vez de escrever scripts imperativos passo a passo ("crie 3 contêineres, depois verifique..."), você entrega um YAML declarando o Estado Desejado. Os controllers comparam continuamente o Estado Observado com o desejado e executam a Reconciliação automaticamente.
OFICINA 05 · CAPÍTULO 3
Montando Seu Cluster Local (Docker Desktop & kind)
Para praticar sem gastar em nuvem desde o primeiro minuto, você precisa de apenas três itens: Docker, um cluster Kubernetes e a CLI kubectl. A partir do Docker Desktop v4.38+, é possível ativar um cluster multi-nó baseado em kind (Kubernetes in Docker) diretamente nas configurações.
kind multi-nó (recomendado para labs): exige login no Docker Desktop e permite ajustar o controle deslizante para 3 nós (desktop-control-plane, desktop-worker e desktop-worker2), cada um rodando como um contêiner Docker isolado.
kubeadm integrado: cria apenas um cluster de nó único.
Atenção aos limites locais: exemplos avançados com Load Balancer/Ingress em nuvem (Capítulo 8) e Storage em nuvem (Capítulo 11) exigem um cluster gerenciado como o Linode Kubernetes Engine (LKE). Lembre também da regra de licenciamento comercial do Docker Desktop (empresas com mais de 250 funcionários ou faturamento acima de US$ 10 milhões/ano).
Terminal · Clonar repositório oficial de exemplos do livro (branch 2025)
git clone https://github.com/nigelpoulton/TKB.git --branch 2025
cd TKB
ls -la
Não apareceu a opção Multi-Node no Docker Desktop 4.38+?
No capítulo 3 do livro, Nigel Poulton cita que em versões onde a opção ainda está oculta por padrão, o código Konami na tela de configurações de Kubernetes habilita a flag MultiNodeKubernetes.
OFICINA 06 · CAPÍTULO 3
Dominando o kubectl e o Arquivo kubeconfig
O kubectl é a ferramenta oficial de linha de comando para conversar com o API Server. Ele sabe qual cluster, usuário e certificado usar lendo o arquivo kubeconfig, armazenado por padrão em ~/.kube/config (macOS/Linux) ou C:\Users\<usuario>\.kube\config (Windows).
Todo kubeconfig organiza quatro seções principais: clusters (endereços dos API Servers), users (credenciais/tokens/certificados), contexts (pares cluster + usuário + namespace padrão) e current-context (o contexto ativo no momento).
Terminal · Verificar nós e inspecionar contextos do kubeconfig
Simule falhas no Control Plane e nos Worker Nodes para visualizar na prática como o quórum RAFT do etcd afeta o loop de reconciliação dos controllers.
Quórum RAFT Necessário
2 de 3 nós
Estado do Cluster Store
Saudável (Escrita Ativa)
Reconciliação de Pods
+2 Pods escalonados
Quórum mantido: o API Server grava normalmente no etcd e o Controller Manager + Scheduler criam os 2 Pods faltantes nos Worker Nodes.
VERIFICAÇÃO DE DOMÍNIO · 4 QUESTÕES
Teste Rápido da Etapa 1
Valide os conceitos essenciais dos Capítulos 1, 2 e 3 antes de avançar para Workloads.
1. Por que imagens criadas com docker build continuam funcionando mesmo após a remoção do dockershim no Kubernetes 1.24?
2. Em um cluster de produção com 3 nós no Control Plane, 2 nós do etcd ficam offline simultaneamente. O que acontece?
3. Por que o Kubernetes coloca um Service na frente de um conjunto de Pods?
4. Qual seção do arquivo kubeconfig une um cluster, um usuário e um namespace padrão para que o kubectl saiba onde atuar?
CONCLUSÃO DA ETAPA 1
Checklist de Prontidão & Exportação
Marque cada marco concluído; seu progresso fica salvo no navegador.
PRÓXIMA PARADA · ETAPA 2 DE 4
Cargas de Trabalho (Workloads) e Rede Básica
Mergulhe nos Capítulos 4, 5, 6 e 7: anatomia de Pods multi-contêiner, isolamento com Namespaces, Deployments com rolling updates e exposição via Services.
