O que é o Ingress e como ele roteia o tráfego externo para os Services?

Question

IT Interview Practice · Accepted Answer

Um **Ingress** é um objeto Kubernetes que define **regras de roteamento HTTP/HTTPS** — mapeando hostnames e paths de URL para **Services** de backend. Ele é cumprido por um **Ingress Controller** (nginx, Traefik, gateways de cloud) e lhe dá um único ponto de entrada, TLS termination e roteamento por host/path em vez de um LoadBalancer por serviço.

## O problema que o Ingress resolve

```text
Expor muitos serviços com type: LoadBalancer significa MUITOS LBs de cloud (e IPs públicos)
— caro, e sem roteamento por hostname/path compartilhado nem TLS.
O Ingress dá UM ponto de entrada que roteia por host & path para Services ClusterIP internos.
```

## Como as peças se encaixam

```text
      Internet
         │
   ┌─────┴──────────────┐
   │ Ingress Controller │  (um Pod, ex.: nginx; normalmente atrás de UM LoadBalancer)
   │  lê as regras Ingress│
   └─────┬──────────────┘
         │ roteia por host / path
   ┌─────┼───────────────┬───────────────┐
   ▼                     ▼               ▼
 Service: web        Service: api    Service: admin  (todos ClusterIP)
   │                     │               │
 Pods                  Pods            Pods

Ingress (regras)  ≠  Ingress Controller (o proxy em execução que as aplica)
```

## Um manifest de Ingress

```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  tls:
    - hosts: [shop.example.com]
      secretName: shop-tls        # cert/key TLS armazenados num Secret
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api
                port: { number: 80 }
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port: { number: 80 }
```

```text
shop.example.com/api/... → Service "api" → Pods api
shop.example.com/...     → Service "web" → Pods web
O TLS é terminado no controller usando o cert do Secret "shop-tls".
```

## Pontos-chave

```text
• Você PRECISA rodar um Ingress Controller — o objeto Ingress sozinho não faz nada.
• ingressClassName seleciona qual controller trata as regras.
• Ingress é apenas HTTP/HTTPS (L7). Para TCP/UDP puro use um Service ou a Gateway API.
• A mais nova Gateway API é a sucessora em evolução, com roteamento mais rico e orientado a papéis.
```

```bash
kubectl get ingress                  # lista regras, hosts, endereços
kubectl describe ingress app-ingress # ver backends & eventos
```

## Por que isso importa

O Ingress é a forma padrão de expor aplicações HTTP/HTTPS ao mundo externo no Kubernetes, então entendê-lo é conhecimento essencial de rede para engenheiros de nível pleno. O problema que ele resolve é concreto e comum: expor muitos serviços via `type: LoadBalancer` significa provisionar um load balancer de cloud e um IP público separados por serviço — caro e sem roteamento por hostname compartilhado nem TLS — enquanto um **Ingress** lhe dá um único ponto de entrada que roteia por **host e path** para Services ClusterIP internos e termina **TLS** de forma centralizada. A distinção que confunde as pessoas é entre o **objeto Ingress** (regras de roteamento declarativas) e o **Ingress Controller** (o proxy em execução real — nginx, Traefik, um gateway de cloud — que observa essas regras e as aplica); as regras não fazem nada sem um controller instalado, e o `ingressClassName` seleciona qual controller as trata. Entender que o Ingress opera em **L7 (apenas HTTP/HTTPS)** — de modo que TCP/UDP puro precisa de um Service ou da mais nova Gateway API — e que a **Gateway API** é a sucessora em evolução e mais expressiva, reflete conhecimento atual e alinhado com a realidade. Como quase toda aplicação voltada ao usuário no Kubernetes precisa de roteamento por host/path e TLS a partir de um único ponto de entrada, e como a distinção objeto-vs-controller é uma fonte frequente de confusão tanto em entrevistas quanto na prática, um domínio sólido do Ingress é fundamental para expor e operar workloads web num cluster.

O problema que o Ingress resolve

Como as peças se encaixam

Um manifest de Ingress

Pontos-chave

Por que isso importa

Perguntas relacionadas