Custom initContainers with custom securityContext for PXC pods
Description
Environment
Activity

Vladislav Gusev November 1, 2024 at 9:05 AM
I just want to change permissions because Kubernetes doesn’t honour fsGroupChangePolicy
in some CSI or PV setups.

Slava Sarzhan November 1, 2024 at 7:58 AM
Hi
What do you think would be the best way to introduce a customisation option for initContainer to be able to workaround similar problems without using a custom image? This custom image still needs to be based on percona-xtradb-cluster-operator image and contain pitr and peer-list binaries…
Could you please provide a more detailed description of what you want to work around? Do you want to install additional tools or just change permissions?

Vladislav Gusev September 25, 2024 at 10:54 AM
What do you think would be the best way to introduce a customisation option for initContainer to be able to workaround similar problems without using a custom image? This custom image still needs to be based on percona-xtradb-cluster-operator image and contain pitr and peer-list binaries…
I thought about several ways to do this:
Add customInitContainer option, as described in the task (complexity ***)
Add customisation for initContainer command. Currently, it executes only “/pxc-init-entrypoint.sh” unconditionally , or other hardcoded commands for different containers (complexity **)
Add support for custom hookscript in initContainer entrypoints, the same way it’s done for pxc-entrypoint (but without CR modification and configmap creation by operator, just using optional configmap). This would be enough on top of the custom containerSecurityContext. (complexity *)

Slava Sarzhan September 24, 2024 at 8:47 AM
new section was added
we need to add it to helm and please add it to our e2e test as well

Slava Sarzhan September 24, 2024 at 8:46 AM
thank you for improvement. We will include this fix in PXCO 1.16.0
Details
Details
Assignee

Reporter

Needs QA
Needs Doc
Fix versions
Priority
Smart Checklist
Open Smart Checklist
Smart Checklist

My team is evaluating a Percona Operator. We've faced an issue when it needs to create a cluster in a custom Kubernetes configuration using pre-created NFS PVs.
In such a setup, the bug is triggered, as described in : fsGroup in podSecurityContext doesn't work; therefore
/var/lib/mysql
permissions must be changed using custom initContainer with chown started withrunAsUser 0
Related configuration:
Without such a container cluster creation fails, pxc-init couldn't finish successfully:
This directory permission should be changed to 1001 here either manually or by initContainer.
It would be nice to have the option to specify custom initContainers with a custom security context, which differs from pods security context with two options for these initContainers:
Run before pxc-init to be able to fix such issues
Run after pxc-init as a native sidecar container ( )