6. Almacenamiento persistente

Comprobar StorageClass

kubectl get storageclass

En Minikube debe existir una StorageClass standard normalmente marcada como default.

Crear el PVC

Crear k8s/04-db-pvc.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mongo-data
  namespace: mern
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Aplicar:

kubectl apply -f k8s/04-db-pvc.yaml
kubectl get pvc -n mern

El PVC debe quedar en estado Bound.

Montar el PVC en MongoDB

En el contenedor de MongoDB añadir:

          volumeMounts:
            - name: mongo-data
              mountPath: /data/db

En spec.template.spec, al mismo nivel que containers, añadir:

      volumes:
        - name: mongo-data
          persistentVolumeClaim:
            claimName: mongo-data

Aplicar:

kubectl apply -f k8s/01-db-api.yaml
kubectl rollout status deployment/db -n mern

Probar persistencia

Crear un registro desde la aplicación y eliminar el Pod de MongoDB:

kubectl delete pod -n mern -l app=db

Esperar el nuevo Pod:

kubectl wait \
  --for=condition=ready \
  pod \
  -l app=db \
  -n mern \
  --timeout=120s

El registro debe continuar existiendo.

Conceptos

Eliminar Pod       -> los datos sobreviven
Eliminar PVC       -> puede eliminarse el volumen y perderse la información

El PV creado por Minikube utiliza normalmente:

Reclaim Policy: Delete

No eliminar el PVC durante esta fase.

Pruebas a realizar

Revisar el estado del PVC, el PV asociado y la StorageClass utilizada:

kubectl get pvc,pv,storageclass -n mern
kubectl describe pvc mongo-data -n mern

Comprobar que el Pod de MongoDB tiene montado el volumen en /data/db:

kubectl describe pod -n mern -l app=db
kubectl exec -n mern deploy/db -- mount | grep /data/db

Revisar qué volumen está usando el Pod:

kubectl get pod -n mern -l app=db \
  -o jsonpath='{.items[0].spec.volumes[*].persistentVolumeClaim.claimName}'

Crear o verificar un registro, eliminar el Pod de MongoDB y esperar su
recreación. Después, comprobar que el registro sigue disponible:
```
kubectl delete pod -n mern -l app=db
kubectl wait --for=condition=ready pod -l app=db -n mern --timeout=120s
kubectl logs deployment/db -n mern
```
La comprobación del registro se puede hacer desde mongosh o desde la API.
Observar los eventos durante la recreación para relacionar el Pod con el
volumen persistente:
```
kubectl get events -n mern --sort-by=.lastTimestamp
```

No se debe eliminar el PVC como parte de esta prueba: con la política de
reclamación Delete, esa acción puede eliminar también el volumen asociado.

Aprendizajes del despliegue

Un PVC solicita almacenamiento sin acoplar la aplicación a los detalles del PV.
El estado Bound indica que la solicitud fue asociada a un volumen disponible.
El volumen se monta en el contenedor mediante volumeMounts y volumes.
Eliminar un Pod no elimina el PVC ni los datos almacenados en el volumen.
La persistencia de los datos es independiente de la identidad temporal del Pod.
El PV y su StorageClass determinan aspectos como la capacidad y la política de reclamación.
El PVC pertenece al namespace y debe ser referenciado por recursos del mismo namespace.
Eliminar el PVC es una operación distinta de eliminar el Pod y puede tener consecuencias irreversibles para los datos.