<h2>O que é Ingress no Kubernetes</h2>

<p>Ingress é um objeto de API do Kubernetes que gerencia o acesso externo aos serviços dentro de um cluster, funcionando como um gerenciador de tráfego HTTP/HTTPS. Ele atua na camada 7 (aplicação) do modelo OSI, permitindo roteamento inteligente baseado em hostname, path e outros atributos da requisição. Sem o Ingress, você estaria limitado a usar NodePort ou LoadBalancer, soluções que não escalam bem e não oferecem flexibilidade de roteamento.</p>

<p>O Ingress não é apenas uma definição — é um conceito que precisa de um controlador para funcionar. O controlador (como Nginx Ingress Controller) monitora objetos Ingress no cluster e configura automaticamente um reverse proxy para rotear o tráfego conforme as regras definidas. Essa separação entre especificação e implementação é um padrão elegante do Kubernetes, permitindo múltiplas implementações.</p>

<h2>Nginx Ingress Controller: Arquitetura e Instalação</h2>

<h3>Entendendo o Componente</h3>

<p>O Nginx Ingress Controller é um pod que roda um servidor Nginx e fica continuamente observando os recursos Ingress no cluster. Quando você cria ou modifica um Ingress, o controlador traduz aquelas definições em configurações Nginx nativas e recarrega o servidor. O controlador expõe um serviço LoadBalancer (ou NodePort) que recebe o tráfego externo e o distribui aos pods da aplicação.</p>

<p>A arquitetura é simples: cliente envia requisição para o IP do LoadBalancer → Nginx roda a lógica de roteamento → requisição chega ao serviço apropriado → load balancer do Kubernetes (kube-proxy) entrega ao pod correto. Toda essa cadeia é gerenciada declarativamente através do manifesto Ingress.</p>

<h3>Instalando o Nginx Ingress Controller</h3>

<p>Você pode instalar o Nginx Ingress Controller usando Helm, que simplifica bastante o processo. O Helm é um gerenciador de pacotes do Kubernetes que empacota componentes complexos em charts reutilizáveis.</p>

<pre><code class="language-bash"># Adicionar o repositório oficial do Nginx Ingress

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx

helm repo update

Instalar em um namespace dedicado

kubectl create namespace ingress-nginx

helm install nginx-ingress ingress-nginx/ingress-nginx \

--namespace ingress-nginx \

--set controller.service.type=LoadBalancer</code></pre>

<p>Após a instalação, você terá um pod do controlador rodando e um serviço LoadBalancer aguardando requisições. Verifique o status:</p>

<pre><code class="language-bash">kubectl get svc -n ingress-nginx

kubectl get pods -n ingress-nginx</code></pre>

<p>Caso você esteja em um ambiente local (like Minikube ou Docker Desktop), o LoadBalancer pode ficar em estado <code>pending</code>. Use <code>minikube tunnel</code> ou configure o tipo como NodePort para testes locais.</p>

<h2>Roteamento de Tráfego com Ingress</h2>

<h3>Criando um Ingress Simples</h3>

<p>Vamos começar com um exemplo prático. Suponha que você tenha um serviço chamado <code>web-app</code> rodando na porta 8080 e quer expô-lo através de um domínio. Aqui está o manifesto Ingress:</p>

<pre><code class="language-yaml">apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

name: web-app-ingress

namespace: default

spec:

ingressClassName: nginx

rules:

• host: app.example.com

http:

paths:

• path: /

pathType: Prefix

backend:

service:

name: web-app

port:

number: 8080</code></pre>

<p>Este manifesto diz: &quot;Todo tráfego HTTP para app.example.com deve ser roteado para o serviço <code>web-app</code> na porta 8080&quot;. O <code>ingressClassName: nginx</code> explicitamente diz ao cluster qual controlador deve gerenciar este Ingress. O <code>pathType: Prefix</code> significa que qualquer path começando com <code>/</code> será capturado (é o mais comum).</p>

<p>Para aplicar:</p>

<pre><code class="language-bash">kubectl apply -f ingress.yaml

kubectl get ingress

kubectl describe ingress web-app-ingress</code></pre>

<h3>Roteamento Baseado em Path</h3>

<p>Um padrão muito comum é ter múltiplos serviços e rotear diferentes paths para cada um. Imagine que você tem um backend em um serviço e um frontend em outro:</p>

<pre><code class="language-yaml">apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

name: multi-service-ingress

namespace: default

spec:

ingressClassName: nginx

rules:

• host: myapp.com

http:

paths:

• path: /api

pathType: Prefix

backend:

service:

name: api-service

port:

number: 3000

• path: /

pathType: Prefix

backend:

service:

name: web-service

port:

number: 80</code></pre>

<p>Aqui, requisições para <code>myapp.com/api/users</code> vão para <code>api-service</code>, enquanto <code>myapp.com/</code> (incluindo <code>myapp.com/login</code>) vai para <code>web-service</code>. A ordem importa: o Nginx avalia os paths de cima para baixo, então caminhos mais específicos devem vir primeiro.</p>

<h3>Roteamento Baseado em Hostname</h3>

<p>Você também pode ter múltiplos hostnames apontando para serviços diferentes no mesmo Ingress:</p>

<pre><code class="language-yaml">apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

name: virtual-hosts-ingress

namespace: default

spec:

ingressClassName: nginx

rules:

• host: api.mycompany.com

http:

paths:

• path: /

pathType: Prefix

backend:

service:

name: api-backend

port:

number: 5000

• host: www.mycompany.com

http:

paths:

• path: /

pathType: Prefix

backend:

service:

name: website

port:

number: 80

• host: admin.mycompany.com

http:

paths:

• path: /

pathType: Prefix

backend:

service:

name: admin-panel

port:

number: 8888</code></pre>

<p>Isso permite você economizar IPs públicos e gerenciar múltiplos serviços com um único ponto de entrada. O Nginx verifica o header <code>Host</code> da requisição e roteia automaticamente.</p>

<h3>HTTPS e Certificados TLS</h3>

<p>Para usar HTTPS, você precisa adicionar um certificado TLS ao cluster como um Secret e referenciar no Ingress:</p>

<pre><code class="language-bash"># Criar um certificado autoassinado para teste (não use em produção!)

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes \

-subj &quot;/CN=myapp.com&quot;

Criar o Secret

kubectl create secret tls myapp-tls \

--cert=cert.pem \

--key=key.pem \

--namespace=default</code></pre>

<p>Agora referencie no Ingress:</p>

<pre><code class="language-yaml">apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

name: secure-ingress

namespace: default

spec:

ingressClassName: nginx

tls:

• hosts:
• myapp.com

secretName: myapp-tls

rules:

• host: myapp.com

http:

paths:

• path: /

pathType: Prefix

backend:

service:

name: web-app

port:

number: 8080</code></pre>

<p>O Nginx automaticamente configurará SSL/TLS e redireciona HTTP para HTTPS por padrão. Em produção, use certificados gerados pelo cert-manager com Let&#039;s Encrypt em vez de certificados autoassinados.</p>

<h2>Configurações Avançadas e Troubleshooting</h2>

<h3>Annotations para Controle Fino</h3>

<p>O Nginx Ingress Controller aceita annotations que permitem ajustar comportamentos específicos sem modificar o Nginx manualmente. Algumas das mais úteis:</p>

<pre><code class="language-yaml">apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

name: advanced-ingress

namespace: default

annotations:

Redirecionar HTTP para HTTPS

nginx.ingress.kubernetes.io/force-ssl-redirect: &quot;true&quot;

Rate limiting (máximo 10 requisições por segundo por IP)

nginx.ingress.kubernetes.io/limit-rps: &quot;10&quot;

CORS habilitado

nginx.ingress.kubernetes.io/enable-cors: &quot;true&quot;

nginx.ingress.kubernetes.io/cors-allow-origin: &quot;*&quot;

Reescrever URL (remover /api do path antes de enviar ao backend)

nginx.ingress.kubernetes.io/rewrite-target: /

spec:

ingressClassName: nginx

rules:

• host: api.example.com

http:

paths:

- path: /api(/|$)(.*)

pathType: ImplementationSpecific

backend:

service:

name: backend

port:

number: 3000</code></pre>

<p>A annotation <code>rewrite-target</code> é particularmente poderosa. Se o seu backend espera <code>/users</code> mas o cliente chama <code>/api/users</code>, você reescreve removendo o prefixo <code>/api</code>.</p>

<h3>Debugging e Troubleshooting</h3>

<p>Quando algo não funciona, comece verificando os logs do controlador:</p>

<pre><code class="language-bash"># Ver logs do Nginx Ingress Controller

kubectl logs -n ingress-nginx deployment/nginx-ingress-ingress-nginx-controller -f

Verificar configuração gerada pelo Nginx

kubectl exec -it -n ingress-nginx deployment/nginx-ingress-ingress-nginx-controller -- cat /etc/nginx/nginx.conf | head -100

Verificar status do Ingress

kubectl describe ingress seu-ingress-name

kubectl get ingress -A -o wide</code></pre>

<p>Um erro comum é não ter o serviço backend pronto ou com o port incorreto. Verifique sempre:</p>

<pre><code class="language-bash"># Confirmar que o serviço existe e está rodando

kubectl get svc seu-servico

kubectl get endpoints seu-servico

Testar conectividade diretamente

kubectl port-forward svc/seu-servico 8080:8080

Agora acesse localhost:8080 no seu navegador</code></pre>

<p>Outro problema frequente: o domínio não resolve. Em desenvolvimento, edite seu <code>/etc/hosts</code> (ou <code>C:\Windows\System32\drivers\etc\hosts</code> no Windows):</p>

<pre><code>192.168.1.100 app.example.com</code></pre>

<p>Substitua o IP pelo IP do seu LoadBalancer (veja com <code>kubectl get svc -n ingress-nginx</code>).</p>

<h2>Conclusão</h2>

<p>O Ingress do Kubernetes com Nginx Controller oferece uma forma declarativa e escalável de gerenciar o acesso externo aos seus serviços. O conceito central é simples — definir regras de roteamento em YAML — mas a flexibilidade é imensa: você controla roteamento por hostname, path, HTTPS, rate limiting e muitos outros aspetos sem tocar em uma única linha de configuração Nginx.</p>

<p>Dois aprendizados práticos que você nunca deve esquecer: primeiro, o Ingress é apenas especificação; o Nginx Ingress Controller é quem materializa aquilo em configuração real, então sem o controlador instalado, seus manifestos Ingress são apenas dados ociosos. Segundo, debugging é sua melhor ferramenta — os logs do controlador e a configuração gerada do Nginx contam toda a história do que está acontecendo e por quê.</p>

<h2>Referências</h2>

<ul>

<li><a href="https://kubernetes.io/docs/concepts/services-networking/ingress/" target="_blank" rel="noopener noreferrer">Documentação Oficial de Ingress do Kubernetes</a></li>

<li><a href="https://kubernetes.github.io/ingress-nginx/" target="_blank" rel="noopener noreferrer">Nginx Ingress Controller - Documentação Oficial</a></li>

<li><a href="https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/" target="_blank" rel="noopener noreferrer">Ingress Nginx - Annotations</a></li>

<li><a href="https://github.com/kubernetes/ingress-nginx/tree/main/charts/ingress-nginx" target="_blank" rel="noopener noreferrer">Helm Chart do Nginx Ingress</a></li>

<li><a href="https://linuxacademy.com/course/kubernetes-the-hard-way/" target="_blank" rel="noopener noreferrer">Kubernetes Network Policies e Ingress - Linux Academy</a></li>

</ul>

<p>&lt;!-- FIM --&gt;</p>