 |
| Bellacosa Mainframe e o kubernetes no cobol uma viagem ao fundo do cluster |
☕ Um Café no Bellacosa Mainframe
Kubernetes, COBOL e a Viagem ao Fundo do Cluster: quando o programador entrou no Seaview procurando um JCL e encontrou Pods nadando entre Nodes
🌊 Containers, Pods, Deployments, Services, Scheduler, Control Plane, YAML, autoscaling, storage, observabilidade e a estranha descoberta de que administrar Kubernetes às vezes parece comandar um submarino nuclear onde metade da tripulação fala YAML
Imagine a cena.
O jovem programador COBOL entra no CPD numa segunda-feira, café na mão, perfeitamente confortável com aquele universo conhecido:
JOB
JCL
JES2
COBOL
CICS
Db2
VSAM
SDSF
Tudo possui nome.
Tudo possui finalidade.
Tudo possui, em algum lugar, um manual de 2.700 páginas que ninguém leu inteiro, mas algum sysprog aposentado sabe exatamente em qual capítulo está a informação necessária.
Então alguém da arquitetura aparece.
— Precisamos colocar a nova aplicação em Kubernetes.
O COBOLzeiro olha para ele.
— Em quê?
— Kubernetes.
— Isso é banco de dados?
— Não.
— Linguagem?
— Não.
— Sistema operacional?
— Não exatamente.
— Middleware?
— Também não.
— Scheduler?
— Mais ou menos.
— Docker?
— Não.
Silêncio.
O jovem COBOLzeiro bebe café.
— Então vocês inventaram uma coisa que não dá para explicar em uma palavra.
Bem-vindo ao século XXI.
E é nesse momento que nossa viagem começa.
Não a bordo da Enterprise.
Nem da TARDIS.
Hoje descemos centenas de metros abaixo da superfície, entrando num submarino tecnológico imaginário chamado:
USS KUBERNETES
Um enorme navio submersível cheio de containers, workloads, redes, volumes, APIs e operadores correndo pelos corredores gritando:
— CAPITÃO! PERDEMOS UM POD!
E o capitão responde:
— Quantas réplicas estavam declaradas?
— TRÊS!
— Quantas temos?
— DUAS!
— Então pare de gritar. O controller já está criando outra.
E o COBOLzeiro, olhando pela escotilha:
— Que tipo de feitiçaria é essa?
Pegue o café.
Vamos ao fundo do cluster.
🌊 Capítulo 1 — Kubernetes não é Docker
Antes de descermos aos níveis mais profundos precisamos matar um dos monstros marinhos mais resistentes da informática moderna:
“Kubernetes substituiu Docker.”
Não.
O problema começa porque vários conceitos acabaram historicamente misturados.
Docker popularizou containers.
Kubernetes popularizou a orquestração de containers.
E durante algum tempo existiu uma disputa mais direta entre:
Docker Swarm
versus
Kubernetes
Isso fazia sentido porque ambos tratavam de orquestração.
Mas Docker e Kubernetes não ocupam exatamente a mesma camada.
Pense desta forma:
Aplicação
|
v
Imagem
|
v
Container
|
v
Runtime
|
v
Pod
|
v
Kubernetes
|
v
Cluster
Docker ajudou a tornar simples construir, distribuir e executar containers.
Kubernetes pergunta outra coisa:
“Muito bem. Agora você possui 4.000 desses bichos. Quem administra?”
Essa pergunta muda tudo.
⚓ Capítulo 2 — O que diabos é um container?
O COBOLzeiro geralmente conhece um mundo bastante previsível.
Você compila:
PROGRAMA.CBL
|
v
compilador
|
v
load module
Depois executa num ambiente definido.
No mundo moderno surgiu um problema recorrente.
O programador dizia:
— Funciona na minha máquina.
Produção respondia:
— Pois aqui não funciona.
Então começava a investigação arqueológica:
versão diferente da biblioteca
variável de ambiente ausente
pacote não instalado
configuração divergente
runtime diferente
permissão diferente
O container tenta encapsular boa parte desse ambiente.
Imagine uma caixa contendo:
Aplicação
Bibliotecas
Dependências
Runtime
Configuração básica
Essa caixa pode ser reproduzida em diferentes ambientes.
Mas cuidado.
Container não é simplesmente uma VM pequena.
Uma máquina virtual tradicional possui algo parecido com:
HARDWARE
|
HYPERVISOR
|
+---- VM A
| |
| Guest OS
|
+---- VM B
|
Guest OS
Já containers normalmente compartilham o kernel do host:
HARDWARE
|
HOST OS
|
KERNEL
|
+---- Container A
+---- Container B
+---- Container C
O isolamento utiliza mecanismos do sistema operacional, especialmente recursos como:
namespaces
cgroups
filesystem isolation
network isolation
Portanto containers costumam ser muito mais leves que VMs completas.
Não existe um sistema operacional inteiro sendo inicializado dentro de cada container da mesma forma que numa VM tradicional.
🐋 Curiosidade do sonar — Docker não inventou isolamento
A ideia de isolamento de processos é muito anterior ao Docker.
Unix já possuía conceitos relacionados.
Depois vieram tecnologias como:
chroot
FreeBSD Jails
Solaris Zones
Linux namespaces
cgroups
LXC
Docker acertou magistralmente numa coisa:
experiência de uso.
Ele tornou relativamente simples construir uma imagem e executar:
docker run
Em tecnologia, muitas revoluções acontecem não quando algo é inventado, mas quando alguém torna aquilo utilizável por gente normal.
🌊 Capítulo 3 — Três containers não precisam de um almirante
Imagine que temos:
Container A
Container B
Container C
Você pode executá-los manualmente.
Talvez Docker Compose resolva perfeitamente.
Agora aumente:
30 containers
300 containers
3.000 containers
Distribuídos entre:
Node 01
Node 02
Node 03
...
Node 200
Então começam as perguntas.
Onde colocar cada aplicação?
Quem reinicia algo que morreu?
Quem percebe que uma máquina caiu?
Quem encontra capacidade disponível?
Quem faz atualização sem interromper o serviço?
Quem distribui tráfego?
Quem escala?
Quem controla configuração?
Quem mantém o estado desejado?
Essa é a missão do Kubernetes.
🧭 Capítulo 4 — O conceito mais importante: estado desejado
Aqui está o segredo que transforma Kubernetes de “montanha de YAML” em algo compreensível.
O modelo é declarativo.
Você diz:
QUERO 3 RÉPLICAS
Não precisa escrever um script detalhando:
crie processo 1
crie processo 2
crie processo 3
verifique processo 1
se morrer reinicie
verifique processo 2
...
Você declara:
replicas: 3
Agora imagine o sonar:
ESTADO DESEJADO
Pod A
Pod B
Pod C
Mas o Kubernetes observa:
ESTADO REAL
Pod A
Pod B
Alguma coisa está errada.
Desejado:
3
Atual:
2
Diferença:
1
O Kubernetes tenta corrigir.
cria novo Pod
Depois observa novamente.
Essa ideia recebe um nome fundamental:
reconciliation loop.
🔁 O coração mecânico do submarino
Imagine um oficial andando eternamente pelos corredores do USS Kubernetes perguntando:
O que deveria existir?
|
v
O que existe agora?
|
v
São iguais?
/ \
NÃO SIM
| |
corrigir continuar
|
observar novamente
Esse processo ocorre continuamente.
É uma diferença filosófica enorme.
Você não está apenas executando uma sequência de comandos.
Você está declarando uma condição que deseja manter verdadeira.
☕ O COBOLzeiro começa a desconfiar
Nesse momento o veterano de mainframe encosta na cadeira.
— Espera.
— Sim?
— Então existe um sistema que observa workloads, recursos, prioridades, falhas e tenta manter um estado operacional desejado?
Sim.
— Isso está começando a parecer menos alienígena.
Exatamente.
Mainframe e Kubernetes são arquiteturas profundamente diferentes.
Mas os problemas fundamentais de computação continuam aparecendo com roupas novas.
🏗️ Capítulo 5 — O cluster Kubernetes
Um ambiente Kubernetes é organizado num cluster.
Simplificando:
CLUSTER
CONTROL PLANE
|
+---------+---------+
| | |
NODE 1 NODE 2 NODE 3
| | |
Pods Pods Pods
Temos duas grandes categorias:
Control Plane
Worker Nodes
O Control Plane coordena.
Os Nodes executam os workloads.
Pense no submarino.
Existe a ponte de comando:
CONTROL PLANE
e existem as áreas onde o trabalho realmente acontece:
NODES
🎛️ Capítulo 6 — kube-apiserver: a sala de rádio
Quando você escreve:
kubectl apply -f deployment.yaml
você não está entrando diretamente num servidor e mandando iniciar alguma coisa.
Você está interagindo com a API do Kubernetes.
O kube-apiserver é uma peça central dessa arquitetura.
É através dele que grande parte das interações ocorre.
Conceitualmente:
kubectl
|
v
API SERVER
|
+--> autenticação
+--> autorização
+--> validação
+--> objetos Kubernetes
Para quem vem de mainframe, pense nisso como uma grande interface controlada entre operadores, automações e o sistema.
🧠 Capítulo 7 — etcd: a memória do navio
O Kubernetes precisa guardar informações fundamentais sobre seu estado.
Para isso existe o etcd.
É um armazenamento distribuído chave-valor.
Ele contém dados críticos relacionados aos objetos e estado do cluster.
Imagine o diário de bordo:
Deployment A deseja 3 réplicas
Service B existe
ConfigMap C contém configuração
Namespace D está configurado
Se estivéssemos numa série submarina antiga, alguém inevitavelmente entraria correndo:
— CAPITÃO! O COMPUTADOR CENTRAL PERDEU A MEMÓRIA!
E todos fariam cara dramática.
No mundo Kubernetes, proteger o estado do etcd é assunto sério.
Backup e recuperação são fundamentais principalmente quando você administra o Control Plane por conta própria.
⚙️ Capítulo 8 — Scheduler: JES2 encontrou Poseidon
Um Pod precisa executar em algum Node.
Mas onde?
Suponha:
Node A
Node B
Node C
Node D
O Pod precisa de:
CPU: 500m
RAM: 512Mi
Talvez:
Node A -> sem recurso
Node B -> possível
Node C -> restrição de afinidade
Node D -> possível
O scheduler analisa as possibilidades e seleciona um Node adequado.
O COBOLzeiro arregala os olhos.
— Temos um componente escolhendo onde colocar workload considerando recursos?
Sim.
— Eu conheço essa música.
Calma.
Não diga:
Kubernetes Scheduler = JES2
Isso estaria tecnicamente errado.
Mas como mapa mental, existe uma familiaridade interessante.
Schedulers são uma obsessão antiga da computação.
Quando temos muitos trabalhos e recursos limitados, alguém precisa decidir:
quem
onde
quando
com quanto
Muda a arquitetura.
A pergunta permanece.
🫧 Capítulo 9 — Pod não é container
Agora encontramos uma criatura que confunde praticamente todo iniciante:
POD
Kubernetes não trabalha primariamente com containers isolados.
Sua menor unidade de execução e scheduling é normalmente o Pod.
Um Pod pode conter:
Pod
|
+---- Container A
ou:
Pod
|
+---- Container principal
|
+---- Container auxiliar
Os containers dentro de um Pod estão fortemente relacionados e compartilham certas características, particularmente contexto de rede.
Uma analogia razoável seria:
Pod = cápsula operacional
Container = ocupante da cápsula
Não confunda isso com host.
O Pod não é simplesmente uma VM.
Ele é uma abstração do Kubernetes.
🐙 Easter egg — o nome Kubernetes
“Kubernetes” vem do grego e está relacionado à ideia de:
timoneiro, piloto, navegador.
Da mesma raiz linguística surgiram palavras relacionadas a governo e cibernética.
Ou seja, aquele logo com um leme não foi escolhido por acaso.
☸
O símbolo do Kubernetes é literalmente um timão naval.
Para nosso submarino, portanto, não poderíamos ter escolhido tema melhor.
🚢 Capítulo 10 — Não crie Pods na unha
Você pode definir diretamente um Pod.
Mas normalmente não é isso que deseja em produção.
Imagine:
Pod A
Ele morre.
Fim.
Por isso usamos objetos controladores como:
Deployment
Você diz:
Quero 3 réplicas.
O Deployment trabalha junto com ReplicaSets para manter essa condição.
Deployment
|
v
ReplicaSet
|
+--> Pod
+--> Pod
+--> Pod
Se um desaparece:
3 desejados
2 existentes
O sistema tenta criar outro.
🩹 Capítulo 11 — Self-healing não é milagre
Essa capacidade é frequentemente chamada de:
self-healing.
Mas existe um perigo de marketing.
Kubernetes não conserta automaticamente seu software.
Suponha que seu container faça:
START
|
v
BUG
|
v
CRASH
O Kubernetes reinicia.
Resultado:
START
|
v
BUG
|
v
CRASH
|
v
RESTART
|
v
BUG
|
v
CRASH
Em algum momento você pode encontrar:
CrashLoopBackOff
Kubernetes consegue dizer:
“Esse processo deveria estar funcionando.”
Ele não consegue dizer:
“Seu programador esqueceu de inicializar WS-CONTADOR.”
O S0C7 continua sendo problema seu.
😆
🚨 Capítulo 12 — Perdemos um Node!
Agora começa o episódio dramático.
Node A desapareceu.
NODE A
X
Pod 1
Pod 2
Silêncio na ponte.
O sonar dispara.
O Control Plane percebe que workloads deixaram de estar disponíveis.
Dependendo das condições e políticas, substitutos podem ser criados em Nodes saudáveis.
NODE B NODE C
| |
Pod 3 novo Pod 1
Pod 4 novo Pod 2
Esse é um dos motivos fundamentais pelos quais Kubernetes existe.
Em vez de depender de um humano perceber às três da manhã:
“Servidor XPTO caiu.”
o sistema possui mecanismos automáticos para reagir.
📡 Capítulo 13 — Mas se Pod muda de IP, como encontro a aplicação?
Excelente pergunta.
Pods são relativamente efêmeros.
Hoje:
10.10.4.31
Amanhã:
10.10.7.88
Você não quer configurar clientes apontando diretamente para cada Pod.
É aí que entra o:
Service
Conceitualmente:
CLIENTE
|
v
SERVICE
|
+---- Pod A
+---- Pod B
+---- Pod C
O Service fornece uma forma estável de alcançar um conjunto de Pods.
Isso desacopla:
quem chama
de:
qual instância específica está viva neste momento
🌐 Capítulo 14 — Load balancing
O Kubernetes oferece mecanismos para distribuir tráfego entre workloads.
Mas não caia numa simplificação perigosa.
Existem várias camadas possíveis:
Internet
|
Load Balancer externo
|
Ingress / Gateway
|
Service
|
Pods
Cada ambiente pode montar essa arquitetura de forma diferente.
Cloud providers também adicionam componentes próprios.
Portanto dizer:
“Kubernetes possui load balancing”
é correto.
Mas é apenas o começo da história.
📈 Capítulo 15 — O submarino precisa acelerar
Imagine uma aplicação com:
3 Pods
De repente chega uma carga enorme.
CPU sobe.
Requests crescem.
Com mecanismos como Horizontal Pod Autoscaler, podemos aumentar o número de réplicas.
3
|
5
|
8
|
12 Pods
Quando a carga desaparece:
12
|
8
|
5
|
3
Esse é o conceito de autoscaling horizontal.
Mas existe uma pegadinha.
Criar mais Pods exige capacidade física ou virtual.
Se todos os Nodes estiverem cheios:
Kubernetes:
"Preciso criar mais 10 Pods."
Cluster:
"Excelente ideia."
Kubernetes:
"Onde estão os recursos?"
Cluster:
"..."
Pods podem ficar:
Pending
Por isso escalabilidade de workloads e escalabilidade da infraestrutura são problemas relacionados, mas não idênticos.
📦 Capítulo 16 — CPU e memória não aparecem por magia
Você pode declarar requests e limits.
Por exemplo:
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"
requests ajudam o scheduler a entender o que o workload precisa.
limits estabelecem limites operacionais.
Aqui o programador COBOL familiarizado com WLM começa novamente a reconhecer um tema antigo:
recursos não são infinitos.
Todo sistema operacional sério acaba lidando com:
prioridade
capacidade
contenção
limites
planejamento
❤️ Capítulo 17 — Liveness, Readiness e Startup
Esses três conceitos merecem atenção.
Liveness Probe
Pergunta aproximadamente:
“Essa aplicação continua saudável?”
Se falhar repetidamente, pode levar ao reinício do container.
Readiness Probe
Pergunta:
“Está pronta para receber tráfego?”
Talvez a aplicação esteja viva.
Mas:
banco ainda conectando
cache carregando
dependência inicializando
Então:
VIVO? SIM
PRONTO? NÃO
É perfeitamente possível.
Startup Probe
É útil para aplicações que demoram para inicializar.
Durante o startup, você não quer que uma liveness agressiva mate a aplicação antes de ela terminar de subir.
🩺 Diagnóstico submarino
Imagine:
Paciente respirando?
Liveness.
Paciente consegue trabalhar?
Readiness.
Paciente acabou de acordar da anestesia?
Startup.
É simplificado, mas ajuda muito.
🔐 Capítulo 18 — ConfigMap e Secret
Imagine uma configuração:
API_URL
LOG_LEVEL
TIMEOUT
Você não precisa colocar tudo dentro da imagem.
Kubernetes oferece:
ConfigMap
para configurações.
Para dados sensíveis existe:
Secret
Mas atenção.
A palavra “Secret” não significa automaticamente:
Ninguém jamais conseguirá ler isso.
Segurança real exige arquitetura.
Inclui coisas como:
RBAC
criptografia
controle de acesso
secret managers
gestão de chaves
auditoria
políticas
Nunca confunda nome de objeto com garantia criptográfica.
🗄️ Capítulo 19 — E os dados?
Pods podem desaparecer.
Mas seu banco de dados talvez não possa.
Imagine:
Pod
|
X
Tudo que estava exclusivamente no filesystem efêmero daquele Pod pode sumir junto com ele.
Para persistência entram conceitos como:
PersistentVolume
PersistentVolumeClaim
StorageClass
CSI
Uma visão extremamente simplificada:
POD
|
PVC
|
PV
|
STORAGE
A aplicação pode morrer.
Outra pode nascer.
Os dados continuam.
Pelo menos essa é a intenção.
Storage em Kubernetes é um dos pontos onde o mergulho deixa de ser piscina infantil e vira Fossa das Marianas.
📊 Capítulo 20 — Kubernetes não é Prometheus
Outro mito:
“Kubernetes já monitora tudo.”
Não exatamente.
Kubernetes possui informações operacionais fundamentais.
Mas observabilidade completa geralmente envolve ecossistemas adicionais.
Podemos querer:
Métricas
Logs
Traces
Alertas
Dashboards
É comum encontrar tecnologias como:
Prometheus
Grafana
OpenTelemetry
e soluções comerciais.
Lembre:
Kubernetes administra workloads.
Isso não significa:
Kubernetes substitui sua estratégia inteira de observabilidade.
🧾 Capítulo 21 — YAML: o JCL que bebeu chá de cogumelo?
O primeiro contato do COBOLzeiro com Kubernetes geralmente é:
apiVersion: apps/v1
kind: Deployment
metadata:
name: cafe
spec:
replicas: 3
Ele olha aquilo.
Olha novamente.
— Então é isso?
Não.
YAML é apenas uma forma comum de representar objetos que serão enviados à API Kubernetes.
O fluxo real é mais interessante:
YAML
|
v
API SERVER
|
v
OBJETO
|
v
ESTADO DESEJADO
|
v
CONTROLLERS
|
v
ESTADO REAL
Portanto Kubernetes não é YAML.
Assim como:
z/OS não é JCL
apesar de alguém poder conhecer z/OS inicialmente através de JCL.
🧠 Capítulo 22 — JCL e Kubernetes: parentes distantes
Existe uma analogia interessante.
Em JCL declaramos:
programa
datasets
parâmetros
condições
recursos
E entregamos o job.
No Kubernetes declaramos:
imagem
réplicas
volumes
rede
recursos
configuração
E entregamos o objeto ao cluster.
Mas existe uma diferença essencial.
O JCL tradicional está fortemente ligado a uma execução.
Kubernetes frequentemente declara:
“Quero que isso continue verdadeiro.”
Exemplo:
replicas = 5
Isso não significa:
“Crie cinco processos uma vez.”
Significa aproximadamente:
“Mantenha cinco instâncias enquanto essa configuração permanecer.”
Essa persistência do estado desejado é fundamental.
🧙 Capítulo 23 — WLM aparece no periscópio
Agora o COBOLzeiro veterano começa a sorrir.
O WLM no z/OS lida com questões como:
objetivos
prioridades
recursos
classes de serviço
competição entre workloads
Kubernetes possui mecanismos diferentes, mas também precisa responder:
Onde executar?
Quanto recurso reservar?
Quem pode consumir?
Qual workload tem prioridade?
O que acontece quando falta capacidade?
Repita comigo:
Kubernetes NÃO é WLM.
Mas ambos pertencem a uma longa tradição de sistemas tentando administrar cargas computacionais automaticamente.
O problema é antigo.
As soluções mudam.
🧩 Capítulo 24 — Kubernetes e COBOL podem conviver
Agora chegamos a um ponto importantíssimo.
Quando alguém diz:
“Estamos modernizando com Kubernetes.”
alguns COBOLzeiros imaginam imediatamente:
COBOL
|
v
LIXO
Não.
Uma arquitetura perfeitamente possível seria:
Internet
|
v
Kubernetes
/ | \
API API API
\ | /
API Gateway
|
v
z/OS Connect
|
+--------+--------+
| |
CICS IMS
| |
COBOL COBOL
|
Db2
Kubernetes pode hospedar:
APIs
microservices
frontends
integrações
processamento auxiliar
componentes de IA
enquanto o core transacional continua no mainframe.
Modernização não é sinônimo de:
jogar COBOL fora.
Muitas vezes significa:
envolver o legado com novas interfaces.
🏛️ Capítulo 25 — O mainframe não precisa morar dentro do Kubernetes
Isso parece óbvio.
Mas precisa ser dito.
Existe uma tendência na indústria de imaginar que qualquer tecnologia nova precisa substituir a anterior.
Não funciona assim.
Você pode ter:
IBM Z
+
Kubernetes
+
cloud
+
SaaS
+
APIs
Tudo coexistindo.
Empresas grandes são fósseis vivos tecnológicos.
Possuem camadas acumuladas durante décadas.
E isso não é necessariamente ruim.
O problema não é idade.
O problema é incapacidade de evolução.
💸 Capítulo 26 — Kubernetes custa dinheiro
Agora chega o financeiro à ponte do submarino.
— Quanto custa?
O arquiteto responde:
— O cluster custa X.
Errado.
O cluster custa:
compute
storage
network
load balancers
Mas o Kubernetes organizacional custa também:
treinamento
SRE
DevOps
observabilidade
CI/CD
segurança
networking
upgrades
backup
disaster recovery
GitOps
governança
troubleshooting
Uma pequena empresa pode descobrir que transformou:
5 aplicações
num ambiente que exige:
especialista Kubernetes
especialista cloud
especialista networking
especialista segurança
especialista observabilidade
Parabéns.
Você resolveu um problema que talvez não tivesse.
🛶 Capítulo 27 — Quando NÃO usar Kubernetes
Suponha:
Aplicações: 3
Equipe: 4 pessoas
Deploy: mensal
Tráfego: previsível
Disponibilidade: normal
Você realmente precisa de Kubernetes?
Talvez não.
Às vezes:
VM
Docker Compose
serviço gerenciado
PaaS
container service
resolvem.
Tecnologia boa é a tecnologia proporcional ao problema.
Usar Kubernetes para tudo é como comprar o USS Seaview para atravessar uma piscina.
Funciona.
Mas talvez uma boia bastasse.
🚢 Capítulo 28 — Quando Kubernetes começa a fazer sentido
Kubernetes tende a ficar atraente quando começam a aparecer vários fatores simultaneamente:
grande quantidade de serviços;
necessidade de automação operacional;
múltiplas equipes;
alta disponibilidade;
atualizações frequentes;
escalabilidade dinâmica;
infraestrutura heterogênea;
necessidade de padronização;
automação via API;
ambientes híbridos;
práticas DevOps e GitOps maduras.
A palavra fundamental é:
complexidade.
Kubernetes não elimina complexidade.
Ele tenta organizar complexidade inevitável.
Essa diferença é enorme.
⚓ Capítulo 29 — Kubernetes gerenciado
Se administrar tudo manualmente parece assustador, existem serviços gerenciados.
Exemplos conhecidos incluem:
Amazon EKS
Azure AKS
Google GKE
O provedor assume parte da operação.
Isso pode reduzir bastante o peso do Control Plane.
Mas não elimina responsabilidades.
Você ainda precisa entender:
workloads
rede
segurança
IAM
RBAC
storage
observabilidade
custos
deployments
capacity planning
Managed Kubernetes não significa:
“Agora ninguém precisa saber Kubernetes.”
Significa:
“Algumas partes dolorosas possuem outro responsável.”
🐳 Capítulo 30 — containerd e o fantasma do Docker
Existe ainda uma curiosidade que confunde iniciantes.
Antigamente era comum associar diretamente Kubernetes ao Docker runtime.
Depois Kubernetes removeu o componente conhecido como dockershim.
Hoje runtimes compatíveis com CRI, especialmente:
containerd
CRI-O
são comuns.
Mas isso não significa que imagens criadas com Docker deixaram de funcionar.
A distinção importante é:
Docker como ferramenta/ecossistema de construção
≠
Docker Engine obrigatório dentro do Kubernetes
Esse detalhe costuma render algumas discussões de bar extremamente desnecessárias.
👻 Easter egg — Pods são descartáveis, dados não
Uma filosofia cloud-native bastante importante diz:
Não se apaixone pela instância.
Se um Pod morre:
crie outro.
Isso é culturalmente diferente de ambientes tradicionais nos quais um servidor pode receber nome, personalidade e quase CPF.
Quem trabalhou em CPD antigo conhece:
SRVPROD01
quinze anos depois:
NÃO DESLIGAR.
NINGUÉM SABE O QUE TEM AQUI.
Kubernetes tenta incentivar outro modelo:
instâncias são substituíveis
estado importante fica fora delas
É uma mudança arquitetural gigantesca.
🔄 Capítulo 31 — Rolling Updates
Imagine que temos:
Versão 1
rodando em cinco Pods.
Queremos:
Versão 2
Não precisamos necessariamente destruir tudo simultaneamente.
Kubernetes pode substituir gradualmente:
V1 V1 V1 V1 V1
V2 V1 V1 V1 V1
V2 V2 V1 V1 V1
V2 V2 V2 V1 V1
V2 V2 V2 V2 V1
V2 V2 V2 V2 V2
Esse conceito é associado a rolling updates.
Se algo der errado, estratégias de rollback podem ajudar.
Para quem viveu décadas com janelas de mudança gigantescas:
SÁBADO
23:00
TODO MUNDO NA SALA
PIZZA
BACKOUT PLAN IMPRESSO
isso parece quase ficção científica.
Embora, sejamos sinceros:
em algumas empresas o Kubernetes apenas adicionou YAML à mesma pizza de sábado.
🔍 Capítulo 32 — kubectl: o periscópio
Uma das ferramentas mais usadas para interagir com Kubernetes é:
kubectl
Alguns comandos básicos:
kubectl get pods
Lista Pods.
kubectl get nodes
Lista Nodes.
kubectl describe pod nome
Mostra informações detalhadas.
kubectl logs nome-do-pod
Mostra logs.
kubectl get deployments
Lista Deployments.
Para o COBOLzeiro:
kubectl
eventualmente começa a assumir um papel psicológico semelhante ao:
SDSF
Não tecnicamente.
Mas emocionalmente.
Quando algo quebra:
COBOLzeiro:
SDSF.
Kuberneteszeiro:
kubectl.
😁
🧪 Capítulo 33 — Primeiro laboratório mental
Vamos montar uma aplicação imaginária.
Nome:
cafe-api
Queremos três réplicas.
apiVersion: apps/v1
kind: Deployment
metadata:
name: cafe-api
spec:
replicas: 3
A intenção é:
Deployment
|
+--> Pod 1
+--> Pod 2
+--> Pod 3
Agora um Pod quebra.
Estado real:
Pod 1
Pod 2
Kubernetes observa.
Desejado = 3
Atual = 2
Control loop:
Criar outro.
Nasce:
Pod 4
Não precisamos recuperar exatamente o velho Pod 3.
Precisamos restaurar:
quantidade desejada = 3
Essa distinção é maravilhosa.
O sistema não possui sentimentalismo.
🧠 Capítulo 34 — Pets versus cattle
Existe uma velha metáfora de infraestrutura:
Pets
versus
Cattle
Pets recebem nomes.
Você cuida individualmente.
Cattle são tratados como grupo.
No modelo tradicional:
Servidor Hercules
cai.
Todos correm para recuperar Hercules.
No modelo cloud-native:
instância 27
cai.
O sistema cria:
instância 42
O objetivo não é preservar o indivíduo.
É preservar o serviço.
Essa ideia aparece fortemente no Kubernetes.
🧯 Capítulo 35 — Kubernetes não elimina incidentes
Outra ilusão perigosa:
“Com Kubernetes teremos alta disponibilidade e não teremos mais problemas.”
Teremos.
Só mudaremos o catálogo.
Antes:
servidor caiu
Agora:
Pod Pending
CrashLoopBackOff
ImagePullBackOff
OOMKilled
PVC Pending
DNS quebrado
Ingress errado
RBAC negando acesso
certificate expired
node pressure
CNI quebrado
Toda tecnologia que resolve dez problemas geralmente introduz sete completamente novos.
O segredo da engenharia não é eliminar problemas.
É trocar problemas ruins por problemas mais administráveis.
🌊 Capítulo 36 — A grande lição da viagem
Chegamos ao fundo do oceano.
O COBOLzeiro olha pela escotilha.
Ao longe vemos:
Pods
Services
Deployments
Nodes
Volumes
Controllers
nadando tranquilamente pelo cluster.
Depois de toda essa viagem, podemos finalmente definir Kubernetes com alguma precisão.
Não diga apenas:
“Kubernetes é uma ferramenta para containers.”
Melhor:
Kubernetes é uma plataforma de orquestração baseada em APIs e control loops que permite declarar como workloads containerizados deveriam estar funcionando e trabalha continuamente para aproximar o estado real do cluster desse estado desejado.
Essa definição explica quase tudo.
☕ O mapa do COBOLzeiro
Se você está começando, memorize esta sequência:
1. APPLICATION
|
v
2. IMAGE
|
v
3. CONTAINER
|
v
4. POD
|
v
5. DEPLOYMENT
|
v
6. SERVICE
|
v
7. NODE
|
v
8. CLUSTER
Depois adicione:
ConfigMap
Secret
Volume
Ingress
HPA
RBAC
Observabilidade
Não tente aprender tudo simultaneamente.
🧭 Roteiro de estudo Bellacosa
Para um COBOLzeiro iniciante eu seguiria esta ordem.
Passo 1 — Aprenda container
Entenda:
imagem
container
registry
Dockerfile
runtime
Passo 2 — Aprenda Pod
Descubra por que Kubernetes trabalha com Pods.
Passo 3 — Deployment
Entenda:
replicas
ReplicaSet
rolling update
self-healing
Passo 4 — Service
Aprenda descoberta e acesso aos Pods.
Passo 5 — Configuração
Estude:
ConfigMap
Secret
Passo 6 — Storage
Depois:
PV
PVC
StorageClass
Passo 7 — Probes
Estude:
startup
readiness
liveness
Passo 8 — Scheduling
Entre em:
requests
limits
affinity
taints
tolerations
Passo 9 — Segurança
Não pule:
RBAC
ServiceAccount
NetworkPolicy
Secrets
Passo 10 — Observabilidade
Finalmente:
logs
metrics
traces
alerts
Só depois disso mergulhe alegremente no abismo chamado:
Helm
Operators
GitOps
Service Mesh
CRDs
Admission Controllers
Porque depois desse ponto o submarino já está a 11 mil metros.
🧙♂️ Dica do velho operador
Quando um Kubernetes parecer complicado demais, não tente memorizar todos os nomes.
Faça sempre cinco perguntas:
1. O que deveria existir?
2. O que existe realmente?
3. Quem observa essa diferença?
4. Quem deveria corrigi-la?
5. Por que não conseguiu?
Essa técnica resolve uma quantidade surpreendente de investigações.
E curiosamente é quase a mesma forma de pensar usada há décadas para diagnosticar ambientes de produção.
🐙 O monstro final: complexidade
No último episódio de nossa expedição aparece diante do submarino uma criatura colossal.
Não é Docker.
Não é YAML.
Não é networking.
É:
COMPLEXIDADE
Kubernetes nasceu porque sistemas distribuídos modernos ficaram complexos demais para administração manual.
Mas existe um paradoxo.
Para controlar complexidade, Kubernetes introduz sua própria complexidade.
Então a decisão madura nunca é:
Kubernetes é bom?
A pergunta correta é:
“O problema que tenho justifica a complexidade operacional que Kubernetes introduzirá?”
Se sim, ele pode ser extraordinário.
Se não, talvez você esteja usando um submarino nuclear para entregar pizza.
🌅 Epílogo — Emergindo do cluster
O USS Kubernetes finalmente retorna à superfície.
O jovem COBOLzeiro sai pela escotilha.
No início da viagem ele conhecia:
JCL
COBOL
CICS
Db2
JES2
Agora carrega um caderno com:
Container
Pod
Deployment
Service
Node
Cluster
Control Plane
Scheduler
etcd
ConfigMap
Secret
PVC
HPA
Probe
Ele olha para o arquiteto.
— Acho que entendi Kubernetes.
— Excelente!
— É um sistema enorme que recebe uma descrição do estado que queremos, observa continuamente o estado que existe e tenta corrigir as diferenças automaticamente.
O arquiteto sorri.
— Perfeito.
O COBOLzeiro toma o último gole do café.
— Então passamos cinquenta anos distribuindo computação para depois construir um negócio gigantesco para coordenar tudo novamente.
Silêncio na sala.
O sysprog veterano, sentado no canto, finalmente levanta os olhos do terminal.
— Eu estava esperando alguém perceber.
☕
E talvez esse seja o maior easter egg de toda a história.
A tecnologia muda.
Os nomes mudam.
Os logos ficam mais bonitos.
O YAML substitui cartões perfurados.
O container substitui parte da configuração artesanal.
O cluster substitui fileiras de servidores administrados individualmente.
Mas a pergunta original continua ecoando pelos corredores do CPD, pelo datacenter, pela cloud e agora pelas profundezas do nosso submarino:
“Temos um monte de programas, recursos limitados, máquinas que quebram e usuários que não querem saber de nada disso. Quem vai administrar essa porra toda?”
No mainframe, construímos respostas.
No Unix, construímos outras.
Na virtualização, outras.
Na cloud, outras.
E no universo containerizado, uma das grandes respostas recebeu um nome grego, um timão como logotipo e a missão quase naval de manter milhares de pequenas embarcações seguindo o curso declarado:
Kubernetes.
Ou, para os íntimos do Bellacosa Mainframe:
//KUBEJOB JOB ...
//STEP01 EXEC PGM=KEEP-EVERYTHING-ALIVE
//SYSOUT DD SYSOUT=*
//COFFEE DD DISP=SHR,DSN=BELLACOSA.CAFE.FORTE
RC=0000.
Esperamos. ☕☸️🌊
Sem comentários:
Enviar um comentário