Começou a estudar ou mexer num cluster Kubernetes e ficou difícil entender o papel, ou como funciona o Ingress? Não foi de primeira pra mim também. Mas vou tentar ajudar a esclarecer esse recurso muito útil do K8s.
De modo simples e direto, o Ingress é uma das formas de expormos serviços HTTP e HTTPS para fora do cluster. Ele trabalha na camada 7 (Application Layer), o que permite lidarmos com recursos como URLs, headers, paths e outros — dependendo do Ingress Controller escolhido.
Já o Service atua na camada 4 (TCP/UDP), fazendo basicamente o balanceamento por IP e porta. Ele não entende rotas ou regras baseadas em domínio.
Por isso o Ingress traz mais funcionalidades e flexibilidade para o cluster. Como vemos na imagem abaixo, ele fica à frente do Service: em uma requisição externa, ele primeiro recebe a chamada, aplica as regras definidas e então encaminha para o Service correto.
Mas existe um detalhe muito importante aqui: o Ingress, por si só, é apenas um recurso declarativo do Kubernetes. Ele define regras, mas não executa nada sozinho.
Quem realmente faz o trabalho acontecer é o Ingress Controller.
O Ingress Controller é uma aplicação que roda dentro do cluster e é responsável por ler os recursos de Ingress criados e transformar aquelas regras em configuração real de proxy ou load balancer.
Em outras palavras:
- O Ingress define o que deve acontecer
- O Ingress Controller faz acontecer
Sem um Ingress Controller instalado no cluster, criar um Ingress não terá efeito algum.
Existem diversos tipos de Ingress Controllers, cada um com suas características. Alguns exemplos bastante utilizados são o NGINX Ingress Controller, o HAProxy, o Traefik e, em ambientes na AWS, o AWS Load Balancer Controller.
Cada um deles pode oferecer recursos extras como TLS automático, integração com load balancers externos, WAF, autenticação, rate limiting, entre outros.
Um ponto importante que muita gente não sabe no início é que podemos ter mais de um Ingress Controller rodando no mesmo cluster.
Isso é bastante comum em ambientes maiores ou com múltiplos times. Por exemplo: um time pode usar um controller específico para aplicações internas, enquanto outro usa um controller integrado ao load balancer do cloud para aplicações públicas.
É aí que entra o conceito de IngressClass.
O IngressClass permite definir qual Ingress Controller deve processar determinado recurso de Ingress. Ou seja, no momento da criação do Ingress, você informa qual classe ele deve utilizar — e apenas o controller associado àquela classe irá assumir aquelas regras.
Isso traz organização e separação de responsabilidades dentro do cluster.
Na prática, já vemos muitos clientes utilizando diferentes abordagens ao mesmo tempo, como por exemplo:
- AWS Load Balancer Controller para integração nativa com ALB na AWS
- Kong quando há necessidade forte de API Management
- Istio quando o ambiente já utiliza service mesh
- Traefik em cenários mais simples ou edge
- NGINX Ingress Controller, que ainda é um dos mais populares
Cada escolha depende muito do nível de complexidade da arquitetura, requisitos de segurança, governança e integração com o ambiente de cloud.
Vale lembrar que o Ingress não é mais a única opção quando falamos de exposição de aplicações no Kubernetes. A comunidade evoluiu bastante esse conceito e hoje temos também o Gateway API.
O Gateway API surge como uma evolução do Ingress, trazendo um modelo mais flexível, mais extensível e com melhor separação de responsabilidades. Ele permite cenários mais avançados, como delegação entre times, múltiplos gateways e regras mais organizadas.
Mas isso é assunto para um próximo post.
No próximo artigo vamos entender como funciona o Gateway API, quais são suas principais diferenças em relação ao Ingress e em quais cenários ele pode ser a melhor escolha.
