2. Desplegar MongoDB y la API

Crear el namespace

Todos los recursos de la aplicación se crean en el namespace mern.

Manifiesto inicial

Crear k8s/01-db-api.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: mern
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: db
  namespace: mern
spec:
  replicas: 1
  selector:
    matchLabels:
      app: db
  template:
    metadata:
      labels:
        app: db
    spec:
      containers:
        - name: mongo
          image: mongo:7.0
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 27017
---
apiVersion: v1
kind: Service
metadata:
  name: db
  namespace: mern
spec:
  selector:
    app: db
  ports:
    - port: 27017
      targetPort: 27017
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: mern
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: mern-crud:study
          imagePullPolicy: IfNotPresent
          command:
            - nodemon
            - server
          ports:
            - containerPort: 3000
          env:
            - name: DB
              value: mongodb://db/mern-crud
            - name: CORS
              value: "1"
            - name: DEBUG
              value: "express:*"
---
apiVersion: v1
kind: Service
metadata:
  name: api
  namespace: mern
spec:
  type: ClusterIP
  selector:
    app: api
  ports:
    - port: 3000
      targetPort: 3000

Aplicar:

kubectl apply -f k8s/01-db-api.yaml

Comprobar:

kubectl get deployments,services,pods -n mern

Probar la API

Crear un túnel temporal:

kubectl port-forward -n mern service/api 3001:3000

Probar desde otra terminal:

curl -i http://localhost:3001

Probar el DNS interno

Crear un Pod temporal:

kubectl run debug \
  -n mern \
  --rm -it \
  --restart=Never \
  --image=busybox:1.36 \
  -- sh

Dentro del Pod:

wget -O- http://api:3000
nc -z -v db 27017
exit

La API encuentra MongoDB mediante el nombre DNS db.

Pruebas a realizar

Una vez aplicado el manifiesto, se pueden realizar las siguientes pruebas:

Listar todos los recursos del namespace:
```
kubectl get all -n mern
```

Revisar los detalles de los Deployments, Services y Pods:

kubectl describe deployment db -n mern
kubectl describe deployment api -n mern
kubectl describe service db -n mern
kubectl describe service api -n mern

Observar los logs de la API y de MongoDB:

kubectl logs deployment/api -n mern
kubectl logs deployment/db -n mern

Comprobar los endpoints que Kubernetes ha asociado a cada Service:
```
kubectl get endpointslice -n mern -o wide
```
Desde el Pod temporal, comprobar tanto el acceso HTTP a la API como la
resolución DNS y el puerto de MongoDB:
```
wget -O- http://api:3000
nc -z -v db 27017
```
Eliminar el Pod de la API y observar cómo el Deployment crea otro:
```
kubectl get pods -n mern -w
kubectl delete pod -n mern -l app=api
```
En esta etapa MongoDB todavía no tiene almacenamiento persistente, por lo
que no se debe eliminar su Pod si se quieren conservar los datos de prueba.

Aprendizajes del despliegue

Un Deployment mantiene el número deseado de réplicas y recrea los Pods que desaparecen.
Los Pods reciben nombres dinámicos y no deben ser tratados como servidores permanentes.
Un Service proporciona un punto de acceso estable para los Pods seleccionados por sus etiquetas.
Kubernetes ofrece DNS interno para que la API encuentre MongoDB mediante db.
Un Service ClusterIP solo es accesible dentro del clúster; el port-forward crea un acceso temporal desde el equipo local.
Los endpoints muestran qué Pods están siendo utilizados realmente por cada Service.
Los logs y los eventos del recurso ayudan a distinguir problemas de la aplicación de problemas del despliegue.
Sin un volumen persistente, los datos de MongoDB están ligados al ciclo de vida del Pod.