Ingress

El NodePort de la lección anterior funciona, pero imagina veinte aplicaciones: veinte puertos raros que documentar, sin TLS centralizado, sin rutas por nombre. La respuesta de Kubernetes al tráfico HTTP entrante es el Ingress: un objeto donde declaras reglas del tipo "las peticiones para el host X van al Service Y", y un Ingress controller que las hace realidad.

El detalle importante: el objeto Ingress no hace nada por sí solo, necesita un controller que lo interprete. Aquí juega a favor el playground: k3s trae de serie Traefik como Ingress controller, escuchando en el puerto 80 de todos los nodos. Compruébalo desde la pestaña dev-machine:

kubectl get pods -n kube-system -l app.kubernetes.io/name=traefik

kubectl get ingressclass

Esa IngressClass llamada traefik (marcada como default) es la que conectará tus reglas con el controller.

Paso 1: Backend y Service

Un Ingress enruta hacia Services, así que primero levanta la base. De nuevo, sin guía: crea un Deployment web (1 réplica de ghcr.io/iximiuz/labs/nginx:alpine, etiqueta app: web, puerto 80) y un Service ClusterIP web que lo seleccione en el puerto 80.

Pista: ninguna de las dos piezas necesita YAML

kubectl create sabe crear un Deployment y un Service directamente, con la imagen, el puerto y las réplicas como banderas. Y para el Service hay un atajo mejor todavía: kubectl expose parte de un objeto que ya existe y hereda su selector, que es justo lo que hay que acertar aquí.

Paso 2: El Ingress

El fichero puedes encontrarlo en manifests/ingress.yaml:

ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
spec:
  rules:
  - host: app.local
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web
            port:
              number: 80

El YAML, explicado con preguntas y respuestas

¿Otro grupo de API más?

Sí: networking.k8s.io/v1, el grupo de los recursos de red (Ingress, NetworkPolicy). Con este ya has visto los cuatro grandes: core, apps, batch y networking.

¿Qué papel juega host?

Es la condición de la regla: solo las peticiones HTTP cuya cabecera Host sea app.local la activan. Así un solo punto de entrada en el puerto 80 puede servir decenas de aplicaciones distintas, una por nombre.

¿Qué significa pathType: Prefix?

Cómo comparar el path con la URL de la petición. Prefix casa / y todo lo que cuelgue de él; la alternativa Exact exige coincidencia literal. Es obligatorio declararlo.

¿Por qué el backend es un Service y no mis Pods?

Porque el Ingress delega en la maquinaria que ya conoces: el controller enruta al Service, y el Service reparte entre sus endpoints. Cada pieza hace un solo trabajo.

¿No falta decir qué controller usa?

Existe el campo ingressClassName para elegirlo explícitamente. Lo omitimos porque k3s marca la clase traefik como default; en un clúster con varios controllers lo declararías siempre.

Aplícalo:

kubectl apply -f manifests/ingress.yaml
kubectl get ingress

Paso 3: La prueba desde fuera

El host app.local no existe en ningún DNS, así que simula lo que haría el navegador enviando la cabecera a mano. Desde dev-machine:

curl -H "Host: app.local" http://cplane-01/

Y la contraprueba, que es donde se entiende el Ingress: la misma petición sin la cabecera correcta.

curl -i http://cplane-01/

Un 404 de Traefik. El controller recibe todo lo que llega al puerto 80, pero solo enruta lo que casa con alguna regla.

Y para verlo como lo vería un usuario, abre la pestaña app.local: ahí está tu aplicación. Esa pestaña apunta al puerto 80 de cplane-01 y añade la cabecera Host: app.local por ti, que es exactamente lo que acabas de hacer a mano con curl -H. Sin esa reescritura recibiría el mismo 404 de la contraprueba.

Resumen

El Ingress declara reglas HTTP (host y path hacia Service); el Ingress controller las ejecuta.
Sin controller, un Ingress es solo un objeto decorativo. k3s resuelve esto trayendo Traefik de serie.
Un único punto de entrada en el 80/443 sustituye a un NodePort por aplicación, y es donde se centraliza el TLS.
El libro cubre también la evolución de esta idea, la Gateway API; con lo aprendido aquí, su lectura te resultará natural.