Ingress no Kubernetes: Guia Completo para Roteamento Avançado e Exposição de Serviços

O que é o Ingress?

O Ingress é um recurso essencial do Kubernetes que permite gerenciar o acesso externo aos serviços dentro de um cluster, especialmente para tráfego HTTP e HTTPS. Ele funciona definindo regras que direcionam as requisições de entrada para diferentes Services com base no host, caminho (path) ou outras condições específicas. Com isso, possibilita funcionalidades como balanceamento de carga, terminação TLS (SSL) e roteamento por URL.

Diferente dos Services do tipo LoadBalancer ou NodePort, que expõem os serviços diretamente, o Ingress oferece uma camada de abstração mais flexível, eficiente e centralizada para controlar o tráfego externo que chega ao cluster.

Como funciona o Ingress?

• Para usar o Ingress, criamos objetos com regras que indicam para quais Services o tráfego HTTP/HTTPS deve ser encaminhado.
• Um componente chamado Ingress Controller é necessário para que o Ingress funcione efetivamente. Ele monitora essas regras pelo API do Kubernetes e aplica as configurações nos proxies reversos, gerenciando como o tráfego é roteado.
• Exemplos populares de Ingress Controllers incluem o NGINX Ingress Controller, Traefik e HAProxy.
• Entre os recursos suportados estão roteamento baseado em host e caminho, terminação TLS, redirecionamentos, autenticação e outras funcionalidades específicas do controlador em uso.

Arquitetura básica: O Ingress Controller atua como uma ponte entre o recurso Ingress e o proxy reverso que realmente manipula o tráfego, como o NGINX ou HAProxy. Ele escuta o API Kubernetes para mudanças nas regras de Ingress e atualiza o proxy correspondendo as configurações para garantir o correto roteamento e aplicação de políticas.

Vantagens do Ingress

• Roteamento avançado e flexível: Permite direcionar tráfego para diversos serviços com base em diferentes critérios, como URLs, domínios e cabeçalhos HTTP.
• Terminação TLS centralizada: Garante o gerenciamento simplificado de certificados SSL em um único ponto.
• Economia de endereços IP públicos: Com um único endpoint público, é possível acessar múltiplos serviços dentro do cluster, sem a necessidade de expor cada Service individualmente.
• Fácil integração: Compatível com diversas ferramentas e painéis de monitoramento que suportam Ingress.
• Facilita escalabilidade e manutenção: Permite atualizar os destinos do tráfego sem alterar o ponto de entrada visível para os clientes.

Desvantagens e limitações do Ingress

• Dependência do Ingress Controller: O recurso Ingress por si só é apenas uma definição declarativa, requer um controlador instalado para funcionar, o que adiciona complexidade à configuração e manutenção.
• Suporte limitado a protocolos: Ingress é focado em tráfego HTTP e HTTPS (camada 7). Protocolos como TCP e UDP exigem configurações adicionais ou o uso de outros tipos de Service.
• Funcionalidades variam conforme o controlador: Recursos disponíveis e suporte a extensões podem diferir entre os Ingress Controllers, requerendo atenção na escolha conforme a necessidade do projeto.
• Não indicado para exposição direta de bancos de dados ou serviços binários: Devido ao foco no tráfego HTTP/HTTPS, não é apropriado para serviços como bancos de dados PostgreSQL que usam protocolos TCP binários.

Tipos de Ingress Controllers

Embora o Kubernetes defina um único objeto Ingress, existem diversas implementações de Ingress Controllers, com características distintas:

1. NGINX Ingress Controller

• O controlador mais popular e amplamente usado.
• Suporta roteamento avançado, terminação TLS, autenticação externa e suporte a WebSocket.

2. Traefik

• Além de HTTP/HTTPS, possui configuração dinâmica e integração simplificada com vários sistemas.

3. Outros exemplos: HAProxy, Istio Gateway, Contour

• Oferecem funcionalidades específicas, como integração com malhas de serviço (service mesh), suporte a protocolos personalizados e recursos avançados de segurança.

Importante: Sem um Ingress Controller instalado, as definições de um recurso Ingress não terão efeito no tráfego.

Expor PostgreSQL usando Ingress: é possível?

PostgreSQL é um serviço TCP, não HTTP

O Ingress é projetado para lidar com tráfego HTTP/HTTPS, baseado em regras da camada 7. Já o PostgreSQL utiliza um protocolo TCP binário, por isso o Ingress não é indicado para expor diretamente bancos de dados PostgreSQL.

Como expor PostgreSQL no Kubernetes corretamente?

• Utilize um Service do tipo LoadBalancer ou NodePort para expor o serviço PostgreSQL, que opera em TCP.
• Alguns Ingress Controllers suportam encaminhamento TCP/UDP via ConfigMaps adicionais, mas isso depende do controlador e não é a finalidade principal do Ingress.
• Alternativamente, um proxy TCP/SSL dedicado fora do Kubernetes ou uma VPN podem ser usados para garantir segurança e acesso controlado ao banco.

Exemplo básico para expor PostgreSQL com Service NodePort

apiVersion: v1
kind: Service
metadata:
  name: postgresql-service
spec:
  ports:
  - port: 5432
    targetPort: 5432
    protocol: TCP
  selector:
    app: postgresql
  type: NodePort

Assim, o banco PostgreSQL ficará acessível externamente via o IP do nó do cluster e a porta associada ao NodePort.

Resumo das diferenças entre Service e Ingress para exposição

Conclusão

O Ingress é uma ferramenta poderosa para gerenciar e expor aplicações HTTP/HTTPS em clusters Kubernetes, oferecendo flexibilidade no roteamento, centralização na gestão de TLS e facilidade para balanceamento entre múltiplos serviços. No entanto, não é adequado para serviços que utilizam protocolos TCP, como bancos de dados PostgreSQL.

Para expor bancos de dados, a abordagem recomendada é usar Services configurados para TCP, garantindo segurança e desempenho robustos. Em casos onde roteamento TCP avançado é necessário, alguns Ingress Controllers podem oferecer suporte especial via configurações extras, mas isso foge do uso padrão e exige atenção.

Se precisar, posso auxiliar na configuração de um Ingress Controller específico, fornecer exemplos avançados ou recomendar opções seguras para expor bancos de dados em ambientes Kubernetes.