 |
| Bellacosa Mainframe e o kubernetes sem misterios |
☕ Um Café no Bellacosa Mainframe
Kubernetes sem Mistérios
O Guia Definitivo do Programador COBOL Padawan para Entender a Plataforma que Virou o "z/OS da Nuvem"
"A tecnologia muda. Os princípios permanecem."
— Adaptado da filosofia vulcana do Sr. Spock
Introdução — Quando o mundo saiu do CPD
Se você começou sua carreira em um CPD tradicional, talvez tenha ouvido frases como:
"O programa está em produção."
"Vamos fazer o deploy no fim de semana."
"Precisamos subir outra LPAR."
"Chama o operador."
"O Sysprog já autorizou."
Durante décadas, essa foi a realidade do desenvolvimento corporativo.
Enquanto isso, um novo mundo surgia.
Primeiro vieram os servidores Linux.
Depois as máquinas virtuais.
Depois os containers.
E finalmente apareceu uma tecnologia que mudou completamente a forma de executar aplicações:
Kubernetes.
Hoje praticamente toda grande empresa utiliza Kubernetes em algum lugar.
Google.
Amazon.
Netflix.
Spotify.
Nubank.
Mercado Livre.
IBM.
Red Hat.
Microsoft.
Oracle.
SAP.
Mas existe uma curiosidade interessante.
Embora muitos pensem que Kubernetes representa uma revolução completa, para quem trabalha há anos com IBM Z, muita coisa parece incrivelmente familiar.
Na verdade, boa parte dos conceitos que hoje são chamados de "Cloud Native" já existiam no universo mainframe, apenas com nomes diferentes.
Hoje vamos fazer exatamente essa viagem.
Pegue sua caneca de café.
Abra o ISPF...
...ou o VS Code.
E vamos descobrir por que Kubernetes talvez seja o primo moderno do z/OS.
O que é Kubernetes?
A resposta rápida costuma ser:
"É um orquestrador de containers."
Correto.
Mas extremamente incompleto.
Uma definição muito melhor seria:
Kubernetes é um Sistema Operacional Distribuído capaz de administrar milhares de aplicações executando simultaneamente em centenas ou milhares de servidores.
Perceba a palavra importante:
administrar.
Ele não executa apenas containers.
Ele administra:
disponibilidade
escalabilidade
armazenamento
rede
segurança
monitoramento
atualização
recuperação
balanceamento
automação
Ou seja...
Ele faz exatamente aquilo que o z/OS faz há décadas.
A evolução da infraestrutura
Vamos visualizar essa evolução.
Era 1 — Servidor físico
Hardware
↓
Sistema Operacional
↓
Aplicação
Muito simples.
Muito limitado.
Era 2 — Virtualização
Servidor
↓
VMware
↓
Máquinas Virtuais
↓
Aplicações
Agora era possível executar diversos servidores no mesmo hardware.
Era 3 — Docker
Em vez de criar máquinas completas...
Criamos containers.
Muito mais leves.
Muito mais rápidos.
Era 4 — Kubernetes
Agora imagine:
50 servidores
↓
20.000 containers
↓
5.000 aplicações
↓
Tudo funcionando sozinho.
É exatamente isso que Kubernetes faz.
Easter Egg nº 1 ☕
Se o Docker é como um apartamento...
O Kubernetes é o síndico.
Ele decide:
onde cada morador ficará
quem troca de prédio
quem recebe visitas
quem ganha mais espaço
quem precisa sair
O container apenas mora.
Quem administra é o Kubernetes.
O verdadeiro problema
Imagine uma empresa moderna.
Ela possui:
600 microsserviços
1.200 APIs
300 bancos
milhares de usuários
Agora imagine que um servidor falha.
Quem:
percebe?
reinicia?
move aplicações?
redistribui carga?
atualiza DNS?
mantém disponibilidade?
Fazer isso manualmente seria impossível.
Foi exatamente para isso que Kubernetes nasceu.
Cluster — O universo inteiro
O Cluster representa todo o ambiente Kubernetes.
Pode possuir:
10 servidores
100 servidores
1.000 servidores
10.000 servidores
Tudo pertence ao mesmo ambiente.
No IBM Z...
Pense em um grande Sysplex.
Node — O servidor
Cada servidor chama-se Node.
Pode ser:
físico
virtual
cloud
Analogia:
No mainframe seria parecido com uma LPAR.
Cada Node executa dezenas ou centenas de Pods.
Pod — A menor unidade
Aqui existe uma confusão comum.
Muitos acreditam que Kubernetes administra containers.
Na verdade...
Ele administra Pods.
Um Pod pode conter:
Container principal
+
Container Sidecar
+
Volumes
+
Rede
Exemplo:
Aplicação Java
+
Agente OpenTelemetry
+
Coletor de Logs
Tudo no mesmo Pod.
Deployment
Imagine dizer ao Kubernetes:
Quero exatamente
5 Pods.
Ele responde:
"Sem problemas."
Se um morrer...
Outro nasce imediatamente.
Sem operador.
Sem intervenção.
Sem JCL.
Sem abrir chamado.
ReplicaSet
ReplicaSet é o guarda-costas do Deployment.
Sua única missão é garantir que o número correto de Pods esteja sempre disponível.
Se deveria haver:
8 Pods
mas existem apenas:
7
Ele cria automaticamente o oitavo.
Service
Os Pods vivem pouco.
Eles nascem.
Morrem.
Mudam de IP.
Isso seria um pesadelo para aplicações.
Então surge o Service.
Ele fornece um endereço permanente.
db-service
api-service
payment-service
Não importa onde o Pod esteja.
O nome continua igual.
Control Plane — O cérebro
Se o Cluster fosse um corpo humano...
O Control Plane seria o cérebro.
Ele contém diversos componentes.
API Server
Tudo passa por ele.
Quando digitamos:
kubectl apply
Na realidade estamos enviando chamadas REST para o API Server.
Ele decide:
aceitar
validar
armazenar
etcd
Este talvez seja o componente mais importante.
O etcd é um banco chave-valor extremamente rápido.
Ele guarda:
Pods
Nodes
ConfigMaps
Secrets
Deployments
Namespaces
Services
Em outras palavras...
Guarda o estado inteiro do Cluster.
Perder o etcd equivale a perder o "catálogo mestre" do ambiente. Por isso, backup e alta disponibilidade do etcd são fundamentais.
Scheduler
Imagine um aeroporto.
O controlador decide em qual pista cada avião pousará.
O Scheduler faz exatamente isso.
Ele escolhe:
qual Node possui CPU
qual possui memória
qual atende afinidade
qual respeita políticas
Controller Manager
Existe um conceito muito elegante chamado:
Desired State
Estado desejado.
Você informa:
Desejo:
10 Pods.
O Controller verifica continuamente.
Encontrou apenas 9?
Cria outro.
Encontrou 12?
Remove dois.
Tudo automaticamente.
Kubelet
É o agente instalado em cada servidor.
Ele conversa com o Control Plane.
Recebe ordens.
Executa containers.
Monitora saúde.
É semelhante ao operador residente daquele Node.
kubectl — O TSO do Kubernetes
Quem vem do z/OS rapidamente faz essa associação.
No mainframe:
TSO
ISPF
SDSF
No Kubernetes:
kubectl
Exemplos:
kubectl get pods
kubectl logs
kubectl exec
kubectl describe
kubectl apply
kubectl delete
É praticamente o console administrativo do Cluster.
Operators — O DBA automático
Imagine um DBA que nunca dorme.
Nunca esquece um backup.
Nunca esquece RUNSTATS.
Nunca esquece REORG.
É exatamente isso que um Operator faz.
Ele conhece profundamente determinada aplicação.
Exemplo:
Operator do PostgreSQL.
Ele sabe:
instalar
criar réplicas
atualizar
restaurar
monitorar
recuperar falhas
Automaticamente.
Escalabilidade automática
Aqui Kubernetes impressiona.
Horizontal Pod Autoscaler
CPU chegou a:
90%
Resultado:
Cria mais Pods.
Quando a carga diminui...
Remove Pods.
Tudo sem intervenção humana.
Vertical Pod Autoscaler
Em vez de criar novos Pods...
Ele aumenta memória.
512 MB
↓
2 GB
Cluster Autoscaler
Imagine que todos os servidores ficaram lotados.
Na Cloud...
Kubernetes solicita automaticamente novos servidores.
Minutos depois...
O Cluster cresceu sozinho.
Stateful Applications
Nem tudo pode ser descartado.
Banco de dados possui memória.
Histórico.
Arquivos.
Volumes.
Para isso existe:
StatefulSet
Mantém identidade.
Cada Pod possui:
nome fixo
armazenamento fixo
ordem previsível
Ideal para:
PostgreSQL
MongoDB
Kafka
Elasticsearch
Redis Cluster
Persistent Volume
Representa o disco permanente.
Mesmo que o Pod desapareça...
Os dados continuam lá.
Persistent Volume Claim
É um pedido.
A aplicação diz:
"Preciso de 100 GB SSD."
O Kubernetes procura um volume compatível e faz a associação.
CSI
Container Storage Interface.
É uma interface padronizada para integrar armazenamento.
Suporta soluções como:
IBM FlashSystem
IBM Storage Scale
NetApp
Dell
AWS EBS
Azure Disk
Google Persistent Disk
Networking — O assunto que mais assusta
Todo Pod recebe seu próprio endereço IP.
Isso elimina diversas limitações antigas.
DNS
Cada Service ganha um nome.
orders.default.svc.cluster.local
A aplicação usa nomes, não IPs.
kube-proxy
Encaminha tráfego para os Pods corretos.
CNI
Container Network Interface.
É o "driver de rede" do Cluster.
Exemplos:
Calico
Cilium
Flannel
OVN-Kubernetes
Network Policies
Funcionam como firewalls internos.
Você pode permitir, por exemplo:
Frontend
↓
Backend
↓
Banco
Enquanto bloqueia qualquer acesso direto do Frontend ao banco.
Service Mesh
Imagine um "corredor inteligente" entre microsserviços.
Ferramentas como Istio ou Linkerd oferecem:
mTLS
retries automáticos
circuit breaker
roteamento avançado
telemetria
Sem alterar o código da aplicação.
Helm — O instalador do Kubernetes
Helm é frequentemente comparado a um gerenciador de pacotes.
Com um único comando você instala aplicações completas.
helm install grafana
Pronto.
Grafana inteiro.
Com Deployments.
Services.
Volumes.
Secrets.
Tudo configurado.
Kustomize
Enquanto Helm distribui aplicações...
Kustomize adapta configurações para ambientes diferentes.
DEV.
QA.
Homologação.
Produção.
Sem duplicar arquivos.
GitOps
Talvez uma das maiores revoluções dos últimos anos.
O Git deixa de ser apenas um repositório de código.
Ele passa a representar o estado oficial da infraestrutura.
Fluxo:
Git
↓
Argo CD ou Flux
↓
Kubernetes
↓
Deploy automático
Mudou o repositório?
O Cluster converge automaticamente para a nova configuração.
Estratégias modernas de Deploy
Rolling Update
Atualiza gradualmente.
Sem indisponibilidade.
Blue-Green
Mantém duas versões completas.
Depois troca o tráfego de uma só vez.
Canary
Começa pequeno.
1%
↓
5%
↓
10%
↓
25%
↓
50%
↓
100%
Se algo der errado...
Basta interromper.
Segurança
Assim como RACF é essencial no z/OS...
Segurança também é indispensável no Kubernetes.
Principais recursos:
RBAC
IAM
Security Context
Secrets
Criptografia
Políticas de rede
Admission Controllers
A recomendação atual é seguir o princípio do menor privilégio: conceder apenas as permissões estritamente necessárias para cada usuário, serviço ou aplicação.
Observabilidade
Não basta executar aplicações.
É preciso enxergar o que está acontecendo.
Ferramentas comuns:
Prometheus
Grafana
OpenTelemetry
Loki
Jaeger
Alertmanager
Elas mostram:
consumo de CPU
memória
latência
erros
logs
traces distribuídos
eventos do cluster
No mundo IBM Z, essa função lembra o papel conjunto de RMF, SMF, OMEGAMON e ferramentas de automação, cada uma especializada em um aspecto da operação.
Comparando Kubernetes com o Mainframe
| Kubernetes | IBM Z |
|---|---|
| Cluster | Sysplex |
| Node | LPAR |
| Pod | Unidade de execução isolada (analogia funcional a um address space para fins didáticos) |
| Service | VIPA / Endereço lógico |
| Scheduler | WLM |
| RBAC | RACF |
| GitOps | Pipeline DBB/Jenkins/ISPW (conceitualmente) |
| Persistent Volume | DASD |
| CSI | Camada de integração com armazenamento |
| Prometheus | RMF/SMF (observabilidade) |
A comparação não é perfeita — as arquiteturas são diferentes —, mas ajuda a compreender como muitos conceitos fundamentais de disponibilidade, gerenciamento e automação já eram familiares para profissionais de mainframe.
Curiosidades
☕ Easter Egg nº 2
O nome Kubernetes vem do grego κυβερνήτης (kybernḗtēs), que significa timoneiro, piloto ou aquele que governa uma embarcação.
Da mesma raiz surgiu a palavra Cibernética, criada por Norbert Wiener em 1948 para representar a ciência do controle e da comunicação em máquinas e seres vivos.
☕ Easter Egg nº 3
O famoso logotipo em forma de roda do Kubernetes representa o leme de um navio, reforçando a ideia de conduzir e coordenar aplicações em um ambiente distribuído.
☕ Easter Egg nº 4
Grande parte das ideias do Kubernetes nasceu da experiência do Google com um sistema interno chamado Borg, utilizado para gerenciar milhões de workloads muito antes da popularização da computação em nuvem.
Dicas para o Programador COBOL Padawan
Se você vem do universo COBOL e IBM Z, não tente decorar centenas de comandos logo no início. Construa uma base sólida:
Aprenda Docker antes de Kubernetes.
Entenda bem Pods, Deployments e Services.
Estude YAML, pois ele é a linguagem declarativa da plataforma.
Pratique com um cluster local usando Minikube, Kind ou OpenShift Local.
Aprenda
kubectlcomo você aprendeu TSO e ISPF.Depois avance para Volumes, Networking e Segurança.
Em seguida, mergulhe em Helm, GitOps, Operators e Observabilidade.
Só então explore Service Mesh e arquiteturas distribuídas mais sofisticadas.
Essa sequência torna o aprendizado muito mais natural.
Conclusão — O z/OS da Era Cloud
Existe um velho ditado no universo da engenharia:
"Toda tecnologia realmente nova acaba redescobrindo uma boa ideia do passado."
Kubernetes prova isso.
Ele trouxe uma nova forma de empacotar aplicações, distribuir cargas e automatizar operações em larga escala. Porém, muitos de seus princípios — disponibilidade, isolamento, escalabilidade, controle de acesso, recuperação automática e gerenciamento centralizado — já faziam parte da cultura dos grandes sistemas corporativos há décadas.
Para o programador COBOL Padawan, Kubernetes não deve ser visto como um substituto do IBM Z, mas como uma tecnologia complementar. Hoje é comum encontrar arquiteturas híbridas nas quais aplicações executam no mainframe, APIs são expostas pelo z/OS Connect, mensagens trafegam pelo IBM MQ e microsserviços em Kubernetes consomem essas informações para construir soluções modernas.
O profissional mais valorizado do futuro não será aquele que conhece apenas o mundo distribuído ou apenas o mundo mainframe. Será aquele capaz de conectar ambos com segurança, eficiência e visão arquitetural.
Como diria o Sr. Spock:
"A lógica é o começo da sabedoria, não o fim."
No universo da computação corporativa, compreender Kubernetes amplia sua visão sobre a nuvem; compreender IBM Z revela por que muitos desses conceitos já sustentavam os sistemas mais críticos do planeta muito antes da era dos containers. É nessa combinação entre tradição e inovação que surgem as arquiteturas mais robustas do século XXI.
Sem comentários:
Enviar um comentário