Recuperar Deployment eliminado Kubernetes (Retain)

Alguien borró un Deployment de MariaDB por accidente y el pánico es inmediato. La buena noticia: si el volumen usaba la política Retain, los datos siguen en el disco. Recuperar un Deployment eliminado en Kubernetes con un volumen Retain es cuestión de re-vincular ese disco a un PersistentVolumeClaim nuevo y volver a aplicar el Deployment. En el caso del walkthrough de CKA publicado el 20 de junio de 2026, el pod volvió a correr sin reinicios y con la base intacta.

Te cuento el procedimiento exacto, paso por paso, con los comandos reales y las trampas donde casi todos se cuelgan.

La política Retain en Kubernetes es una de las tres reclaim policies de un PersistentVolume. Cuando borrás el PersistentVolumeClaim asociado, el volumen no se elimina ni se vacía: queda con estado Released y conserva los datos en disco, esperando que un nuevo claim lo tome. Es la opción pensada para datos críticos donde una eliminación accidental no debería costarte la información.

¿Qué es la política Retain en Kubernetes y por qué protege tus datos?

Kubernetes tiene tres políticas de reclamación (reclaim policies) para un PersistentVolume, y definen qué pasa con el disco cuando el PVC que lo usaba desaparece.

• Retain: el volumen queda intacto. Pasa a estado Released y conserva los datos. La recuperación es manual, vos decidís cuándo y cómo re-vincularlo.
• Delete: al borrar el PVC, Kubernetes también borra el PV y, en muchos provisioners de nube, el disco físico subyacente. Limpieza automática, pero perdés todo.
• Recycle: deprecada hace años. Hacía un borrado básico del contenido (rm -rf) y dejaba el volumen disponible. No la uses.

¿Por qué Retain es la opción segura para producción? Porque desacopla el ciclo de vida del dato del ciclo de vida del workload. Si alguien borra el Deployment a las tres de la mañana, el disco no se evapora con él. Para una base de datos, eso es la diferencia entre un susto de diez minutos y un incidente de recuperación de backups que puede durar horas (si es que tenés backups, claro).

¿Qué sucede cuando elimino un Deployment que usa volumen Retain?

Ponele que corrés kubectl delete deployment mariadb -n mariadb sin pensarlo demasiado. ¿Qué se va y qué queda? Esto se conecta con lo que analizamos en los pipelines de despliegue modernos.

Se van el Deployment, los ReplicaSets y los pods. Si además borraste el PVC, también desaparece la reclamación. Lo que NO se va es el PersistentVolume con política Retain. Confirmás el síntoma rápido:

• kubectl get deploy,pods -n mariadb devuelve No resources found. El workload no existe más.
• kubectl get pv mariadb muestra el volumen vivo, con RECLAIM POLICY: Retain y status Available o Released.

Acá conviene entender la diferencia entre los dos estados. Released significa que el PV tuvo un claim que ya no existe, pero todavía guarda una referencia interna (el claimRef) al PVC viejo. Available significa que está libre para que cualquier claim compatible lo tome. Esa referencia colgada es justo lo que vas a tener que limpiar para poder re-vincular.

Cómo verificar que tu volumen Retain sigue disponible en el cluster

Antes de tocar nada, diagnosticá. La regla de oro: no asumas, mirá el estado real.

• Listar el volumen: kubectl get pv mariadb te da capacidad, modo de acceso, reclaim policy y status en una línea.
• Ver el detalle: kubectl describe pv mariadb te muestra el claimRef (a qué PVC apuntaba), la ruta en disco y el StorageClass. Acá confirmás si todavía cuelga del PVC viejo.
• Confirmar la política: en la salida buscá Reclaim Policy: Retain. Si dice Delete, frená, porque el panorama cambia por completo.

Si el volumen aparece como Released, está bien. Tiene los datos, solo que arrastra el claimRef del claim borrado. Ese es el clavo a sacar antes del próximo paso.

Crear un nuevo PersistentVolumeClaim vinculado al volumen existente

Esta es la parte donde la gente se cuelga, así que vamos despacio. Son dos movimientos: limpiar la referencia vieja del PV y crear un PVC que apunte de forma estática al volumen.

Primero, limpiar el claimRef. Mientras el PV recuerde al PVC borrado, va a quedar en Released y rechazar cualquier binding nuevo. Lo sacás con un patch:

kubectl patch pv mariadb -p '{"spec":{"claimRef": null}'

Con eso el PV pasa a Available y ya se puede tomar.

Segundo, crear el PVC con bind estático. Acá hay dos campos que no podés equivocar:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: mariadb
 namespace: mariadb
spec:
 storageClassName: ""
 volumeName: mariadb
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 250Mi

¿Por qué storageClassName: "" y no omitirlo? Porque si lo dejás vacío o lo omitís y tenés un StorageClass por defecto en el cluster, Kubernetes asume que querés aprovisionamiento dinámico y te crea un PV vacío nuevo. Este binding vincula un claim a un PV, que es el disco real. El string vacío explícito le dice: “no provisiones nada, usá el volumen que ya te nombré en volumeName“. El volumeName fuerza el binding estático a ese PV puntual.

Aplicás con kubectl apply -f pvc.yaml y verificás con kubectl get pvc -n mariadb: tiene que aparecer Bound al volumen mariadb.

Re-aplicar el Deployment y verificar que recupera los datos

Con el PVC ya en Bound, el último paso es levantar el Deployment apuntando a ese claim.

Aplicás el manifiesto: kubectl apply -f deployment.yaml. El Deployment monta el PVC mariadb, que ahora está atado al PV con tus datos. Y verificás:

• Estado del pod: kubectl get pods -n mariadb debe mostrar el pod en Running con 0 en la columna RESTARTS. Si reinicia en loop, algo del montaje no cerró.
• Logs limpios: kubectl logs <pod> -n mariadb tiene que arrancar MariaDB sin reinicializar la base. Si ves que crea las tablas de cero, montaste un volumen vacío, no el tuyo.
• Dato vivo: entrá con kubectl exec y corré un SHOW DATABASES; o un SELECT contra una tabla conocida. Si los registros están, recuperaste todo.

El criterio del examen CKA es claro: pod corriendo, sin reinicios, datos intactos. Eso es todo. Si llegaste hasta acá con la base respondiendo, aprobaste la tarea. En cuanto a seguridad del acceso a volúmenes profundizamos sobre esto.

Diferencias entre Retain, Delete y Recycle: cuándo usar cada una

La elección de reclaim policy define cuánto margen de error tenés. Acá la comparación seca:

La regla práctica: si la pregunta es “¿me dolería perder esto?”, la respuesta es Retain. Para un entorno de pruebas que recreás con un script, Delete te ahorra discos colgados acumulándose y facturando. Si gestionás clusters propios sobre infraestructura en la nube o un VPS, en donweb.com tenés servidores donde armar tu cluster de Kubernetes con control total sobre el almacenamiento persistente.

Errores comunes al recuperar volúmenes Retain y cómo evitarlos

Estos son los tropezones que vemos una y otra vez, con su corrección.

• Creer que Retain borra los datos: falso. Retain conserva todo. El estado Released asusta porque suena a “liberado/vaciado”, pero solo significa que perdió su claim. Antes de entrar en pánico, corré kubectl describe pv.
• No limpiar el claimRef antes de re-vincular: si saltás ese paso, el PVC nuevo se queda en Pending para siempre y no entendés por qué. El PV sigue “casado” con un claim fantasma. Patcheá el claimRef a null primero.
• Dejar storageClassName con el provisioner por defecto: Kubernetes te crea un PV vacío nuevo y montás una base en blanco. Usá siempre storageClassName: "" más volumeName para el bind estático.
• Usar Delete en producción sin backup: el clásico. Configurás Delete “para que limpie solo”, borrás el namespace por error y el disco se va con todo. Si vas a usar Delete, que sea solo donde podés recrear los datos.

Preguntas Frecuentes

¿Cómo recupero un Deployment que eliminé accidentalmente en Kubernetes?

Si el volumen usaba política Retain, el PersistentVolume sobrevive con los datos. Limpiás el claimRef del PV con kubectl patch pv <nombre> -p '{"spec":{"claimRef": null}', creás un PVC nuevo con storageClassName: "" y volumeName apuntando al PV, y volvés a aplicar el Deployment. El pod recupera la base sin reinicios.

¿Qué es la política Retain en Kubernetes y para qué sirve?

Retain es una de las tres reclaim policies de un PersistentVolume. Cuando se borra el PVC asociado, el volumen no se elimina ni se vacía: queda en estado Released con los datos intactos. Sirve para proteger información crítica de eliminaciones accidentales, dejando la recuperación bajo control manual del administrador.

¿Puedo recuperar datos si borro un PersistentVolumeClaim?

Sí, siempre que el PersistentVolume tenga reclaim policy Retain. Al borrar el PVC, el PV pasa a Released pero conserva los datos en disco. Creás un PVC nuevo con bind estático al mismo PV y los recuperás. Si la política era Delete, en cambio, el disco se elimina con el PVC y no hay recuperación directa.

¿Cuál es la diferencia entre PV, PVC y claimRef en Kubernetes?

El PersistentVolume (PV) es el disco real. El PersistentVolumeClaim (PVC) es la solicitud de almacenamiento que un Deployment monta. El claimRef es el campo interno del PV que registra a qué PVC está vinculado. Cuando borrás el PVC, ese claimRef queda colgando y hay que limpiarlo para re-vincular el volumen.

¿Cómo re-vinculo un volumen persistente después de eliminar la reclamación?

Primero limpiás el claimRef del PV con un kubectl patch para que vuelva a Available. Después creás un PVC con storageClassName: "" (string vacío, no omitido) y volumeName con el nombre del PV. Eso fuerza un binding estático al volumen existente en vez de aprovisionar uno nuevo.

Conclusión

Borrar un Deployment con base de datos no es una catástrofe si configuraste bien el almacenamiento. La política Retain te da una red de seguridad real: el disco sobrevive al workload y lo re-vinculás en pocos minutos. El procedimiento es siempre el mismo, limpiar el claimRef, crear un PVC con bind estático (storageClassName: "" más volumeName) y volver a aplicar el Deployment.

Si todavía tenés tus volúmenes de producción en Delete, andá a revisarlos ahora. Cambiar la reclaim policy a Retain en los datos que no podés perder es un ajuste de un minuto que te ahorra el peor día de tu vida como administrador. Y aunque uses Retain, mantené tus backups: Retain te salva del borrado accidental, no de un disco que falla.

Fuentes

• Documentación oficial de Kubernetes – PersistentVolumes y reclaim policies
• The Cyber Sidekick – Recover a deleted Deployment from a Retain-policy volume (CKA Storage)
• OneUptime – PV reclaim policies y retención de datos
• DonWeb News – StatefulSets vs Deployments: persistencia de datos en Kubernetes
• Paradigma Digital – Kubernetes: almacenamiento y persistencia de datos