Is there a reason why this is “delete” and not “retain” ?
Mostly because it is within the spirit of automation and operator handling.
With Operator you can either keep the PVCs when cluster is deleted (it is by default) or do a complete clean up with the finalizer - delete-psmdb-pvc
.
Why do you think we should have Retain? I see it only as the case for protecting data in case of manual PVCs deletion.
I see it only as the case for protecting data in case of manual PVCs deletion.
Exactly - a developer deleted a GKE cluster by mistake (yea … I know …) and it would be nice if the data related stuff would be left intact. Let’s say someone does delete the cluster in PROD, then it’s still ok to delete the data related resources manually.
Got it! Well, reclaim policy is something dictated by StorageClass, not PVC.
The quickest solution here would be to modify the storage class that you use. GKE’s standard storage class:
allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
storageclass.kubernetes.io/is-default-class: "true"
creationTimestamp: "2022-06-20T08:17:48Z"
labels:
addonmanager.kubernetes.io/mode: EnsureExists
name: standard
resourceVersion: "368"
uid: 6942539b-a89f-4f26-a1b4-865fead29015
parameters:
type: pd-standard
provisioner: kubernetes.io/gce-pd
reclaimPolicy: Delete
volumeBindingMode: Immediate
Change reclaimPolicy
here.
Our Operator creates PVCs, but Reclaim Policy is set on PV level. I’m not sure if it is possible to dynamically change PVc reclaim policy through PVC resource in k8s. Maybe I’m wrong.
Will modifying the storage class help in your case? You can have on StorageClass for prod workloads and always keep the data, and another StorageClass with delete
, not to keep the junk.