During k8s upgrades (AKS) new C* nodes taking a long time (~10-20 mins) to start which may be down to the mount permission change. Does it make sense for already established servers to skip permission change if root folder already has permission setup correctly?
Here is a security context currently set for C* PODs
Add a new fsGroup default as fsGroupChangePolicy="OnRootMismatch" so the POD startup is expedited as there is no recursive chown operation run required against every file and folder if root folder contains valid permissions.
What is missing?
During k8s upgrades (AKS) new C* nodes taking a long time (~10-20 mins) to start which may be down to the mount permission change. Does it make sense for already established servers to skip permission change if root folder already has permission setup correctly?
Here is a security context currently set for C* PODs
Which is coming from https://github.com/k8ssandra/cass-operator/blob/c273e274310b0b007178ab214b2e32774f3cf819/pkg/reconciliation/construct_statefulset_test.go#L435
Why do we need it?
Add a new fsGroup default as fsGroupChangePolicy="OnRootMismatch" so the POD startup is expedited as there is no recursive chown operation run required against every file and folder if root folder contains valid permissions.
Environment
References
https://kubernetes.io/blog/2020/12/14/kubernetes-release-1.20-fsgroupchangepolicy-fsgrouppolicy/#allow-users-to-skip-recursive-permission-changes-on-mount
┆Issue is synchronized with this Jira Story by Unito ┆Issue Number: K8OP-36