Inicio / Ingress paso a paso

Cómo exponer una app en Kubernetes con Ingress paso a paso

De un Pod que solo habla dentro del clúster a un dominio público con HTTPS.

Por defecto, un Pod de Kubernetes solo es alcanzable dentro del clúster. Para que un usuario en internet llegue hasta tu app necesitas encadenar tres piezas: el Pod, un Service que le dé una dirección estable, y un Ingress que enrute el tráfico externo hacia ese Service según el dominio y la ruta.

Paso 1 — el Service (dirección interna estable)

Los Pods se crean y se destruyen constantemente (al escalar, al actualizar la imagen), así que su IP cambia. Un Service les da un nombre y una IP interna que no cambian nunca, y reparte el tráfico entre todos los Pods que coincidan con su selector:

apiVersion: v1
kind: Service
metadata:
  name: mi-servicio
spec:
  type: ClusterIP
  selector:
    app: mi-app
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP

type: ClusterIP (el valor por defecto) es suficiente aquí — el Ingress hablará con este Service desde dentro del clúster, así que no necesita ser accesible desde fuera por sí mismo.

Paso 2 — el Ingress Controller (una pieza que instalar una vez)

Un objeto Ingress por sí solo no hace nada: necesita un Ingress Controller corriendo en el clúster que lea esos objetos y configure un proxy real (nginx, Traefik, HAProxy…). Si tu clúster es gestionado (GKE, EKS, AKS) puede que ya tenga uno, o tengas que instalarlo con un solo comando (por ejemplo ingress-nginx vía Helm). Esto se hace una vez por clúster, no por cada app.

Paso 3 — el objeto Ingress (las reglas de enrutado)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: mi-ingress
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - app.midominio.com
      secretName: mi-tls-secret
  rules:
    - host: app.midominio.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: mi-servicio
                port:
                  number: 80

ingressClassName le dice a Kubernetes qué Ingress Controller debe atender esta regla (útil si tienes más de uno). Cada entrada de rules asocia un host con una lista de paths; cada path apunta a un Service y un puerto concretos — así puedes enrutar /api a un backend y / a un frontend con el mismo Ingress.

Paso 4 — TLS (el candado del navegador)

El bloque tls le dice al Ingress Controller que sirva ese host por HTTPS usando el certificado guardado en el Secret mi-tls-secret (de tipo kubernetes.io/tls, con las claves tls.crt y tls.key). En producción, ese Secret casi siempre lo rellena automáticamente cert-manager pidiendo un certificado gratuito a Let's Encrypt — pero el Ingress no necesita saber cómo se generó, solo dónde está.

¿Y si solo tengo una app y no quiero instalar un Ingress Controller?

Para un caso muy simple, un Service de tipo LoadBalancer (en una nube que lo soporte) te da una IP pública directa sin necesidad de Ingress. La desventaja es que cada Service de este tipo suele facturar su propio balanceador de carga en la nube — con dos o tres apps, un único Ingress sale más barato y más ordenado.

Genera el Service y el Ingress de tu app —incluido el bloque TLS— con nuestro generador de manifiestos de Kubernetes, y combina ambos en un solo archivo con el modo «paquete».

← Volver al generador