search

zalando / postgres-operator

Postgres operator creates and manages PostgreSQL clusters running in Kubernetes
https://postgres-operator.readthedocs.io/
MIT License
4.3k stars 974 forks source link

Clearer way to map PVCs to PVs for Static Volumes #1131

Open curionim opened 4 years ago

curionim commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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:

kkendzia commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

I think changing https://github.com/zalando/postgres-operator/blob/e398cf8c7e7553d00a796cb278e2d22542ba2345/pkg/cluster/k8sres.go#L1243 , respective https://github.com/zalando/postgres-operator/blob/e398cf8c7e7553d00a796cb278e2d22542ba2345/pkg/cluster/k8sres.go#L1510 and the matching CRD should be enough - but I've never developed go or anything in k8s environment.

jcrood commented 3 years ago

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.