1

i got a configuration of a postgres deployment, something like this..

on the volumeMounts level

      volumeMounts:
        - mountPath: /var/lib/postgresql/data
          name: postgres-persistance-storage-new

on the volumes level

  volumes:
    - name: postgres-persistance-storage-new
      persistentVolumeClaim:
        claimName: postgres-pv-claim-new

the PersistentVolumeClaim spec

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-pv-claim-new # name of PVC essential for identifying the storage data
  labels:
    app: postgres
    tier: database
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

My problem is the following : when i delete persistentVolumeClaim via a kubectl command, and then launch again my postgres deployment yaml spec, the persistentVolume seems to be always here, as logs in postgres container say :

PostgreSQL Database directory appears to contain a database; Skipping initialization

How is it possible ?

it.drive.view
  • 95
  • 8
  • Can you update the old manifest files as well and have you created a separate deployment for your new pods and are all your old pods were down now. One more thing after modifying the PV and PVC config have you applied them. – Kranthiveer Dontineni Mar 15 '23 at 05:54

1 Answers1

1

When you delete a PVC, if there is a resource that uses it (for example if the volume is attached to a Deployments with running Pods) this remains ACTIVE.

This is the reason: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection

When you reapply the YAML describing the Deployment, Kubernetes will upgrade to rolling-update mode.

Rolling updates allow Deployments' update to take place with zero downtime by incrementally updating Pods instances with new ones. The new Pods will be scheduled on Nodes with available resources.

https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/

This means that your "old" Pod will remain active until the "new" becomes Up&Running (but continuing to fail, the "old" will never be killed and consequently the PVC will never be destroyed, continuing to maintain the application configurations).

To conclude, I suggest you delete the resources (postgresql Deployment in this case) that use the deleted PVC before re-installing them.

glv
  • 994
  • 1
  • 1
  • 15