4. Exponer la aplicación mediante Ingress

Habilitar el controlador

minikube addons enable ingress

Comprobar:

kubectl get pods -n ingress-nginx
kubectl get service -n ingress-nginx

Crear el Ingress

Crear k8s/03-ingress.yaml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: mern
  namespace: mern
spec:
  ingressClassName: nginx
  rules:
    - host: web.mern.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port:
                  number: 4200
    - host: api.mern.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api
                port:
                  number: 3000

Aplicar:

kubectl apply -f k8s/03-ingress.yaml
kubectl get ingress -n mern

Crear un único acceso local

El Service del controlador es NodePort. Para este laboratorio se utilizó un único port-forward:

kubectl port-forward \
  -n ingress-nginx \
  service/ingress-nginx-controller \
  8080:80

Dejar este proceso activo.

Configurar hosts locales

Añadir en /etc/hosts:

127.0.0.1 web.mern.local
127.0.0.1 api.mern.local

Cambiar la URL de la API del frontend

En k8s/02-web.yaml cambiar:

            - name: REACT_APP_API_URL
              value: "http://api.mern.local:8080"

Aplicar y esperar el rollout:

kubectl apply -f k8s/02-web.yaml
kubectl rollout status deployment/web -n mern

Acceder a:

http://web.mern.local:8080/

La ruta final es:

Navegador
  -> Ingress Controller
  -> Service web o Service api
  -> Pod correspondiente

Pruebas a realizar

Revisar el estado del Ingress y los recursos que utiliza:

kubectl describe ingress mern -n mern
kubectl get service web api -n mern
kubectl get endpointslice -n mern -o wide

Comprobar el acceso a la web y a la API usando los nombres definidos en
/etc/hosts:
```
curl -i http://web.mern.local:8080/
curl -i http://api.mern.local:8080/
```

Verificar que el enrutamiento depende del encabezado Host, incluso si se
utiliza la misma dirección local:

curl -i -H 'Host: web.mern.local' http://127.0.0.1:8080/
curl -i -H 'Host: api.mern.local' http://127.0.0.1:8080/

Enviar una petición con un host inexistente y observar la respuesta del
controlador:
```
curl -i -H 'Host: desconocido.mern.local' http://127.0.0.1:8080/
```

Revisar los logs del controlador mientras se realizan peticiones:

kubectl logs -n ingress-nginx \
  deployment/ingress-nginx-controller --tail=50

Eliminar y recrear el Pod de la web para comprobar que el Ingress sigue
llegando al Service cuando cambia la dirección del Pod:
```
kubectl delete pod -n mern -l app=web
kubectl get endpointslice -n mern \
  -l kubernetes.io/service-name=web -w
```

Aprendizajes del despliegue

Un Ingress concentra varios accesos HTTP y los dirige según el host solicitado.
El Ingress no selecciona Pods directamente: entrega el tráfico a un Service.
El controlador de Ingress es un componente adicional del clúster y también debe estar operativo.
Una misma dirección IP y un mismo puerto pueden servir aplicaciones distintas mediante nombres de host.
El port-forward del controlador es un acceso de laboratorio; no representa una exposición permanente del clúster.
Los cambios en los Pods se reflejan en los endpoints de los Services sin modificar las reglas del Ingress.
Una petición con un host no definido permite observar cómo responde el controlador cuando no encuentra una regla coincidente.