 |
| Bellacosa Mainframe apresenta kubernetes para coboleiros |
☕ Um Café no Bellacosa Mainframe
Kubernetes para COBOLzeiros: o Guia do Mochileiro das Galáxias para quem saiu do JES2, encontrou um Pod e perguntou onde diabos colocaram o JCL
🚀 Pods, Deployments, Services, YAML, containers, RBAC, storage, GitOps e a estranha descoberta de que o mundo cloud-native passou décadas reinventando problemas que o velho operador do mainframe já conhecia — só que agora tudo tem nomes novos, logos simpáticos e pode desaparecer antes do café esfriar
Há uma frase impressa em letras grandes e amistosas na capa do Guia do Mochileiro das Galáxias:
NÃO ENTRE EM PÂNICO.
Se Douglas Adams tivesse vivido tempo suficiente para trabalhar com Kubernetes, provavelmente acrescentaria uma segunda:
E NÃO APAGUE O NAMESPACE prod.
Porque Kubernetes tem uma característica curiosa.
Quando você olha pela primeira vez, encontra palavras como:
Pod, Deployment, ReplicaSet, Service, Ingress, ConfigMap, Secret, StatefulSet, DaemonSet, Helm, Operator, CRD.
O COBOLzeiro veterano olha aquilo e pensa:
— Meu Deus. Inventaram outra computação.
Não inventaram.
Mudaram a arquitetura, mudaram a escala, mudaram a implementação, inventaram abstrações extremamente poderosas e deram nomes diferentes a problemas que, em muitos casos, nós já enfrentávamos quando o terminal ainda era verde.
Precisamos executar programas.
Precisamos saber onde executá-los.
Precisamos distribuir recursos.
Precisamos armazenar configurações.
Precisamos controlar acesso.
Precisamos monitorar aplicações.
Precisamos guardar dados.
Precisamos recuperar processos que morreram.
Precisamos instalar novas versões sem transformar terça-feira à noite numa reunião extraordinária com 27 pessoas.
E, acima de tudo:
precisamos impedir que alguma coisa quebrou às 02:47 da manhã sem ninguém saber por quê.
Então pegue sua toalha, seu café e talvez aquele manual de JCL que você insiste em manter na gaveta.
Hoje vamos viajar para Kubernetes.
1. Antes de Kubernetes havia... computadores
Vamos começar pelo começo.
Um programador COBOL iniciante conhece aproximadamente este universo:
Programa COBOL
|
v
Compilação
|
v
LOAD MODULE
|
v
JCL
|
v
JES
|
v
Execução
Naturalmente estou simplificando.
Mas existe uma ideia importante:
o programa precisa de um ambiente para executar.
Ele precisa de CPU, memória, arquivos, bibliotecas, configuração, permissões e recursos.
Isso nunca desapareceu.
No universo moderno surgiu outro problema.
Imagine uma aplicação desenvolvida em determinado ambiente:
Aplicação
+
bibliotecas
+
runtime
+
dependências
+
configuração
Na máquina do desenvolvedor funciona perfeitamente.
Vai para outro servidor:
ABEND GALÁCTICO
— Mas na minha máquina funciona!
Essa frase provavelmente causou mais sofrimento humano que Vogons lendo poesia.
Uma das respostas modernas para esse problema foram os containers.
2. Container: coloque a aplicação numa caixinha
De maneira bastante simplificada, um container empacota a aplicação e aquilo de que ela precisa para executar de forma consistente.
Pense:
+----------------------+
| CONTAINER |
| |
| aplicação |
| runtime |
| bibliotecas |
| dependências |
| |
+----------------------+
Isso melhora enormemente a portabilidade.
Mas imediatamente surge outro problema.
Você possui:
1 container
Tudo maravilhoso.
Depois:
10 containers
Administrável.
Depois:
100 containers
Interessante.
Depois:
3.000 containers
Alguém pergunta:
— Quem administra isso?
Silêncio na sala.
É nesse momento que Kubernetes entra pela porta.
3. Kubernetes não é simplesmente um “Docker grandão”
Essa comparação ajuda durante cinco minutos e depois começa a atrapalhar.
Kubernetes é uma plataforma para orquestração de workloads containerizadas.
A palavra mágica é:
ORQUESTRAÇÃO
Imagine uma orquestra com 200 músicos.
O maestro não toca simultaneamente todos os instrumentos.
Ele coordena o conjunto.
Kubernetes tenta responder perguntas como:
onde uma aplicação será executada?
quantas cópias dela devem existir?
o que fazer quando uma morre?
como encontrar essas cópias?
como distribuir tráfego?
como atualizar uma versão?
como fornecer configuração?
como controlar recursos?
como armazenar dados persistentes?
quem pode alterar o quê?
Isso já começa a parecer menos alienígena para alguém vindo de ambientes corporativos.
4. A ideia que muda tudo: estado desejado
Aqui está provavelmente o conceito mais importante de Kubernetes.
Você declara aquilo que deseja.
Por exemplo:
replicas: 3
Traduzindo para português de máquina do café:
“Senhor Kubernetes, eu gostaria que existissem três instâncias dessa aplicação.”
Ele observa:
DESEJADO = 3
ATUAL = 3
Tudo certo.
Então uma delas morre:
DESEJADO = 3
ATUAL = 2
Kubernetes percebe:
— Isso não está certo.
E tenta retornar para:
3
Esse processo é chamado, em essência, de reconciliação.
Podemos imaginar:
Estado desejado
|
v
Estado atual
|
v
São iguais?
/ \
SIM NÃO
| |
OK corrigir
|
+------+
|
v
observar
novamente
Kubernetes é, em grande parte, uma enorme máquina dizendo:
“O universo não está como deveria estar. Vou tentar consertá-lo.”
É uma ambição que normalmente encontramos apenas em sistemas distribuídos, religiões e departamentos de arquitetura corporativa.
5. Control Plane: conheça o cérebro da criatura
Um cluster Kubernetes pode ser imaginado assim:
KUBERNETES CLUSTER
|
+------------+------------+
| |
CONTROL PLANE WORKER NODES
| |
API Server Pods
Scheduler kubelet
Controllers runtime
etcd network
O Control Plane administra o estado do cluster.
E um dos personagens principais é:
kube-apiserver
Quando você executa:
kubectl get pods
não está indo de porta em porta perguntar aos containers:
— Boa tarde, senhor Pod, o senhor está vivo?
Você fala com a API do Kubernetes.
Conceitualmente:
VOCÊ
|
kubectl
|
v
API SERVER
|
+-- autenticação
+-- autorização
+-- validação
+-- recursos do cluster
Esse detalhe revela uma característica fundamental:
Kubernetes é profundamente API-driven.
6. etcd: o sujeito que sabe das coisas
O etcd é um armazenamento distribuído chave-valor usado pelo Kubernetes para guardar dados essenciais sobre o estado do cluster.
Imagine que alguém diga:
— Temos backup dos servidores.
Ótimo.
— E do etcd?
Silêncio.
Uma mosca passa.
O operador começa lentamente a beber o café.
Informações críticas do estado do cluster dependem dele. Portanto backup e recuperação do etcd são assuntos sérios.
Primeira regra da produção:
Backup que nunca teve restauração testada é uma crença religiosa.
7. Scheduler: o JES encontrou um primo distante
Você solicita uma workload.
Existem vários Nodes:
NODE-A
NODE-B
NODE-C
NODE-D
Onde ela será executada?
O Scheduler participa dessa decisão.
Ele considera recursos e restrições como:
CPU
memória
afinidade
anti-afinidade
taints
tolerations
restrições de placement
O COBOLzeiro começa a sorrir.
— Espere... alguém recebe uma carga de trabalho, olha recursos e decide onde executar?
Sim.
— Então é JES?
NÃO.
Guarde a toalha.
As tecnologias, arquiteturas e responsabilidades são diferentes.
Mas existe um parentesco conceitual extremamente útil para aprender.
O truque para um profissional experiente aprender tecnologia nova não é fingir que tudo é completamente novo.
É perguntar:
“Qual problema antigo essa abstração está tentando resolver de uma maneira nova?”
8. Worker Node: onde a marmota realmente trabalha
O Control Plane coordena.
Os Worker Nodes executam as workloads.
Dentro deles encontramos componentes como o kubelet, runtime de containers e elementos relacionados a networking.
Podemos imaginar:
WORKER NODE
|
+-- kubelet
|
+-- runtime
|
+-- POD
| |
| +-- container
|
+-- POD
|
+-- container
E aqui encontramos talvez a palavra mais famosa do Kubernetes.
9. POD — não é ervilha espacial
O Kubernetes não trabalha simplesmente administrando containers isoladamente.
Uma unidade fundamental de execução é o:
Pod
Normalmente encontramos:
Pod
|
+-- Container
Mas um Pod pode possuir mais de um container quando existe uma razão arquitetural para isso:
Pod
|
+-- aplicação
|
+-- container auxiliar
Containers no mesmo Pod compartilham aspectos importantes de seu ambiente.
Portanto:
POD != CONTAINER
Grave isso.
Pode parecer uma distinção acadêmica no primeiro dia.
No vigésimo ela salva sua compreensão do ambiente.
10. E o Pod morreu
Aqui acontece uma transformação filosófica interessante para quem passou décadas tratando servidores como indivíduos.
No mundo tradicional:
“Esse é o servidor XPTO01. Cuide dele.”
No Kubernetes, muita infraestrutura é tratada como efêmera.
O Pod morreu?
Pode surgir outro.
Hoje:
Pod A
10.20.1.17
Amanhã:
Pod A = morto
Pod B
10.20.4.38
Por isso construir dependências baseadas diretamente na identidade transitória de um Pod seria uma péssima ideia.
Precisamos de abstrações.
11. ReplicaSet: quero três vivos
Imagine:
Desejado = 3 Pods
Temos:
Pod
Pod
Pod
Um desaparece:
Pod
X
Pod
O ReplicaSet ajuda a manter:
3
criando outro.
Aqui reencontramos nosso velho amigo:
estado desejado.
12. Deployment: agora precisamos atualizar tudo
Na prática, para aplicações comuns, normalmente trabalhamos com um Deployment, que administra ReplicaSets e facilita rollouts.
Imagine:
Deployment
|
ReplicaSet V1
|
+-- Pod
+-- Pod
+-- Pod
Sai versão nova.
Em vez de:
PARE TUDO!
podemos fazer uma substituição progressiva:
V1 V1 V1
V2 V1 V1
V2 V2 V1
V2 V2 V2
Isso é tremendamente importante em ambientes modernos onde deploys podem ocorrer com frequência.
E quando algo dá errado?
Rollback passa a fazer parte da conversa.
13. Service: “mas qual IP eu chamo?”
Lembra que Pods podem desaparecer?
Temos:
Frontend
|
???
|
Backend Pods
Como o frontend encontra o backend se os Pods mudam?
Usamos uma abstração chamada:
Service
CLIENTE
|
v
SERVICE
|
+---- Pod
|
+---- Pod
|
+---- Pod
O Service fornece um ponto lógico estável para acessar um conjunto de Pods selecionados.
Aqui existe uma das ideias mais bonitas do cloud-native:
colocar identidade lógica estável diante de componentes fisicamente transitórios.
14. ConfigMap: não coloque o universo dentro do programa
Aplicações precisam de configurações:
LOG_LEVEL=INFO
LANGUAGE=PT_BR
API_HOST=...
Você poderia colocar tudo dentro da imagem.
Mas então qualquer mudança exigiria outra construção da imagem.
ConfigMaps permitem separar parte da configuração da aplicação.
É uma evolução daquele princípio antigo:
programa é uma coisa; parâmetros do ambiente são outra.
COBOLzeiro conhece essa conversa há décadas, mesmo usando mecanismos completamente diferentes.
15. Secret: o nome promete mais do que parece
Temos informações sensíveis:
senha
token
chave
certificado
Kubernetes possui o objeto Secret.
Mas cuidado com uma armadilha clássica:
Um objeto chamado Secret não significa automaticamente “segredo absolutamente protegido contra tudo”.
Segurança adequada envolve também:
Colocar a senha em Secret e declarar vitória é como escrever:
//PASSWORD DD *
SUPERSECRETA123
/*
e colocar uma etiqueta dizendo CONFIDENCIAL.
A etiqueta não é o controle de segurança.
16. Storage: containers morrem; saldo bancário não deveria
Containers são naturalmente descartáveis.
Dados empresariais frequentemente não são.
Imagine:
Banco de dados
|
container
|
morreu
Kubernetes responde:
— Sem problemas, fazemos outro!
O DBA responde:
— E MEUS DADOS?
E nesse instante nasce uma reunião.
Para persistência encontramos conceitos como:
PersistentVolume
PersistentVolumeClaim
StorageClass
Simplificando:
POD
|
PVC
|
PV
|
STORAGE REAL
O Pod pode ser transitório.
O armazenamento precisa seguir regras diferentes.
17. StatefulSet: quando identidade importa
Deployments funcionam muito bem quando as instâncias podem ser relativamente intercambiáveis.
Mas nem toda workload funciona assim.
Algumas precisam de identidade previsível:
db-0
db-1
db-2
e armazenamento associado.
Aparece então o:
StatefulSet
Ele é especialmente relevante para workloads stateful e sistemas distribuídos que precisam de identidade e ordenação mais previsíveis.
Isso não significa:
“StatefulSet transforma magicamente qualquer banco em banco cloud-native.”
Se fosse tão fácil, DBA seria uma profissão de seis minutos.
18. DaemonSet: um para cada Node
Imagine um agente de monitoramento que precisa existir em todos os Nodes:
NODE A → agente
NODE B → agente
NODE C → agente
NODE D → agente
O DaemonSet serve muito bem para esse padrão.
Aplicações típicas incluem agentes de:
observabilidade;
logging;
segurança;
networking.
Quando surge outro Node, a intenção pode ser automaticamente refletida nele.
Estado desejado novamente.
Kubernetes é quase obsessivo.
19. Jobs e CronJobs: o COBOLzeiro reconhece um parente
Nem tudo precisa ficar executando eternamente.
Temos tarefas:
INÍCIO
|
PROCESSAMENTO
|
FIM
Kubernetes possui Jobs.
E para tarefas periódicas:
CronJobs
O COBOLzeiro imediatamente pergunta:
— Então isso é batch?
Em espírito, estamos no mesmo bairro.
Mas não na mesma casa.
Um Job Kubernetes não substitui automaticamente décadas de ecossistema batch corporativo, scheduling, dependências, restart/recovery, controles operacionais e processamento transacional.
Ainda assim, a analogia ajuda enormemente:
Job → trabalho finito
CronJob → trabalho agendado
20. Requests e Limits: WLM manda lembranças
Aqui chegamos a uma área deliciosa para quem conhece mainframe.
Uma workload pode declarar algo semelhante a:
resources:
requests:
cpu: "500m"
memory: "512Mi"
limits:
cpu: "1"
memory: "1Gi"
Simplificando, requests ajudam a expressar recursos necessários para scheduling; limits impõem tetos de utilização conforme o recurso.
A pergunta filosófica é antiga:
Temos recursos finitos e consumidores potencialmente infinitos. Quem recebe quanto?
O mainframe possui décadas de engenharia sofisticadíssima em workload management.
Kubernetes aborda isso dentro de seu próprio modelo.
Não diga:
Kubernetes WLM = IBM WLM
Não são equivalentes.
Diga:
Ambos enfrentam aspectos do velho problema de administrar recursos compartilhados e workloads concorrentes.
Essa comparação ensina.
A equivalência enganaria.
21. Agora chegamos ao inferno: produção
Até aqui tudo funciona.
Tutorial:
pod/myapp created
Aluno:
— Kubernetes é fácil!
Produção:
CrashLoopBackOff
Aluno:
— Chamem um adulto.
E aqui começa o verdadeiro treinamento.
Você precisa conhecer:
logs;
events;
probes;
métricas;
CPU;
memória;
DNS;
networking;
storage;
permissões;
dependências;
configuração.
Porque:
CrashLoopBackOff
não significa:
“Execute o comando secreto número 17.”
Significa que existe um comportamento de reinício repetido a investigar.
A causa pode ser:
configuração errada
dependência indisponível
credencial
permissão
OOM
bug
porta
DNS
storage
probe
É quase o nosso querido:
S0C7
O código oferece uma pista.
Mas experiência transforma a pista em investigação.
22. Observabilidade: o cluster precisa falar
Imagine:
Usuário
|
Ingress
|
Service
|
Pod
|
Aplicação
|
API
|
Banco
Usuário diz:
“Está lento.”
Maravilha.
Onde?
Precisamos de diferentes sinais:
METRICS
LOGS
TRACES
EVENTS
Não basta saber que um Pod está Running.
Um processo pode estar vivo e a aplicação completamente inútil.
É por isso que existem conceitos como:
liveness probe e readiness probe.
De forma simplificada:
Liveness:
"Você ainda está vivo?"
Readiness:
"Você está pronto para receber tráfego?"
São perguntas diferentes.
Um sujeito pode estar vivo às seis da manhã e absolutamente não estar pronto para receber tráfego.
Eu sou prova disso antes do café.
23. RBAC: RACF olha pela janela
RBAC significa Role-Based Access Control.
A pergunta é familiar:
QUEM
|
pode fazer
|
O QUÊ
|
sobre QUAL RECURSO?
Exemplo:
PROGRAMADOR
|
+--> visualizar Pods SIM
+--> consultar logs SIM
+--> destruir cluster NÃO, ESPERAMOS
Quem conhece RACF encontra aqui outra ponte conceitual.
RBAC não é RACF.
Mas autorização baseada em identidades, recursos, permissões e mínimo privilégio definitivamente não nasceu ontem.
24. NetworkPolicy: “você não precisa conversar com ele”
Imagine:
FRONTEND
|
BACKEND
|
DATABASE
O frontend precisa realmente acessar diretamente o banco?
Talvez não.
Então podemos desejar:
Frontend ---> Backend OK
Frontend -X-> Database NÃO
Backend ----> Database OK
Network Policies permitem controlar fluxos de rede entre workloads quando suportadas adequadamente pelo ambiente de networking.
Aqui começamos a caminhar em direção a arquiteturas mais próximas do princípio de:
negue aquilo que não é necessário.
25. Helm: porque 47 YAMLs também cansam
No início temos:
deployment.yaml
Depois:
deployment.yaml
service.yaml
configmap.yaml
ingress.yaml
secret.yaml
pvc.yaml
...
Em determinado momento alguém pergunta:
— Não poderíamos empacotar isso?
Entra Helm.
Helm trabalha com Charts, templates e valores configuráveis.
Conceitualmente:
Chart
|
+-- templates
|
+-- values
|
+-- metadata
E aqui ocorre um ritual iniciático cloud-native:
você aprende YAML;
aprende templates;
aprende templates que produzem YAML;
recebe uma mensagem de erro;
olha para o teto;
reconsidera decisões profissionais;
resolve;
coloca no LinkedIn.
26. CRD: “eu também posso inventar objetos?”
Sim.
Uma das capacidades mais interessantes do Kubernetes são as Custom Resource Definitions.
Originalmente você trabalha com recursos como:
Pod
Service
Deployment
Com CRDs podemos estender a API com recursos específicos.
Conceitualmente:
Database
Certificate
KafkaCluster
Backup
MeuObjetoCorporativo
Isso revela que Kubernetes é mais que um mero lançador de containers.
Ele oferece uma espécie de framework declarativo extensível para sistemas de controle.
Essa mudança mental é importante.
27. Operator: o runbook ganhou pernas
Imagine o velho especialista.
Ele sabe:
SE A acontecer
verifique B
SE B estiver assim
execute C
SE C falhar
tente D
Décadas de conhecimento operacional.
Um Operator tenta codificar conhecimento operacional específico usando o modelo de controllers e reconciliação do Kubernetes.
Simplificando:
Conhecimento operacional
|
v
código
|
v
Operator
|
v
observa → decide → reconcilia
É como se parte do runbook ganhasse vida.
Não elimina o especialista.
Muda o lugar onde parte do conhecimento dele vive.
28. CI/CD: ninguém deveria levar o deploy num disquete
O próximo passo natural é automação.
Temos:
Código
|
Git
|
Build
|
Teste
|
Imagem
|
Registry
|
Deploy
|
Kubernetes
Entramos no território de CI/CD.
E depois aparece GitOps.
Em vez de alguém alterar manualmente produção:
OPERADOR
|
kubectl
|
PRODUÇÃO
podemos trabalhar com um modelo no qual o Git representa o estado desejado relevante:
Developer
|
v
Git
|
Pull Request
|
Review
|
v
GitOps Controller
|
v
Cluster
Isso melhora possibilidades de:
rastreabilidade;
auditoria;
revisão;
versionamento;
recuperação;
consistência.
Mas lembre-se:
automatizar processo ruim produz desastre em velocidade industrial.
29. O que aquele roadmap deveria mostrar antes do Kubernetes
Aqui está minha principal crítica à figura.
Eu colocaria uma Fase Zero:
FASE ZERO
Linux
|
processos
|
filesystem
|
CPU/memória
|
networking
|
TCP/IP
|
DNS
|
HTTP
|
TLS
|
containers
|
images
|
runtime
|
KUBERNETES
Por quê?
Porque Kubernetes não aboliu o sistema operacional.
Nem aboliu rede.
Nem DNS.
Especialmente DNS.
Existe um antigo espírito maligno vagando pelos datacenters dizendo:
“It's always DNS.”
Quando você acha que não é DNS, eventualmente descobre que era DNS usando bigode falso.
30. Networking merece uma fase própria
Eu ampliaria o roadmap para incluir profundamente:
IP
CIDR
TCP
UDP
DNS
NAT
routing
TLS
Load Balancing
ClusterIP
NodePort
LoadBalancer
Ingress
CNI
NetworkPolicy
Porque um dos incidentes mais frustrantes é:
Pod: Running
Application: Healthy
Service: Exists
Usuário: NÃO FUNCIONA.
Então começa a expedição arqueológica.
31. Segurança de supply chain também precisa entrar
Em 2026 não basta perguntar:
“A imagem funciona?”
Precisamos perguntar:
Quem construiu essa imagem?
De onde veio?
Qual imagem base foi usada?
Possui vulnerabilidades?
Tem SBOM?
Foi assinada?
Quem pode publicar?
Foi adulterada?
Ou seja, o roadmap moderno precisa incluir:
scanning;
provenance;
SBOM;
assinatura;
admission policies;
least privilege;
gestão de secrets;
identidade de workloads;
atualização segura.
O container é conveniente justamente porque carrega muita coisa consigo.
E tudo aquilo que carregamos conosco também pode carregar problemas.
32. E o mainframe no meio dessa galáxia?
Aqui existe uma oportunidade fantástica para o COBOLzeiro.
Não pense:
Kubernetes
VERSUS
Mainframe
Pense:
INTERNET
|
KUBERNETES
|
APIs / serviços
|
+---------+---------+
| |
CLOUD MAINFRAME
|
+-------+-------+
| | |
CICS IMS Db2
|
COBOL
Kubernetes não precisa destruir o mainframe para justificar sua existência.
Um banco pode perfeitamente ter sistemas transacionais críticos em IBM Z enquanto utiliza Kubernetes para APIs, integração, canais digitais, serviços distribuídos, observabilidade e outras workloads.
O mundo corporativo real é híbrido.
A Millennium Falcon também não foi construída inteira pela mesma consultoria.
Provavelmente por isso funcionava.
33. O laboratório que eu faria para um COBOLzeiro
Aqui está o caminho prático.
Não faça 25 tutoriais desconectados.
Construa uma aplicação e faça-a evoluir.
Chamaremos:
BELLACOSA INTERGALACTIC BANK
Versão 1:
Frontend
Versão 2:
Frontend
|
Backend
Versão 3:
Frontend
|
Service
|
Backend
Versão 4:
Ingress
|
Frontend
|
Service
|
Backend
|
Database
Depois acrescente:
ConfigMap
Secrets
PVC
Requests
Limits
Probes
RBAC
NetworkPolicy
Monitoring
Logging
Depois:
CI/CD
Depois:
GitOps
E somente então:
Helm
Operators
CRDs
Não tente aprender a galáxia inteira antes de visitar a Lua.
34. Agora destrua tudo
Esta é a etapa que falta em muitos cursos.
Faça o Pod morrer.
kubectl delete pod ...
Observe o que acontece.
Coloque memória insuficiente.
Quebre uma configuração.
Use uma imagem inexistente.
Quebre uma readiness probe.
Remova uma permissão.
Altere uma NetworkPolicy.
Crie problema de storage.
Observe:
Pending
ImagePullBackOff
CrashLoopBackOff
OOMKilled
Forbidden
Readiness probe failed
Para cada incidente pergunte:
O QUE aconteceu?
POR QUE aconteceu?
QUAL componente percebeu?
QUAL estado era desejado?
QUAL estado existia?
QUEM tentou reconciliar?
ONDE encontro evidência?
COMO evitar novamente?
Esse exercício ensina dez vezes mais do que decorar cinquenta comandos.
35. O COBOLzeiro possui uma vantagem escondida
O programador COBOL iniciante talvez olhe Kubernetes e pense que está começando do zero.
Não está.
Se ele está aprendendo o ecossistema mainframe simultaneamente, já está entrando em contato com perguntas universais:
Como programas são executados?
Como recursos são alocados?
Como identidade funciona?
Como permissões são verificadas?
Como dados persistem?
Como jobs são agendados?
Como falhas são diagnosticadas?
Como mudanças chegam à produção?
Como recuperamos alguma coisa que quebrou?
Essas perguntas atravessaram gerações de computadores.
As respostas mudaram.
As perguntas continuam surpreendentemente parecidas.
36. A tabela de tradução intergaláctica
Não como equivalência técnica, mas como pontes mentais:
| Universo Mainframe | Universo Kubernetes | Ideia em comum |
|---|
| JES/scheduling | Scheduler/Jobs | execução organizada de workloads |
| JCL/parâmetros | manifests/configuração | declarar como executar |
| PROC | templates/Helm | reutilização |
| RACF | RBAC | autorização |
| WLM | requests/limits/scheduling | gestão de recursos |
| Started Tasks | serviços/workloads contínuas | processos duradouros |
| Scheduler batch | CronJob | execução periódica |
| datasets/storage | PV/PVC | persistência |
| Sysplex/HA | cluster/replicas | disponibilidade |
| SMF/RMF/logs | metrics/logs/traces | observabilidade |
| Runbook | Operator | conhecimento operacional |
Novamente:
não são equivalentes.
Essa tabela é mapa turístico, não especificação de arquitetura.
Se você tentar usar um mapa turístico para fazer cirurgia, o resultado será digno dos Vogons.
37. Do iniciante ao arquiteto
Existe uma progressão interessante.
Nível 1
O aluno pergunta:
“Como crio um Pod?”
Nível 2
Pergunta:
“Como faço três réplicas?”
Nível 3
Pergunta:
“Por que esse Pod morreu?”
Nível 4
Pergunta:
“Por que ele continua morrendo?”
Nível 5
Pergunta:
“Por que nossa arquitetura permitiu que a morte desse Pod afetasse usuários?”
Nível 6
Pergunta:
“Como eliminamos essa classe inteira de falhas?”
Essa é a transformação.
COMANDO
↓
OBJETO
↓
PLATAFORMA
↓
OPERAÇÃO
↓
ARQUITETURA
↓
ENGENHARIA DE RESILIÊNCIA
38. Easter Egg: Kubernetes e o número 42
No Guia do Mochileiro das Galáxias, a resposta para a Grande Questão da Vida, do Universo e Tudo Mais é:
42
Depois descobriram que ninguém sabia exatamente qual era a pergunta.
Kubernetes possui uma versão corporativa disso.
O arquiteto pergunta:
— Quantas réplicas precisamos?
Consultor:
— Três.
— Por quê?
— Alta disponibilidade.
— Baseado em qual cálculo?
— ...
— Tráfego?
— ...
— SLO?
— ...
— capacidade?
— ...
— histórico de falhas?
— ...
— teste de carga?
— ...
Três virou o 42 da arquitetura cloud-native.
😆
A lição é excelente:
uma resposta tecnicamente plausível sem a pergunta correta continua sendo apenas uma resposta procurando uma justificativa.
39. Outra curiosidade: Kubernetes significa timoneiro
O nome vem do grego e remete à ideia de timoneiro/piloto.
Daí também o famoso leme no logotipo.
E isso é poeticamente perfeito.
Kubernetes não é o navio.
Não é a carga.
Não é o oceano.
Ele ajuda a conduzir a embarcação.
Só existe um detalhe que nenhum tutorial coloca em letras suficientemente grandes:
você ainda precisa saber navegar.
Kubernetes não elimina a necessidade de conhecer Linux, redes, storage, segurança, aplicações e sistemas distribuídos.
Na realidade, em ambientes complexos ele pode exigir que você compreenda um pouco de todos eles simultaneamente.
40. O segredo final do roadmap
A imagem original termina aproximadamente com a ideia:
consistência + prática = especialista Kubernetes.
Eu acrescentaria algumas variáveis:
TEORIA
+
PRÁTICA
+
ERRO
+
OBSERVAÇÃO
+
TROUBLESHOOTING
+
DOCUMENTAÇÃO
+
CURIOSIDADE
+
INCIDENTES
+
CAFÉ
=
EXPERIÊNCIA
Principalmente os erros.
Porque executar:
kubectl get pods
é fácil.
Interpretar:
NAME READY STATUS
app-7d98 0/1 CrashLoopBackOff
é outra história.
E descobrir que o Pod não era a causa, que a aplicação estava falhando porque não conseguia alcançar uma dependência, que a dependência estava inacessível por causa de uma alteração de rede introduzida no deploy anterior...
Aí temos engenharia.
☕ Epílogo — O COBOLzeiro pega sua toalha
Nosso programador começou a viagem olhando para um roadmap colorido e pensando:
“Pod? Helm? Ingress? CRD? Operator? Eu só queria aprender Kubernetes.”
Agora ele sabe que Kubernetes não é uma coleção de palavras estranhas.
É uma resposta moderna para um conjunto de problemas profundamente antigos:
executar, distribuir, controlar, proteger, observar, recuperar e evoluir software.
O mainframe resolveu muitos desses problemas dentro de seu próprio universo durante décadas.
Unix resolveu outros.
Cloud resolveu outros.
Containers mudaram novamente a unidade de distribuição.
Kubernetes apareceu para coordenar esse novo zoológico.
E talvez essa seja a maior lição para um programador COBOL entrando no mundo cloud-native:
não jogue fora aquilo que você aprendeu.
Traduza.
Quando encontrar RBAC, lembre-se das perguntas que RACF ensinou a fazer.
Quando encontrar requests e limits, pense nas questões que WLM levanta.
Quando encontrar Jobs, recorde o mundo batch.
Quando encontrar observabilidade, pense em RMF, SMF, logs e diagnóstico.
Quando encontrar Operators, pense no velho runbook do especialista que sabia exatamente o que fazer quando determinada luz vermelha acendia.
Não porque essas tecnologias sejam iguais.
Mas porque a história da computação é cheia de novas respostas para perguntas antigas.
E algum dia, provavelmente às 03:17 da manhã, você encontrará isto:
CrashLoopBackOff
O jovem aprendiz perguntará:
— Mestre, qual comando resolve isso?
Você tomará um gole de café, olhará calmamente para o terminal e responderá:
— Nenhum. Primeiro precisamos descobrir o que aconteceu.
Nesse instante terá ocorrido algo muito mais importante que aprender Kubernetes.
Você terá aprendido a pensar como alguém de produção.
E, como diria o Guia do Mochileiro das Galáxias, enquanto o cluster inteiro estiver pegando fogo:
+---------------------------------------+
| |
| NÃO ENTRE EM PÂNICO |
| |
| kubectl get events |
| |
| E LEVE UMA TOALHA |
| |
+---------------------------------------+
☕🚀
Bem-vindo ao Kubernetes, COBOLzeiro.
A galáxia continua distribuída, eventualmente consistente, estranhamente documentada e, por algum motivo que ninguém conseguiu explicar satisfatoriamente, ainda depende de DNS.
