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:

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:

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:

RBAC;
criptografia em repouso;
proteção do etcd;
controle de Service Accounts;
secret managers;
rotação;
auditoria;
mínimo privilégio.

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 é:

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.

Translate

terça-feira, 11 de agosto de 2026