¿Qué es un Ingress y cómo enruta el tráfico externo hacia los Services?

Question

IT Interview Practice · Accepted Answer

Un **Ingress** es un objeto de Kubernetes que define **reglas de enrutamiento HTTP/HTTPS**, mapeando hostnames y rutas de URL a **Services** de backend. Lo materializa un **Ingress Controller** (nginx, Traefik, gateways de cloud) y te da un único punto de entrada, terminación TLS y enrutamiento por host/ruta en vez de un LoadBalancer por servicio.

## El problema que resuelve el Ingress

```text
Exponer muchos servicios con type: LoadBalancer significa MUCHOS LBs de cloud (e IPs públicas)
— caro, y sin enrutamiento compartido por hostname/ruta ni TLS.
El Ingress da UN punto de entrada que enruta por host y ruta a Services ClusterIP internos.
```

## Cómo encaja todo

```text
      Internet
         │
   ┌─────┴──────────────┐
   │ Ingress Controller │  (un Pod, p. ej. nginx; normalmente detrás de UN LoadBalancer)
   │  lee las reglas Ingress│
   └─────┬──────────────┘
         │ enruta por host / ruta
   ┌─────┼───────────────┬───────────────┐
   ▼                     ▼               ▼
 Service: web        Service: api    Service: admin  (todos ClusterIP)
   │                     │               │
 Pods                  Pods            Pods

Ingress (reglas)  ≠  Ingress Controller (el proxy en ejecución que las aplica)
```

## Un 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/clave TLS almacenados en un 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 de api
shop.example.com/...     → Service "web" → Pods de web
El TLS se termina en el controller usando el cert del Secret "shop-tls".
```

## Puntos clave

```text
• DEBES ejecutar un Ingress Controller — el objeto Ingress por sí solo no hace nada.
• ingressClassName selecciona qué controller maneja las reglas.
• El Ingress es solo HTTP/HTTPS (L7). Para TCP/UDP crudo usa un Service o la Gateway API.
• La más reciente Gateway API es el sucesor en evolución, con enrutamiento más rico y orientado a roles.
```

```bash
kubectl get ingress                  # lista reglas, hosts, direcciones
kubectl describe ingress app-ingress # ver backends y eventos
```

## Por qué es importante

El Ingress es la forma estándar de exponer aplicaciones HTTP/HTTPS al mundo exterior en Kubernetes, así que entenderlo es conocimiento esencial de red para ingenieros de nivel medio. El problema que resuelve es concreto y común: exponer muchos servicios vía `type: LoadBalancer` significa provisionar un load balancer de cloud y una IP pública separados por servicio —caro y sin enrutamiento compartido por hostname ni TLS—, mientras que un **Ingress** te da un único punto de entrada que enruta por **host y ruta** a Services ClusterIP internos y termina el **TLS** de forma centralizada. La distinción que confunde a la gente es entre el **objeto Ingress** (reglas de enrutamiento declarativas) y el **Ingress Controller** (el proxy realmente en ejecución —nginx, Traefik, un gateway de cloud— que vigila esas reglas y las aplica); las reglas no hacen nada sin un controller instalado, y `ingressClassName` selecciona qué controller las maneja. Entender que el Ingress opera en **L7 (solo HTTP/HTTPS)** —así que TCP/UDP crudo necesita un Service o la más reciente Gateway API— y que la **Gateway API** es el sucesor en evolución y más expresivo refleja conocimiento actual y del mundo real. Como casi toda aplicación de cara al usuario en Kubernetes necesita enrutamiento por host/ruta y TLS desde un único punto de entrada, y como la distinción objeto-vs-controller es una fuente frecuente de confusión tanto en entrevistas como en la práctica, un buen dominio del Ingress es fundamental para exponer y operar workloads web en un cluster.

El problema que resuelve el Ingress

Cómo encaja todo

Un manifest de Ingress

Puntos clave

Por qué es importante

Preguntas relacionadas