Controlar o tráfego de entrada e saída de um cluster Kubernetes não é luxo, é sobrevivência operacional. É exatamente nesse ponto que o Kubernetes Ingress entra em cena: ele organiza o caos, reduz custos e simplifica a exposição de serviços para a internet. Para quem está começando ou já opera clusters em produção, entender Ingress deixou de ser opcional.
Este artigo explica o conceito de Ingress, como ele funciona no Kubernetes e por que tantas equipes migraram para esse modelo.
O que é Ingress, afinal?
Ingress não nasceu no Kubernetes. O conceito existe em várias plataformas de código aberto e se resume a uma ideia simples: definir regras que controlam como o tráfego externo entra em um sistema.
Na prática, um Ingress recebe requisições HTTP ou HTTPS e as encaminha para o serviço correto com base em regras como domínio, caminho da URL ou ambos. Ele funciona como um porteiro inteligente, analisando cada pedido antes de decidir para onde ele vai.
Quando nenhuma regra combina, o tráfego é enviado para um backend padrão, conhecido como default backend, que normalmente retorna um erro 404.
O grande objetivo do Ingress é centralizar roteamento, balanceamento de carga e exposição externa, evitando que cada serviço precise de seu próprio IP público ou load balancer.
O que é Ingress no Kubernetes (K8s)?
No Kubernetes, o Ingress é um recurso nativo responsável por gerenciar o acesso externo aos serviços que rodam dentro do cluster. Ele atua como um gateway único, aplicando regras de roteamento definidas em arquivos YAML.
Em vez de criar vários serviços do tipo LoadBalancer, o desenvolvedor define regras de Ingress que direcionam o tráfego para diferentes serviços internos, geralmente expostos como ClusterIP ou NodePort.
O resultado é menos complexidade, menos IPs públicos e muito mais controle.
Os componentes principais do Kubernetes Ingress
O Ingress no Kubernetes funciona com três peças fundamentais:
- O Ingress Controller, que é quem realmente faz o trabalho pesado. Ele observa os recursos Ingress do cluster e aplica as regras de roteamento. Pode ser baseado em Nginx, HAProxy, GCE, entre outros.
- O recurso Ingress, que é o objeto Kubernetes onde ficam as regras: domínios, caminhos e serviços de destino.
- As regras de Ingress, que determinam exatamente como cada requisição deve ser encaminhada.
- Sem um controller rodando no cluster, o Ingress simplesmente não funciona.
Por que usar Ingress em vez de vários LoadBalancers?
Muitas equipes começam expondo serviços com LoadBalancers individuais. Funciona, mas não escala bem — nem técnica nem financeiramente.
Cada LoadBalancer tem custo, seja por unidade, por regra ou por tempo de uso. À medida que a infraestrutura cresce e novos ambientes surgem (dev, staging, produção), a conta explode.
Com Ingress, um único IP público pode expor dezenas de serviços diferentes, apenas variando domínio e caminho. Isso reduz drasticamente o número de LoadBalancers e simplifica a operação.
Em ambientes como Google Cloud, o Ingress também é a única forma nativa de fazer balanceamento com terminação TLS para HTTPS.
Benefícios práticos do Kubernetes Ingress
O Ingress habilita recursos essenciais para ambientes modernos:
- Ele distribui tráfego entre múltiplas réplicas de um serviço, garantindo alta disponibilidade.
- Permite terminação SSL/TLS no próprio controller ou no load balancer.
- Suporta múltiplos domínios no mesmo IP, usando virtual hosts.
- Roteia tráfego com base em caminhos de URL, ideal para arquiteturas com múltiplos serviços.
- Viabiliza deploys canary, direcionando apenas parte do tráfego para novas versões.
Tudo isso de forma centralizada e declarativa.
Ingress Controllers: o cérebro da operação
As regras de Ingress só ganham vida quando existe um controller ativo no cluster. Existem várias implementações prontas, e também é possível criar uma própria.
Na prática, muitas equipes usam Nginx como controller tanto na AWS quanto no Google Cloud. A diferença é que, no GCP, o controller pode ser gerenciado automaticamente, enquanto na AWS ele costuma ser instalado manualmente via Deployment.
O controller observa continuamente os recursos Ingress e ajusta o roteamento conforme as regras mudam.
Como funciona o roteamento com Ingress
Um recurso Ingress define qual controller deve gerenciá-lo e quais regras aplicar. É possível rotear tráfego por domínio, por caminho ou pela combinação dos dois.
Um mesmo domínio pode direcionar caminhos diferentes para serviços distintos. Se nenhuma regra for atendida, a requisição cai no backend padrão.
Ingresses diferentes podem existir em namespaces diferentes, todos atendidos pelo mesmo controller e pelo mesmo IP público, desde que usem a mesma classe de Ingress.
Resultados reais na prática
Ao centralizar o tráfego com Ingress, equipes conseguem reduções massivas de custo e complexidade. É comum ver infraestruturas que saem de dezenas de LoadBalancers para pouco mais de uma dúzia, mesmo considerando ambientes de desenvolvimento e produção em múltiplas clouds.
Além da economia, fica mais fácil isolar times, padronizar exposição de serviços e manter consistência entre ambientes.
Cuidados e limitações
Ingress não é bala de prata. Ele adiciona uma nova camada à arquitetura, o que pode complicar o diagnóstico de problemas de rede se a equipe não estiver familiarizada com o recurso.
Em ambientes gerenciados como o GKE, é essencial configurar corretamente as Readiness Probes. Sem elas, o Ingress simplesmente não roteia tráfego para os pods. Outro ponto importante é o tempo de propagação: após um serviço ficar pronto, pode levar vários minutos até que o Ingress comece a responder corretamente.
O Kubernetes Ingress é uma das peças mais importantes para operar clusters modernos em produção. Ele reduz custos, simplifica a exposição de serviços e oferece um nível de controle que não escala bem com LoadBalancers tradicionais.
Ao mesmo tempo, exige maturidade operacional, entendimento de rede e atenção aos detalhes. Quando bem implementado, o ganho supera — e muito — a complexidade extra.
