 |
| Bellacosa Mainframe e a introducao ao kubernetes no mundo cobol |
☕ Um Café no Bellacosa Mainframe
Kubernetes, COBOL e o Guia do Mochileiro das Galáxias para quem saiu do JES2 e encontrou um Pod
🚀 Pods, Deployments, Services, YAML, containers, Scheduler, Control Plane, storage, autorrecuperação e a perturbadora descoberta de que o universo 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 desaparece antes do café esfriar
Existe uma frase que deveria estar escrita em letras grandes na entrada de qualquer curso de Kubernetes:
NÃO ENTRE EM PÂNICO.
Ela deveria aparecer imediatamente acima de outra:
E NÃO TENTE DECORAR O YAML.
O jovem programador COBOL, entretanto, normalmente ignora ambas.
Ele acabou de sobreviver ao primeiro encontro com IDENTIFICATION DIVISION, descobriu que PIC 9(7)V99 COMP-3 não é uma coordenada intergaláctica, conseguiu executar seu primeiro JCL sem receber um JCL ERROR e começa a acreditar que finalmente compreendeu o universo.
Então alguém aparece no corredor e pergunta:
— Você conhece Kubernetes?
O programador responde:
— Um pouco.
Essa resposta, como inúmeras decisões tomadas na história da humanidade, será lamentada posteriormente.
Quinze minutos depois ele estará olhando para alguma coisa assim:
apiVersion: apps/v1
kind: Deployment
metadata:
name: payment-api
spec:
replicas: 3
selector:
matchLabels:
app: payment
E começa a suspeitar que foi sequestrado por extraterrestres.
Deployment.
ReplicaSet.
Pod.
Service.
Ingress.
Node.
Cluster.
Namespace.
ConfigMap.
Secret.
PersistentVolumeClaim.
DaemonSet.
StatefulSet.
Scheduler.
kubelet.
etcd.
O sujeito olha para aquilo e pensa:
“Eu só queria executar um programa.”
Bem-vindo ao Kubernetes.
Pegue sua toalha.
Prepare o café.
E não entre em pânico.
🌌 Capítulo 1 — Afinal, que diabo é Kubernetes?
O material que iniciou nossa viagem apresenta Kubernetes como uma plataforma open source destinada a automatizar implantação, dimensionamento, gerenciamento e operação de aplicações em contêineres.
A definição está correta.
Mas é daquelas definições tecnicamente corretas que escondem justamente a parte mais interessante.
É como definir um mainframe dizendo:
“É um computador utilizado para executar programas.”
Também está correto.
Só não ajuda muito.
Kubernetes pode ser entendido de forma mais poderosa:
Kubernetes é um sistema distribuído que observa continuamente o mundo real e tenta fazê-lo coincidir com o mundo que você declarou desejar.
Essa frase merece café.
Porque aqui está praticamente toda a filosofia Kubernetes.
Suponha que você diga:
Quero três instâncias da minha aplicação.
No Kubernetes você pode declarar:
replicas: 3
Agora imagine que estejam rodando:
Pod A
Pod B
Pod C
Perfeito.
Estado desejado:
3
Estado real:
3
O universo está em equilíbrio.
Até que o Pod B morre.
Agora temos:
Estado desejado = 3
Estado real = 2
O Kubernetes observa a diferença.
E basicamente diz:
“Segundo meus registros, deveriam existir três. Só estou vendo dois. Isso é inaceitável.”
Então cria outro.
Pod A
Pod C
Pod D
Voltamos a:
Desejado = 3
Real = 3
Pronto.
Você acabou de entender um dos conceitos mais importantes de Kubernetes:
reconciliation loop
ou:
loop de reconciliação
Kubernetes está continuamente perguntando:
O que deveria existir?
|
v
O que existe agora?
|
v
Existe diferença?
|
+---- não ---> continue observando
|
+---- sim ---> tente corrigir
Pense nisso como um operador extremamente obsessivo que possui uma planilha dizendo:
PRECISO DE 3 INSTÂNCIAS
e passa o dia inteiro contando.
— Uma.
— Duas.
— Três.
Tudo certo.
Cinco minutos depois:
— Uma.
— Duas.
CADÊ A TERCEIRA?!
E imediatamente chama alguém para providenciar outra.
🧠 Capítulo 2 — Kubernetes é declarativo, e isso muda tudo
No mundo tradicional de administração de sistemas, costumamos pensar proceduralmente.
Faça isto.
Depois aquilo.
Depois outra coisa.
Por exemplo:
1. crie servidor
2. instale sistema operacional
3. copie aplicação
4. configure arquivos
5. inicie processo
6. verifique processo
7. reinicie se necessário
Kubernetes tenta trabalhar de maneira diferente.
Você declara:
Quero três instâncias.
Quero esta imagem.
Quero esta configuração.
Quero esta quantidade de memória.
Quero este serviço.
E deixa a plataforma tentar produzir esse estado.
O próprio material destaca essa abordagem: você descreve os recursos através de manifestos e o sistema trabalha para manter o ambiente alinhado com o estado declarado.
Para um COBOLzeiro isso pode parecer estranho.
Mas não é completamente alienígena.
Pense em JCL.
Você escreve:
//ARQOUT DD DSN=EMPRESA.RELATORIO,
// DISP=(NEW,CATLG,DELETE),
// SPACE=(CYL,(5,2))
Você não está manualmente movimentando braços mecânicos dentro do storage.
Você está declarando requisitos.
O sistema interpreta.
Aloca.
Gerencia.
Kubernetes leva essa filosofia para workloads distribuídos.
🐳 Capítulo 3 — Antes de Kubernetes havia containers
Agora surge uma pergunta absolutamente fundamental:
Por que Kubernetes existe?
Porque containers ficaram tremendamente úteis.
Imagine uma aplicação tradicional que depende de:
Java versão X
biblioteca Y
arquivo Z
variáveis ambientais
configurações específicas
Na máquina do desenvolvedor funciona.
Em homologação explode.
Em produção surge o clássico diálogo:
— Mas na minha máquina funciona.
Ao que o operador responde:
— Excelente. Então vamos colocar sua máquina no data center.
Containers surgiram como uma maneira extremamente prática de empacotar aplicação e suas dependências.
Simplificando:
Aplicação
+
Dependências
+
Configuração de runtime
=
Imagem de container
A partir dela podemos iniciar containers.
Mas aí aparece o problema.
Um container é fácil.
Dez containers são administráveis.
Cem começam a ficar interessantes.
Mil começam a pedir café.
Dez mil fazem você procurar emprego.
Então surgem perguntas:
Em qual servidor cada container roda?
E se o servidor morrer?
Como substituir automaticamente?
Como distribuir tráfego?
Como atualizar versões?
Como saber quais instâncias estão saudáveis?
Como aumentar capacidade?
Como armazenar dados?
Como controlar configuração?
Como proteger credenciais?
Eis o território do Kubernetes.
📦 Capítulo 4 — Container não é Pod
Essa é uma das primeiras armadilhas do viajante.
O material corretamente apresenta o Pod como menor unidade de implantação do Kubernetes, capaz de conter um ou mais containers.
Então:
CONTAINER != POD
Um Pod é uma abstração.
Imagine:
+---------------------------+
| POD |
| |
| +-------------------+ |
| | Container App | |
| +-------------------+ |
| |
| +-------------------+ |
| | Container Sidecar | |
| +-------------------+ |
| |
+---------------------------+
Na maioria dos casos simples:
1 Pod
|
+-- 1 container principal
Mas podem existir múltiplos containers fortemente relacionados.
Por exemplo:
Aplicação
+
proxy auxiliar
ou:
Aplicação
+
componente auxiliar de observabilidade
Esses containers compartilham elementos do ambiente do Pod.
A ideia importante é:
Kubernetes administra Pods.
Você pode até imaginar o container como o programa e o Pod como sua pequena unidade operacional.
Não é uma equivalência perfeita com nada do mainframe, mas ajuda a construir o mapa mental.
💀 Capítulo 5 — Kubernetes não ama seus servidores
Aqui ocorre um choque cultural particularmente divertido.
Administradores tradicionais costumavam dar nomes carinhosos às máquinas.
WEBPROD01
WEBPROD02
DBSERVER03
E depois surgia aquele servidor lendário.
Você pergunta:
— Podemos reiniciar WEBPROD01?
A sala fica silenciosa.
O sysadmin mais velho começa a suar.
— Não sabemos.
— Como assim?
— Ele está rodando desde 2014.
— Então reinicie.
— Existem coisas que o homem não deveria tentar compreender.
No Kubernetes, a filosofia tende a ser diferente.
Pods são efêmeros.
Se um Pod desaparece, você não deveria necessariamente organizar uma cerimônia fúnebre.
Você substitui.
Pod XPTO morreu.
Kubernetes:
Quantos deveriam existir?
Você:
5.
Kubernetes:
Quantos existem?
Você:
4.
Kubernetes:
Então criarei outro.
Fim.
Nenhuma lágrima.
Nenhum minuto de silêncio.
Nenhum administrador abraçando o rack.
🏗️ Capítulo 6 — Deployment: pare de criar Pods com as próprias mãos
Você pode criar diretamente um Pod.
Mas normalmente aplicações são administradas por objetos de nível superior.
Um dos principais é o:
Deployment
Imagine:
Deployment
|
v
ReplicaSet
|
+---- Pod
+---- Pod
+---- Pod
O material apresenta ReplicaSets como responsáveis por garantir determinado número de réplicas e Deployments como responsáveis por administrar implantações e atualizações.
Declare:
replicas: 3
Você está dizendo:
“Universo, quero três.”
Um Pod morre.
ReplicaSet percebe:
Desejado: 3
Atual: 2
Cria outro.
Mas Deployment também ajuda em algo importantíssimo:
atualizações.
Imagine que você possui:
versão 1
e deseja implantar:
versão 2
Em vez de executar:
PARA TUDO
ATUALIZA TUDO
REZA
LIGA TUDO
podemos fazer atualização gradual.
Essa lógica está por trás dos famosos:
rolling updates
Nova versão vai entrando enquanto a antiga vai saindo.
O objetivo é reduzir interrupção.
Naturalmente, como qualquer sysprog experiente sabe:
“Atualização sem parada” não significa “atualização sem risco”.
Kubernetes automatiza mecanismos.
Não revoga a Lei de Murphy.
🛰️ Capítulo 7 — O Scheduler é o agente de viagens dos Pods
Imagine que um novo Pod precisa executar.
Existem cinco Nodes.
Node A
Node B
Node C
Node D
Node E
Quem decide onde o bichinho vai morar?
O:
Scheduler
O artigo apresenta o Scheduler entre os principais componentes do antigo chamado “Master Node”.
Hoje é preferível falar:
CONTROL PLANE
em vez de simplesmente:
MASTER NODE
O Scheduler analisa possibilidades.
Por exemplo:
CPU disponível?
Memória suficiente?
Restrições?
Afinidade?
Taints?
Tolerations?
Topologia?
E decide:
Este Pod -> Node C
Para quem viveu mainframe:
— Bellacosa, isso lembra WLM!
Calma, jovem Padawan.
Não são equivalentes.
Mas enfrentam uma família semelhante de problemas.
No mainframe:
workload
|
v
classes / prioridades / recursos
|
v
execução
No Kubernetes:
Pod pendente
|
v
Scheduler
|
v
Node
A tecnologia muda.
A pergunta permanece:
Como distribuir trabalho sobre recursos limitados?
Os computadores passam décadas reinventando essa pergunta.
Só os acrônimos mudam.
🧙 Capítulo 8 — O Control Plane é a burocracia imperial
Para entender Kubernetes, imagine uma administração imperial intergaláctica extremamente eficiente.
Temos:
API Server
Scheduler
Controller Manager
etcd
O API Server é a porta de entrada.
Você executa:
kubectl apply -f deployment.yaml
Muitos iniciantes pensam:
kubectl = Kubernetes
Não.
kubectl é um cliente.
Conceitualmente:
kubectl
|
v
API Server
|
v
Universo Kubernetes
A API é extraordinariamente importante.
Porque quase tudo pode conversar com ela:
CI/CD
GitOps
Operators
automação
ferramentas administrativas
políticas
observabilidade
Isso explica por que Kubernetes não é simplesmente um “Docker grandão”.
É uma plataforma orientada por API.
📚 Capítulo 9 — etcd: o cartório onde o universo guarda sua memória
O etcd mantém dados importantes sobre o estado do cluster.
Imagine que Kubernetes possui um cartório.
Lá está registrado:
Deployment pagamento
replicas: 5
Service pagamento
porta: 8080
Configuração X
Configuração Y
O etcd participa da preservação daquilo que o cluster acredita que existe e deveria existir.
Portanto:
etcd morreu
não é exatamente uma frase que você gostaria de ouvir às 3h17 da manhã.
Especialmente se a próxima frase for:
— E o backup?
seguida por:
— Que backup?
Nesse momento até o Guia do Mochileiro recomendaria abandonar o planeta.
👷 Capítulo 10 — kubelet: o capataz de cada Node
Cada worker possui um agente chamado:
kubelet
O material o apresenta como responsável por administrar os containers e manter sua execução em conformidade com as especificações.
Imagine:
CONTROL PLANE
|
v
NODE
+-------------------+
| kubelet |
| runtime |
| Pod |
| Pod |
+-------------------+
O control plane decide.
O kubelet executa localmente parte desse desejo.
Ele verifica:
“Existem Pods que deveriam estar rodando aqui?”
E trabalha para garantir isso.
🌐 Capítulo 11 — Service: porque decorar IP de Pod é receita para enlouquecer
Hoje:
Pod A = 10.0.1.37
Amanhã ele morre.
Novo Pod:
Pod B = 10.0.8.91
Se todo cliente dependesse diretamente desses endereços, estaríamos construindo um castelo sobre areia movediça.
Então surge:
Service
O material descreve Services como abstrações responsáveis por permitir comunicação confiável entre Pods e proporcionar exposição e balanceamento de tráfego.
Em vez de:
Cliente -> IP do Pod
temos:
+--> Pod A
Cliente -> Service
+--> Pod B
+--> Pod C
Os Pods podem mudar.
O Service fornece identidade estável.
Isso é uma ideia fundamental.
Pods são descartáveis.
Services são pontos lógicos relativamente estáveis.
🚪 Capítulo 12 — E então aparecem Ingress e Gateway
Agora imagine que temos:
Internet
e precisamos encaminhar tráfego até aplicações dentro do cluster.
Uma arquitetura pode envolver:
Internet
|
Load Balancer
|
Ingress / Gateway
|
Service
|
Pods
Isso nos ensina algo importante:
Kubernetes não é uma caixa mágica que substitui DNS, firewall, load balancer, proxy e todas as camadas de networking da humanidade.
Quando alguém disser:
“Kubernetes faz load balancing.”
Pergunte imediatamente:
“Em qual camada?”
Você ficará instantaneamente 14% mais perigoso em reuniões técnicas.
💾 Capítulo 13 — Storage: o momento em que os Pods descobrem que existem consequências
Aplicações stateless combinam maravilhosamente com a filosofia:
morreu?
cria outra.
Mas imagine um banco.
Pod morre.
Você diz:
— Tudo bem, cria outro.
Banco responde:
— Excelente ideia. E meus dados?
Silêncio.
Agora chegamos a:
PersistentVolume
PersistentVolumeClaim
StorageClass
StatefulSet
O artigo explica que Kubernetes oferece volumes e mecanismos de persistência que permitem manter dados mesmo quando Pods são reiniciados ou reimplantados.
Podemos pensar:
Pod
|
v
PVC
|
v
PV
|
v
Storage
Por trás pode existir:
cloud disk
SAN
NFS
Ceph
storage corporativo
A aplicação solicita armazenamento.
A infraestrutura providencia.
🏛️ Capítulo 14 — StatefulSet: alguns cidadãos precisam de identidade
Para uma API web:
Pod A
Pod B
Pod C
podem ser quase equivalentes.
Mas existem aplicações onde identidade importa.
Bancos.
Clusters distribuídos.
Mensageria.
Sistemas que precisam de:
ordem
identidade
storage persistente
relações específicas
Então aparece:
StatefulSet
O nome já entrega:
Stateful
Estado importa.
Aqui Kubernetes começa a deixar de ser parque de diversões e vira arquitetura séria.
🔑 Capítulo 15 — ConfigMap e Secret
Um erro clássico:
password = "senha123"
dentro do código.
Outro:
URL_PRODUCAO
compilada na aplicação.
Kubernetes permite separar configuração da aplicação.
Temos:
ConfigMap
para configurações.
E:
Secret
para informações sensíveis.
O material destaca ambos como mecanismos de separação entre código, configuração e dados sensíveis.
Mas cuidado.
Secret não significa:
SEGREDO PROTEGIDO POR MAGIA ÉLFICA
Segurança real ainda exige:
RBAC
controle de privilégios
criptografia
proteção do etcd
auditoria
segregação
gestão de credenciais
Quem vem de RACF deveria sentir aqui um arrepio familiar.
A tecnologia muda.
O princípio permanece:
usuário ou workload deve possuir apenas os privilégios necessários.
Least privilege nunca saiu de moda.
Só ganhou novos logos.
🏥 Capítulo 16 — Está vivo? Está pronto? Ou apenas finge muito bem?
Imagine um processo executando.
Sistema operacional diz:
PID existente.
Ótimo.
Mas ele responde?
Talvez não.
Consegue acessar dependências?
Talvez não.
Está preparado para receber tráfego?
Talvez não.
Então Kubernetes trabalha com probes.
livenessProbe
readinessProbe
startupProbe
Três perguntas diferentes:
STARTUP:
Você conseguiu iniciar?
READINESS:
Você está pronto para trabalhar?
LIVENESS:
Você ainda está funcionando?
Essa diferença é lindíssima.
Porque:
processo existente não significa aplicação saudável.
Quem já passou horas olhando um CICS aparentemente “UP” enquanto alguma parte crítica estava mortalmente doente sabe exatamente do que estamos falando.
🩺 Capítulo 17 — Self-healing não é House M.D.
Kubernetes frequentemente é descrito como possuindo:
self-healing
Ou:
autorrecuperação
O texto também destaca recuperação automática diante de falhas de Pods ou máquinas.
Mas não imagine:
Kubernetes encontrou bug COBOL.
Kubernetes corrigiu regra de juros.
Kubernetes percebeu SQL errado.
Não.
Ele pode perceber:
processo morreu
Pod desapareceu
Node deixou de responder
probe falhou
réplicas estão abaixo do esperado
E reagir operacionalmente.
Porém se sua aplicação calcula:
R$ 10,00
quando deveria calcular:
R$ 1.000.000,00
Kubernetes pode executar o erro com extraordinária disponibilidade.
E escalá-lo horizontalmente.
Parabéns.
Você agora possui um bug altamente disponível.
🔥 Capítulo 18 — Kubernetes automatiza inclusive suas más decisões
Essa merece entrar no manual oficial.
Você declara:
replicas: 50
Kubernetes tenta fornecer 50.
Muito eficiente.
Agora imagine que a aplicação possua um erro fatal.
Kubernetes pode providenciar:
50 cópias
do erro fatal.
Cloud-native!
Esse é o paradoxo da automação:
Automação amplifica capacidade, não inteligência.
Ela acelera boas decisões.
E acelera estupidamente decisões ruins.
Por isso precisamos de:
testes
observabilidade
logs
métricas
traces
health checks
CI/CD
rollback
canary
políticas
controle de mudança
O velho mainframeiro sorri.
Porque novamente descobre que o futuro acabou reencontrando problemas que produção conhece há décadas.
🐳 Capítulo 19 — Docker não é Kubernetes
O artigo compara corretamente os papéis gerais:
Docker -> empacotamento/execução de containers
Kubernetes -> orquestração
Mas precisamos modernizar a interpretação.
Kubernetes não significa:
Kubernetes
|
Docker obrigatório
O ecossistema utiliza runtimes compatíveis com a Container Runtime Interface.
Um arranjo comum é:
Kubernetes
|
kubelet
|
CRI
|
containerd
|
containers
Então Docker e Kubernetes podem coexistir no seu aprendizado, mas Kubernetes não deve ser entendido simplesmente como:
“Docker distribuído.”
É outra camada de abstração.
📝 Capítulo 20 — YAML não é Kubernetes
Essa deveria estar estampada em canecas.
YAML != Kubernetes
YAML é sintaxe usada para representar objetos.
Veja:
apiVersion: apps/v1
kind: Deployment
metadata:
name: pagamento
A parte importante não é saber que depois de metadata: vêm dois espaços.
O importante é compreender:
O que é Deployment?
Por que existe?
Qual estado ele representa?
Quem observa esse estado?
Que outros objetos ele cria?
Memorizar YAML sem entender Kubernetes é como decorar JCL sem compreender dataset, step, DD, condição e execução.
Você aprende os símbolos.
Mas ainda não aprendeu o sistema.
🪐 Capítulo 21 — O fantástico universo dos objetos
Depois que você entende o modelo declarativo, os nomes começam a deixar de parecer uma convenção criada por alienígenas bêbados.
Pod
declara unidade executável.
Deployment
declara uma aplicação replicada e atualizável.
Service
declara uma identidade de rede.
ConfigMap
declara configuração.
Secret
declara informação sensível.
PVC
declara necessidade de armazenamento.
Job
declara trabalho que deve terminar.
CronJob
declara trabalho agendado.
StatefulSet
declara workload com identidade/estado.
DaemonSet
declara algo que deve existir em determinados Nodes, frequentemente um por Node.
Percebeu o padrão?
Tudo é:
declaração de intenção.
🔧 Capítulo 22 — Operator: quando você ensina Kubernetes a administrar seu sistema
Agora chegamos a uma das regiões mais interessantes da galáxia.
Kubernetes possui controllers.
Controllers observam estado e corrigem divergências.
Então alguém teve a ideia inevitável:
“E se eu criar meu próprio controller?”
Nasce o conceito de:
Operator
Imagine um banco fictício.
Você cria um recurso:
kind: BancoGalactico
spec:
replicas: 3
backup: diario
Naturalmente Kubernetes não nasce sabendo o que significa:
BancoGalactico
Mas você pode criar lógica que compreenda essa definição.
Então o Operator observa:
BancoGalactico
e executa procedimentos especializados.
A partir daí Kubernetes deixa de ser simplesmente um orquestrador.
Ele se transforma numa:
plataforma para construir plataformas.
👽 Capítulo 23 — O cluster não é simplesmente um grupo de servidores
O material define cluster como conjunto de máquinas físicas ou virtuais usadas para executar workloads Kubernetes.
Correto.
Mas existe uma interpretação melhor.
Cluster também é um domínio lógico de:
computação
rede
storage
políticas
identidade
scheduling
controle
Imagine:
CLUSTER
+---------------------------------------+
| |
| Control Plane |
| |
| Node A Node B Node C |
| Pods Pods Pods |
| |
| Services |
| Storage |
| Policies |
| Configurations |
| |
+---------------------------------------+
Você deixa de pensar:
Tenho 37 servidores.
e começa a pensar:
Tenho capacidade computacional administrada pelo cluster.
Essa mudança mental é poderosa.
🧮 Capítulo 24 — Requests, Limits e o dia em que todo mundo quis 64 GB
Em ambientes compartilhados aparece outra pergunta ancestral:
Quanto cada aplicação pode consumir?
Imagine vinte equipes declarando:
Minha aplicação precisa de tudo.
Kubernetes fornece mecanismos como:
requests
limits
Simplificando:
request = quantidade considerada necessária para scheduling
limit = teto permitido
Exemplo conceitual:
resources:
requests:
memory: "512Mi"
cpu: "250m"
limits:
memory: "1Gi"
cpu: "500m"
Isso começa a lembrar gestão de capacidade.
E novamente o COBOLzeiro veterano diz:
— Isso parece assunto de WLM.
Sim.
Continue seguindo o coelho branco.
📈 Capítulo 25 — Autoscaling: três não precisam continuar três
Inicialmente:
replicas: 3
Mas carga aumenta.
Talvez precisemos de:
6
Depois diminui:
2
Kubernetes possui mecanismos de autoscaling.
Então a infraestrutura começa a adaptar capacidade ao comportamento observado.
A ideia é sedutora:
Pouca carga -> menos recursos
Muita carga -> mais recursos
Mas novamente:
métricas ruins produzem decisões ruins.
Se seu indicador não representa corretamente pressão real sobre a aplicação, você pode automatizar oscilações, desperdício ou indisponibilidade.
Nenhum produto consegue escapar da regra universal:
GARBAGE IN
|
v
AUTOMATION
|
v
GARBAGE AT SCALE
🧭 Capítulo 26 — Como eu ensinaria Kubernetes para um programador COBOL iniciante
Não começaria com Helm.
Não começaria com service mesh.
Não começaria com Istio.
Não começaria com GitOps.
E certamente não jogaria 800 páginas de YAML na cabeça da vítima.
Eu seguiria esta trilha:
Passo 1 — Entenda processo
Saiba o que significa um programa executando.
Passo 2 — Entenda container
Aplicação isolada com dependências empacotadas.
Passo 3 — Entenda imagem
Modelo imutável usado para criar containers.
Passo 4 — Execute container localmente
Antes de Kubernetes.
Passo 5 — Aprenda Pod
A menor unidade Kubernetes.
Passo 6 — Aprenda Deployment
Pare de tratar Pods como animais de estimação.
Passo 7 — Aprenda Service
Descubra como encontrar aplicações efêmeras.
Passo 8 — ConfigMap e Secret
Separe configuração de aplicação.
Passo 9 — Volumes
Descubra que dados não podem desaparecer simplesmente porque um Pod morreu.
Passo 10 — Requests e Limits
Aprenda capacidade.
Passo 11 — Probes
Aprenda saúde operacional.
Passo 12 — Scheduler
Descubra como workload encontra Node.
Passo 13 — Control Plane
Entenda quem governa a galáxia.
Passo 14 — Networking
Agora você possui contexto suficiente para sofrer adequadamente.
Passo 15 — Segurança
RBAC, ServiceAccounts, Secrets, políticas.
Passo 16 — Observabilidade
Logs, métricas, tracing.
Passo 17 — StatefulSet e Jobs
Comece a trabalhar com workloads especializados.
Passo 18 — GitOps, Operators e ecossistema
Somente depois disso entre nos níveis avançados.
🧪 Capítulo 27 — Laboratório do Mochileiro: sua primeira viagem
Imagine uma aplicação:
hello-cobol
Você cria Deployment com:
replicas: 3
Depois:
kubectl get pods
E encontra:
hello-abc
hello-def
hello-ghi
Agora delete um:
kubectl delete pod hello-def
Espere alguns segundos.
Execute novamente:
kubectl get pods
Você verá outro surgindo.
Esse exercício vale mais do que vinte slides.
Porque seu cérebro finalmente percebe:
“Ah! Eu não mandei Kubernetes executar três Pods uma vez. Eu disse que três deveriam existir.”
BINGO.
Esse é o momento Jedi.
🎒 Easter Egg nº 1 — O nome Kubernetes
Kubernetes vem de uma palavra grega associada ao conceito de:
timoneiro
piloto
governante
Daí o famoso símbolo do leme.
É uma escolha perfeita.
Containers são workloads.
Nodes são recursos.
Kubernetes segura o leme.
Ou pelo menos tenta.
Porque ocasionalmente alguém executa:
kubectl delete namespace production
e então nem Poseidon poderá ajudá-lo.
🧙 Easter Egg nº 2 — Kubernetes também é conhecido como K8s
Você verá frequentemente:
K8s
Por quê?
Kubernetes possui:
K + 8 letras + s
As oito letras entre K e s foram comprimidas.
Da mesma família:
internationalization -> i18n
localization -> l10n
Economia de caracteres.
Talvez porque depois de escrever manifestos YAML durante três horas qualquer economia começa a parecer importante.
🐛 Easter Egg nº 3 — O artigo trouxe PHP para Kubernetes
No final do material original surge uma frase curiosa:
“Embora seja possível aprender PHP por conta própria...”
PHP aparentemente atravessou um wormhole editorial.
Logo depois o texto ainda fala em compreensão profunda da “linguagem”.
Só que Kubernetes não é linguagem.
Provavelmente o texto nasceu de algum template reaproveitado.
Excelente lembrete de produção:
copy/paste é o ancestral comum de metade dos bugs do planeta.
COBOLzeiros conhecem muito bem essa criatura.
🏦 Capítulo 28 — Kubernetes encontra COBOL
Agora chegamos à pergunta realmente divertida.
COBOL vai rodar em Kubernetes?
Pode.
Mas essa não é necessariamente a pergunta mais importante.
O ponto mais interessante é:
Como sistemas legados podem participar de uma arquitetura onde Kubernetes administra componentes modernos?
Imagine:
Mobile
|
API Gateway
|
Kubernetes
|
Microserviço
|
API
|
z/OS Connect
|
COBOL
|
Db2
Nesse desenho:
COBOL continua fazendo aquilo que faz extraordinariamente bem:
transação
regra de negócio
processamento financeiro
integração com dados críticos
Enquanto Kubernetes administra:
APIs
camadas web
serviços modernos
integrações
workloads distribuídos
Não precisamos transformar cada programa COBOL em um Pod para que Kubernetes seja relevante ao mundo mainframe.
Essa é uma distinção importante.
Modernização não significa:
DELETE FROM MAINFRAME;
Modernização pode significar:
INTEGRATE MAINFRAME WITH MODERN ECOSYSTEM;
🏰 Capítulo 29 — Kubernetes não matou o mainframe
Eis uma história corporativa clássica.
1995:
“Mainframe morreu.”
2005:
“Mainframe morreu.”
2015:
“Agora morreu.”
2026:
“Tem alguém que saiba COBOL?”
Enquanto isso, no universo distribuído:
Docker
Kubernetes
Kafka
Redis
Service Mesh
Observability
GitOps
API Gateway
Zero Trust
O futuro não substituiu complexidade.
Ele a redistribuiu.
Às vezes elegantemente.
Às vezes em 97 arquivos YAML.
☕ Capítulo 30 — A grande revelação do velho sysprog
Depois de algumas semanas estudando Kubernetes, nosso jovem COBOLzeiro procura o sysprog.
— Mestre, descobri algo.
O sysprog larga o café.
— Fale.
— Kubernetes possui Scheduler.
— Sim.
— Controle de recursos.
— Sim.
— Autorização.
— Sim.
— Alta disponibilidade.
— Sim.
— Logs.
— Sim.
— Automação.
— Sim.
— Storage.
— Sim.
— Workload management.
— De certa forma.
— Atualizações controladas.
— Sim.
— Recuperação automática.
— Sim.
— Então...
O jovem hesita.
— O pessoal de cloud passou décadas recriando problemas que o mainframe já tinha?
O sysprog sorri.
— Agora você está aprendendo arquitetura.
Essa é a grande lição.
Não significa que:
Kubernetes = mainframe
Nem remotamente.
Significa que sistemas grandes encontram problemas universais:
capacidade
concorrência
isolamento
scheduling
identidade
segurança
storage
recuperação
configuração
observabilidade
automação
A tecnologia muda.
Os problemas fundamentais continuam sentados no mesmo bar.
🌌 Epílogo — A resposta para Kubernetes, a vida, o universo e tudo mais
No Guia do Mochileiro das Galáxias, a resposta para a grande questão da vida, do universo e tudo mais é:
42
No Kubernetes, talvez a resposta seja:
estado desejado
Porque quase tudo começa daí.
Você declara:
Quero três Pods.
Quero determinada imagem.
Quero determinada configuração.
Quero determinado storage.
Quero determinado endpoint.
Quero determinadas políticas.
O cluster observa:
O que existe?
Compara:
O que deveria existir?
E trabalha continuamente para reduzir a diferença.
Por isso o fluxo mental definitivo pode ser desenhado assim:
DECLARAÇÃO
|
v
ESTADO DESEJADO
|
v
API SERVER
|
v
etcd
|
+-------+-------+
| |
Controllers Scheduler
| |
+-------+-------+
|
v
Nodes
|
kubelet
|
v
Pods
|
v
ESTADO REAL
|
v
OBSERVAÇÃO
|
+-------------------+
|
v
ESTÁ DIFERENTE?
/ \
não sim
| |
continue reconciliar
Se você entendeu esse desenho, Kubernetes deixou de ser coleção de palavras estranhas.
Pod não é mais um nome engraçado.
Deployment não é mais um YAML gigante.
Service não é simplesmente um IP.
Scheduler não é magia.
Controller não é mistério.
Kubernetes começa a revelar aquilo que realmente é:
um enorme sistema distribuído de controle, baseado em APIs e declarações de intenção, construído para manter workloads funcionando num mundo onde servidores falham, aplicações mudam, demanda oscila, containers desaparecem e alguém inevitavelmente faz deploy numa sexta-feira às 17h47.
E essa última pessoa deverá ser proibida de tocar em produção.
Não por Kubernetes.
Por um sysprog veterano armado com uma caneca de café.
☕ Registro final do Bellacosa Mainframe
Se você vem de COBOL, não cometa o erro de olhar Kubernetes pensando:
“Isso é coisa totalmente diferente daquilo que conheço.”
Olhe novamente.
Por baixo dos logos coloridos existem velhos problemas conhecidos:
Quem executa?
Onde executa?
Quanto pode consumir?
Quem pode acessar?
O que acontece quando falha?
Como encontrar o serviço?
Como manter estado?
Como atualizar?
Como observar?
Como recuperar?
Essas perguntas sobreviveram ao batch, ao CICS, ao cliente-servidor, à web, aos containers e sobreviverão ao próximo paradigma.
Aprender Kubernetes, portanto, não é decorar uma tecnologia.
É aprender uma nova maneira de responder antigas perguntas da computação.
E talvez seja justamente por isso que um programador COBOL possui uma vantagem inesperada.
Ele já conhece o planeta.
Só precisa aprender os nomes das novas criaturas.
Pegue sua toalha.
Abra o terminal.
Prepare o café.
Digite:
kubectl get pods
E lembre-se da primeira regra do administrador intergaláctico de infraestrutura:
NÃO ENTRE EM PÂNICO.
A segunda?
NUNCA FAÇA kubectl delete ANTES DE LER DUAS VEZES O NOME DO NAMESPACE.
☕🚀🖥️
Sem comentários:
Enviar um comentário