You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
This is more of a gathering ideas/or a how-to , instead of a bug/issue.
We need to exclude some PVs, but do want PVCs and STS backed up in our kubernetes clusters.
We have a k8s operator based on operator-sdk written in go, that I am using to apply labels to my CRD resources in Kubernetes.
I just learned that labels are not inherited by PV from its PVC, so I have the label at PVC, but no way to attach that label to PV. (the existing operator does not have access to PV)
I can write a new operator to listen for PV and apply label after checking if label already does not exist, but since PV are at cluster scope, my operator would also need to operate at cluster scope which is deemed too risky and too much control to the operator.
Has anyone come across a similar situation and how/what approach they had to take to solve this ?
Any suggestions would be welcome.
Thanks
The text was updated successfully, but these errors were encountered:
Hi @mithuns - you are correct, labels on a PVC are not passed on to their PV, which can be frustrating in scenarios like this.
You may want to consider using RBAC on the operator/controller that applies the labels to the PVs so that it can only work on PVs, and nothing else. That way, you get the PVs labeled and you're not allowing access to the whole cluster. Hopefully that's more acceptable than allowing fully cluster-scoped permissions.
Also, I don't know if you're aware, but there's a standard label for excluding resources from Velero backups so you wouldn't have to apply your own custom label and exclusion per-backup.
Hi,
This is more of a gathering ideas/or a how-to , instead of a bug/issue.
We need to exclude some PVs, but do want PVCs and STS backed up in our kubernetes clusters.
We have a k8s operator based on operator-sdk written in go, that I am using to apply labels to my CRD resources in Kubernetes.
I just learned that labels are not inherited by PV from its PVC, so I have the label at PVC, but no way to attach that label to PV. (the existing operator does not have access to PV)
I can write a new operator to listen for PV and apply label after checking if label already does not exist, but since PV are at cluster scope, my operator would also need to operate at cluster scope which is deemed too risky and too much control to the operator.
Has anyone come across a similar situation and how/what approach they had to take to solve this ?
Any suggestions would be welcome.
Thanks
The text was updated successfully, but these errors were encountered: