 |
| Bellacosa Mainframe e o kubernetes ingress |
☕ Um Café no Bellacosa Mainframe
Kubernetes Ingress Muito Além do Erro 502 Bad Gateway
O Que Todo Programador COBOL Padawan Precisa Saber Sobre Ingress, Services, Pods, Endpoints, DNS, DevOps, Cloud e Como os Grandes Bancos Encontram Problemas em Produção Antes que Eles Virem Incidentes
"No Mainframe aprendemos que um ABEND raramente é a causa do problema. Normalmente ele é apenas o sintoma. No Kubernetes acontece exatamente a mesma coisa com o famoso erro 502 Bad Gateway."
Introdução
Se você perguntar para um administrador de Mainframe qual foi o pior problema que ele enfrentou em produção, dificilmente ele responderá que foi um erro de compilação.
Os verdadeiros pesadelos acontecem quando...
o CICS começa a rejeitar transações;
o DB2 responde lentamente;
um Job Batch termina com RC=12;
um MQ Queue Manager para de responder;
uma região entra em SOS (Short On Storage);
ou simplesmente "o sistema caiu" e ninguém sabe por quê.
Curiosamente, no mundo Kubernetes acontece exatamente a mesma coisa.
Um dos erros mais famosos é:
502 Bad Gateway
Muitos iniciantes acreditam que o Ingress "quebrou".
Na verdade...
Na maioria das vezes o Ingress está funcionando perfeitamente.
Quem está com problemas é alguma camada localizada atrás dele.
E aqui está a primeira grande lição para um Programador COBOL Padawan:
Grandes sistemas nunca são compostos por apenas uma aplicação. Eles são compostos por diversas camadas que trabalham em conjunto.
É exatamente assim que funciona um banco.
É exatamente assim que funciona um IBM Z.
E é exatamente assim que funciona um cluster Kubernetes.
Hoje vamos entender profundamente cada uma dessas camadas.
Antes de falar do erro 502...
Precisamos entender quem participa da conversa.
Imagine que você abre o navegador e acessa:
https://api.banco.com/saldo
Parece simples.
Mas internamente existe uma verdadeira viagem.
Usuário
↓
DNS
↓
Load Balancer
↓
Ingress
↓
Service
↓
Endpoints
↓
Pods
↓
Aplicação
↓
Banco de Dados
Veja quantos componentes participaram.
O usuário nem imagina.
É exatamente como acontece quando você consulta seu saldo no aplicativo do banco.
Você aperta um botão.
Milhares de componentes trabalham em conjunto.
A analogia com o Mainframe
Vamos traduzir tudo para a linguagem COBOL.
| Kubernetes | Mainframe |
|---|---|
| DNS | VTAM / TCP/IP |
| Ingress | API Gateway / CICS Front-End |
| Service | Definição lógica de roteamento |
| Pod | Região executando aplicação |
| Container | Address Space |
| Cluster | Data Center |
| Deployment | Versão da aplicação |
| Namespace | Ambiente (DEV/HML/PRD) |
| ConfigMap | PARMLIB |
| Secret | RACF + Keyring |
| Persistent Volume | DASD |
Perceba que os conceitos são muito semelhantes.
Mudam apenas os nomes.
O que realmente significa o erro 502?
O navegador mostra:
502 Bad Gateway
O usuário pensa:
"A aplicação caiu."
Nem sempre.
Na verdade o Ingress está dizendo algo parecido com:
"Recebi sua requisição.
Tentei conversar com o servidor responsável.
Mas ele respondeu errado ou simplesmente não respondeu."
Observe que o problema pode estar muito distante do Ingress.
O Ingress é apenas um porteiro
Imagine um edifício comercial.
Na recepção existe um porteiro.
Ele pergunta:
"Quem você deseja visitar?"
Você responde:
"Departamento Financeiro."
O porteiro liga.
Ninguém atende.
Isso significa que o porteiro fez algo errado?
Claro que não.
Ele apenas tentou encaminhar.
O Ingress faz exatamente isso.
A viagem da requisição
Vamos acompanhar um pacote.
Notebook
↓
Internet
↓
DNS
↓
Ingress Controller
↓
Service
↓
Endpoints
↓
Pod
↓
Container
↓
Aplicação Java
↓
Banco
Em qualquer etapa algo pode falhar.
O DNS
O DNS é o catálogo telefônico da Internet.
Quando digitamos:
api.banco.com
O computador precisa descobrir:
172.31.25.90
Sem DNS nada funciona.
No Kubernetes existe também o DNS interno.
Por exemplo:
pagamentos.default.svc.cluster.local
É assim que um Pod encontra outro.
Sem DNS...
Não existe comunicação.
O Ingress
O Ingress é um roteador HTTP.
Ele analisa:
Host
URL
Caminho
Certificados
TLS
Headers
Depois decide para onde enviar.
Exemplo:
api.banco.com/clientes
↓
Service Clientes
Enquanto:
api.banco.com/cartoes
↓
Service Cartões
O Ingress não executa sua aplicação.
Ele apenas encaminha.
O Service
Aqui existe um conceito muito importante.
O Service NÃO É a aplicação.
Ele também NÃO É o Pod.
Ele funciona como um endereço lógico.
Imagine uma agência bancária.
O cliente conhece:
Caixa Preferencial
Mas não conhece qual funcionário está trabalhando naquele momento.
O Service funciona exatamente assim.
O segredo do Selector
O Service procura Pods através dos Labels.
Exemplo.
O Pod possui:
app=financeiro
O Service procura:
selector:
app=financeiro
Perfeito.
Agora imagine um erro.
Pod:
financeiro
Service:
finance
Uma palavra diferente.
Resultado:
0 Pods encontrados.
O Ingress não terá ninguém para atender.
Endpoints
Pouca gente conhece esse objeto.
Mas ele é extremamente importante.
O Endpoint é a lista de Pods disponíveis.
Imagine:
Pod A
10.1.1.5
Pod B
10.1.1.6
O Service cria:
Endpoints
10.1.1.5
10.1.1.6
Agora o balanceamento pode acontecer.
Quando o Endpoint fica vazio
Imagine que todos os Pods morreram.
O Endpoint passa a mostrar:
<none>
Agora pense.
O Ingress pergunta:
"Para quem envio?"
O Service responde:
"Ninguém."
Resultado?
502
ou
503
Dependendo do cenário.
O Pod
O Pod é onde sua aplicação realmente vive.
Pode conter:
Java
Go
Node
Python
.NET
COBOL moderno
É equivalente a uma região executando programas.
Running não significa saudável
Esse é um erro clássico.
Imagine:
kubectl get pods
Resultado:
Running
Todo mundo comemora.
Mas...
READY
0/1
O Pod está vivo.
Mas não está pronto.
É igual um operador sentado na mesa sem conseguir atender clientes.
Readiness Probe
Essa é uma das funcionalidades mais inteligentes do Kubernetes.
A cada poucos segundos ele pergunta:
Você está pronto?
Se a resposta for:
200 OK
O Pod entra no balanceamento.
Caso contrário...
Ele fica isolado.
Liveness Probe
Agora outra pergunta.
Você continua vivo?
Se a resposta for negativa...
O Kubernetes mata o processo.
Depois inicia outro.
É como um operador de Mainframe reiniciando uma região CICS travada.
TargetPort
Um dos maiores causadores do erro 502.
Imagine:
Container:
8080
Service:
targetPort
9090
O Service bate na porta errada.
É igual ligar para um ramal inexistente.
O erro mais comum do mundo
O desenvolvedor altera a aplicação.
Antes:
8080
Depois:
9090
Esquece de alterar o Service.
Pronto.
Produção parada.
Como um SRE investiga
Nunca começa olhando código.
Segue uma sequência lógica.
Primeiro:
kubectl get ingress
Depois:
kubectl describe ingress
Depois:
kubectl get svc
Depois:
kubectl describe svc
Depois:
kubectl get endpoints
Depois:
kubectl get pods
Depois:
kubectl logs
Perceba a filosofia.
Ele verifica a cadeia inteira.
Não apenas um componente.
A importância dos Logs
Logs são o SDSF do Kubernetes.
No Mainframe fazemos:
SDSF
JESMSGLG
JESJCL
SYSOUT
No Kubernetes fazemos:
kubectl logs
Ali encontramos mensagens como:
Connection refused
Timeout
Database unavailable
Port already in use
Essas mensagens normalmente apontam para a causa raiz.
Eventos do Cluster
Outro recurso pouco utilizado.
kubectl get events
Ali aparecem informações como:
Pod reiniciado
Nó indisponível
Falha no agendamento
Problemas de armazenamento
Imagem não encontrada
Erros de montagem de volumes
É semelhante aos consoles operacionais de um ambiente z/OS, onde mensagens do sistema revelam a sequência dos acontecimentos.
O que os grandes bancos fazem diferente?
Grandes bancos não esperam o usuário reclamar.
Eles monitoram tudo.
Cada camada possui métricas específicas:
Tempo de resposta do Ingress.
Quantidade de requisições por segundo.
Taxa de erros HTTP.
Saúde dos Pods.
Consumo de CPU e memória.
Tempo de resposta do banco de dados.
Número de conexões ativas.
Latência entre serviços.
Ferramentas como Prometheus, Grafana, Loki, Elastic, OpenTelemetry e Jaeger ajudam a transformar milhares de métricas em painéis compreensíveis.
Observabilidade: muito além dos logs
Em ambientes modernos falamos em três pilares:
Logs: contam o que aconteceu.
Métricas: mostram tendências e comportamento.
Traces: acompanham uma requisição por todas as camadas.
Imagine uma transferência bancária. Um trace pode mostrar:
Cliente
↓
Ingress
↓
API
↓
Serviço de autenticação
↓
Serviço de pagamentos
↓
DB2
Se houver lentidão, você identifica exatamente onde ela ocorreu.
Um estudo de caso
Imagine que um banco publica uma nova versão do serviço de consulta de saldo.
Logo após o deploy, o monitoramento começa a registrar centenas de erros 502.
O procedimento correto seria:
Confirmar se o Ingress continua roteando corretamente.
Verificar se o Service aponta para a porta correta.
Confirmar se os Endpoints existem.
Validar se os Pods estão
Ready.Conferir a configuração das Readiness Probes.
Examinar os logs da aplicação.
Caso necessário, executar um rollback para a versão anterior.
Observe que, em nenhum momento, a primeira ação é "reiniciar tudo". Profissionais experientes evitam esse tipo de abordagem porque ela pode mascarar a causa real do problema.
Lições para um Programador COBOL Padawan
Quem trabalhou com Mainframe já aprendeu algo muito valioso:
Um ABEND pode ter origem em um arquivo indisponível.
Um SQLCODE negativo pode ser consequência de um problema anterior.
Um Job RC=12 pode ter sido causado por outro Job que terminou em RC=08.
Em Kubernetes, a lógica é idêntica.
O erro 502 é apenas o último elo de uma cadeia de eventos.
Por isso, desenvolva sempre uma visão sistêmica. Entenda como DNS, Ingress, Services, Endpoints, Pods, Containers, Rede e Aplicação trabalham juntos. Essa capacidade de enxergar o fluxo completo é o que diferencia um operador de comandos de um verdadeiro engenheiro de software.
Conclusão
O famoso 502 Bad Gateway é um excelente exemplo de como os sistemas modernos são compostos por diversas camadas cooperando entre si. O Ingress raramente é o verdadeiro culpado; ele apenas informa que não conseguiu obter uma resposta válida do backend.
Para o Programador COBOL Padawan, a maior lição não é decorar comandos do kubectl, mas adotar uma forma de pensar que já existe há décadas no universo IBM Mainframe: investigar de forma estruturada, compreender a arquitetura completa e seguir o caminho da requisição do início ao fim.
Em um banco moderno, uma simples consulta de saldo pode atravessar DNS, balanceadores, Ingress, Services, Pods, APIs, mensageria, aplicações Java, programas COBOL, CICS e DB2 antes de retornar ao cliente. Quando entendemos essa jornada, percebemos que um erro como o 502 deixa de ser um mistério e passa a ser um sintoma que aponta para a próxima etapa da investigação.
No fim das contas, a tecnologia muda, os nomes evoluem e as plataformas se modernizam, mas os princípios permanecem os mesmos: conhecer a arquitetura, observar cuidadosamente os sinais do sistema e investigar cada camada até encontrar a verdadeira causa raiz. É assim que trabalham os SREs, os engenheiros DevOps e os especialistas em IBM Z responsáveis por manter, todos os dias, milhões de transações bancárias funcionando com segurança e disponibilidade quase absoluta.
