 |
| Bellacosa Mainframe apresenta kubernetes sem misterios |
☕ Um Café no Bellacosa Mainframe
Kubernetes sem Mistérios
Os 50 Erros que Derrubam Clusters em Produção (e que um Profissional IBM Z já Aprendeu a Evitar Há Décadas)
Existe uma curiosidade interessante.
Muitos profissionais enxergam Kubernetes como uma tecnologia revolucionária.
Ela realmente é.
Mas existe outra forma de enxergá-la.
Para quem trabalhou anos em Mainframe, Kubernetes parece muito mais uma redescoberta de conceitos que IBM já aplicava há décadas.
Disponibilidade.
Balanceamento.
Isolamento.
Escalonamento.
Segurança.
Observabilidade.
Recuperação.
Controle de acesso.
Versionamento.
Rollback.
Tudo isso sempre existiu.
A diferença é que hoje esses conceitos aparecem usando containers, pods e YAML.
No IBM Z eles aparecem como:
JES2
WLM
RACF
Sysplex
CICS
Db2
GDG
VSAM
SMF
RMF
O objetivo continua exatamente o mesmo:
Fazer sistemas críticos permanecerem funcionando.
O grande problema
Criar um cluster Kubernetes é extremamente fácil.
Rodar um cluster durante cinco anos, sem interrupções relevantes, é extremamente difícil.
Quase todos os grandes incidentes em produção acontecem por pequenas decisões aparentemente inocentes.
É exatamente isso que o infográfico demonstra.
BLOCO 1
Cluster & Infrastructure
Erro 1
Um único Worker Node
Imagine um banco inteiro rodando em apenas um IBM Z.
Parece absurdo.
No Kubernetes isso acontece o tempo inteiro.
Node A
APP1
APP2
APP3
APP4
Se esse servidor falhar...
Tudo cai.
No Mainframe isso seria equivalente a:
um único CPC
sem Parallel Sysplex
sem GDPS
sem redundância
Alta disponibilidade simplesmente deixa de existir.
Erro 2
Não proteger o Control Plane
O Control Plane é o cérebro.
Ele contém:
API Server
Scheduler
Controller Manager
ETCD
Sem ele...
O cluster fica "cego".
Os containers podem continuar rodando por algum tempo.
Mas nada novo consegue ser criado.
É parecido com perder o JES2 Master.
Erro 3
Não fazer backup do ETCD
O ETCD guarda praticamente todo o estado do cluster.
É equivalente ao:
catálogo do sistema
SYS1
repositórios de configuração
Sem ETCD...
Você perdeu:
Deployments
Services
Secrets
ConfigMaps
RBAC
Namespaces
Ou seja...
Perdeu o cluster.
Erro 4
Misturar Desenvolvimento e Produção
Esse é um erro clássico.
Imagine colocar:
PIX
Internet Banking
Folha de Pagamento
junto com
Sistema de Testes
No mesmo cluster.
Um teste mal executado pode consumir:
CPU
Memória
IO
Rede
e afetar produção.
Mainframe resolveu isso há décadas.
LPARs.
WLM.
Classes de serviço.
Ambientes isolados.
BLOCO 2
Resource Management
Aqui aparece um dos assuntos mais importantes.
Recursos.
No Kubernetes nada funciona "no automático".
Requests
Requests significam:
"O mínimo que preciso."
Exemplo
CPU: 500m
Memory: 1GB
O Scheduler utiliza isso para decidir onde colocar o Pod.
Sem requests...
Ele simplesmente chuta.
É semelhante ao WLM tentando distribuir workload sem conhecer prioridades.
Limits
Agora vem outra história.
Limits representam o máximo permitido.
CPU
2 cores
RAM
4GB
Se ultrapassar...
O processo sofre throttling.
Ou pode ser encerrado.
OOMKilled
Talvez o erro mais famoso.
Quando um container usa mais memória que o permitido.
O Kernel Linux faz:
OOM Killer
e encerra o processo.
No Mainframe seria parecido com:
Storage exhaustion
ou
S878
HPA
Horizontal Pod Autoscaler.
Ele aumenta o número de Pods.
Mas cuidado.
Escalar uma aplicação ruim apenas cria mais instâncias lentas.
É parecido com colocar mais CICS Regions para um programa que possui SQL ruim.
O gargalo continua existindo.
BLOCO 3
Deployment
Aqui surgem alguns erros extremamente comuns.
Nunca usar latest
Jamais.
image: latest
Parece prático.
Mas amanhã...
"latest"
é outra versão.
Você perdeu reprodutibilidade.
Sempre utilize
1.2.7
2.1.0
5.8.12
ou melhor ainda
Digest SHA256.
Isso lembra muito o mundo Mainframe.
Nunca executamos:
PROD.COBOL
Sabemos exatamente qual Load Module foi promovido.
Readiness Probe
O Pod iniciou.
Mas será que ele está pronto?
Não necessariamente.
Uma aplicação Java pode precisar:
30 segundos.
Sem Readiness.
O Kubernetes envia tráfego imediatamente.
Resultado:
Erro.
Liveness Probe
Verifica se o processo continua vivo.
Se travar...
O Kubernetes reinicia.
É semelhante ao Automation do SA z/OS detectando um address space congelado.
Startup Probe
Ideal para aplicações pesadas.
Sem ela...
O Kubernetes mata a aplicação antes dela terminar de iniciar.
Rolling Update
Jamais atualizar todos os Pods simultaneamente.
Sempre:
1
2
3
4
Nunca:
100%
de uma vez
É exatamente o conceito de deploy gradual utilizado por bancos.
BLOCO 4
Networking
Aqui muitos iniciantes sofrem.
Network Policies
Sem elas...
Todo Pod conversa com qualquer Pod.
Isso é perigosíssimo.
Imagine um malware chegando.
Ele consegue acessar praticamente tudo.
É equivalente a um RACF onde todos possuem ALTER em todos os datasets.
Impensável.
DNS
Muitos problemas parecem ser de aplicação.
Na verdade são DNS.
service
↓
CoreDNS
↓
IP
Uma falha aqui afeta milhares de Pods.
NodePort
Expor NodePort diretamente para Internet.
Nunca.
Use:
Ingress
Load Balancer
API Gateway
WAF
TLS
Sem TLS.
Todo tráfego pode ser interceptado.
No Mainframe isso seria equivalente a utilizar TN3270 sem criptografia.
BLOCO 5
Storage & Security
Aqui aparecem erros gravíssimos.
Rodar como Root
Nunca.
Um container comprometido ganha acesso privilegiado.
Use:
runAsNonRoot
readOnlyRootFilesystem
drop capabilities
Secrets em ConfigMaps
Erro extremamente comum.
ConfigMap não criptografa.
Secrets devem permanecer em:
Secret
Vault
KMS
External Secrets
RBAC
Sem RBAC.
Todos administram tudo.
Imagine um operador podendo:
Excluir produção.
Criar usuários.
Modificar políticas.
É por isso que RACF existe.
RBAC é o RACF do Kubernetes.
BLOCO 6
Observabilidade
Talvez o capítulo mais importante.
Sem logs...
Não existe troubleshooting.
Sem métricas...
Não existe capacity planning.
Sem tracing...
Não existe análise distribuída.
Sem dashboards...
Não existe visão operacional.
Ferramentas normalmente utilizadas
Logs
ELK
OpenSearch
Loki
Métricas
Prometheus
Dashboards
Grafana
Tracing
Jaeger
Tempo
Zipkin
Alertas
Alertmanager
Isso lembra muito:
RMF
SMF
OMEGAMON
NetView
Tivoli
Z APM Connect
BLOCO 7
Operação
Aqui aparecem erros humanos.
E a maioria dos grandes incidentes nasce justamente deles.
Deploy manual
Nunca.
Sempre:
Git
Pipeline
Automação
GitOps
O Git torna-se a verdade absoluta.
Toda alteração passa por:
Commit
↓
Review
↓
Pipeline
↓
Deploy
↓
Rollback
É semelhante ao ChangeMan, ISPW ou Endevor.
Nada muda diretamente na produção.
Não testar recuperação
Backup sem restore não vale nada.
Todo DR precisa ser testado.
No IBM Z isso sempre foi obrigatório.
GDPS.
Recovery.
Image Copy.
Log Apply.
Não auditar segurança
Novas vulnerabilidades surgem diariamente.
Imagens precisam ser continuamente escaneadas.
Os "novos" erros
Os últimos slides ampliam ainda mais a lista.
Entre eles destacam-se:
Não definir ResourceQuota.
Não usar LimitRange.
Ignorar Namespaces.
Expor aplicações diretamente.
Não realizar backup periódico do ETCD.
Não otimizar custos.
Não separar ambientes.
Não validar probes continuamente.
Não monitorar consumo financeiro do cluster.
Esses erros normalmente não derrubam o ambiente no primeiro dia, mas aumentam gradualmente a complexidade operacional e o risco de incidentes.
O grande paralelo com IBM Z
O aspecto mais interessante desse material é perceber que praticamente todos os "50 erros do Kubernetes" já possuem um equivalente consolidado no ecossistema IBM Z:
| Kubernetes | IBM Z / Mainframe |
|---|---|
| RBAC | RACF |
| Scheduler | WLM |
| Rolling Update | Promoção controlada (Endevor/ISPW/ChangeMan) |
| ReplicaSet | Parallel Sysplex |
| ETCD | Catálogos e repositórios críticos do sistema |
| Observabilidade | RMF, SMF, OMEGAMON |
| Health Checks | SA z/OS, NetView |
| GitOps | Gestão de configuração e promoção de software |
| Secrets | RACF + ICSF + cofres corporativos |
| Autoscaling | Balanceamento e classes de serviço do WLM |
A tecnologia mudou, mas os princípios permanecem.
A maior lição para um Padawan COBOL
Quem está começando em Kubernetes costuma imaginar que dominar YAML, Pods e Deployments basta para operar um ambiente de produção. Na realidade, isso representa apenas uma pequena parte do trabalho.
Os profissionais mais experientes pensam primeiro em engenharia operacional. Antes de criar um único Deployment, eles definem como recuperar o cluster após uma falha, como limitar recursos para evitar que uma aplicação afete outra, como monitorar métricas, como proteger segredos, como automatizar implantações, como auditar mudanças e como garantir que qualquer alteração possa ser revertida rapidamente.
Essa é exatamente a mentalidade que sempre existiu no IBM Z. Durante décadas, bancos, seguradoras e governos construíram sistemas que precisavam permanecer disponíveis 24 horas por dia. Kubernetes não substitui esses princípios; ele os reapresenta em uma nova arquitetura baseada em containers.
No Bellacosa Mainframe, essa é talvez a maior mensagem deste material: um bom engenheiro de Kubernetes não é aquele que conhece mais comandos kubectl, mas aquele que projeta plataformas resilientes, observáveis, seguras e previsíveis. A verdadeira maturidade está menos na tecnologia utilizada e muito mais na disciplina de engenharia aplicada a ela.
