Clearer way to map PVCs to PVs for Static Volumes

[curionim]

• Which image of the operator are you using? registry.opensource.zalan.do/acid/postgres-operator:v1.5.0
• **Where do you run it - cloud or metal? Bare Metal K8s
• Are you running Postgres Operator in production? yes
• Type of issue? feature request

When running on cluster without dynamic volumes, i.e. PVs are statically created, the operator will try to create a PVC for each replica and bind it to available PVs based on storage class name and size.
We would like to be able to explicitly select which PVs to use, for instance by allowing for static PVCs, or by using selectors.
Is it possible already?

Thanks,
Michele

[Jan-M]

If you can elaborate more what is needed for this we might at least give some feedback.

I would wonder if this is not something K8s can already solve for you?

[curionim]

Hi Jan,
what is needed is a way in postgres-manifest to be able to specify which PV the various replicas of Postgres will bind to.
In our system we have about 10 PVs created statically, each using the same storage class.
3 of those PVs are meant for Postgres.
When the Operator creates the Postgres cluster with 3 instances, it will request 3 available PVs from Kubernetes based on the storage class specified in postgres-manifest. Without any specific selector, Kubernetes will offer any 3 of the above 10 PVs.
What we want is to be able to target the 3 PVs that were created specifically for Postgres, and not pick any others.
I don't see how that's possible with the current parameters available in postgres-manifest.

[DrissiReda]

If you have 3 PVs created specifically for postgres, then why not give them their own storage class? Isn't that what storage class is for?

[curionim]

Hi,
yes we could do that, but storage class is used mostly to indicate the type of storage, not to select PVs.
In AWS storage class is useful to create dynamic PVs.
In on prem deployment we use the storage class to indicate that PVs are static.

The better way to address our use case would be to have a selector, like in a standard PVC via selector.matchLabels.
In postgres-manifest selector is supported for additionalVolumes, so why not use it for the primary volume as well?

[MatthiasLohr]

I would here agree with @curionim. Selectors for PersistentVolumeClaims are the preferred kubernetes way to select, which volume exactly to chose (and yes, StorageClass ist class of the storage, not the instance of the storage, e.g. a volume). Kubernetes already has everything build in, just the operator does not offer to use this feature. E.g. allowing to specify the matchLabels in the cluster definition would be it.

References:

• spec.selector in PersistentVolumeClaimTemplate -- https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.20/#persistentvolumeclaim-v1-core
• spec.volumeClaimTemplates.spec.selector in StatefulSet -- https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.20/#statefulset-v1-apps

[kkendzia]

This is something I'm really looking for. We are currently in a migration process and want to use a postgres operator. A missing selector field is, unfortunately, not suitable for us (also on-premise).

[MatthiasLohr]

@Jan-M, since several people now elaborated on this, how can be proceed on this? You're right, Kubernetes provide something for this (selectors), but postgres-operator does not (yet?) allow for setting this. But I guess that should be easy to implement?

[kkendzia]

I think changing

postgres-operator/pkg/cluster/k8sres.go

Line 1243 in e398cf8

if volumeClaimTemplate, err = generatePersistentVolumeClaimTemplate(spec.Volume.Size,

, respective

postgres-operator/pkg/cluster/k8sres.go

Line 1510 in e398cf8

Spec: v1.PersistentVolumeClaimSpec{

and the matching CRD should be enough - but I've never developed go or anything in k8s environment.

[jcrood]

I'm pretty much in the same boat, dealing with static PVs pointing to an NFS server. Currently I work around the issue by creating a new StorageClass per pg cluster that I spin up, but I'd love to use a normal selector. If no one else is working on this yet, I'm more than willing to take a stab at adding this.