Description
I like to deploy a 3 node replicaset of MongoDB instances with PersistentVolumeClaims.
Problem
The psmdb-operator creates all resources correctly and looks good. When the init container starts, it will fail with the following error:
$ kubectl logs mongodb-base-mongodb-base-0 -c mongo-init
++ id -u
++ id -g
+ install -o 99 -g 99 -m 0755 -D /ps-entry.sh /data/db/ps-entry.sh
install: cannot create regular file '/data/db/ps-entry.sh': Permission denied
The problem is, the volume is owned by “root”.
Trying to solve the problem, I found these issues:
From my current point of view, there is no way the MongoDB will ever start working with only the operator.
How can I change the CephFS permissions with the Percona MongoDB Operator to use PersistentVolumeClaims?
I worked around the problem by changing the permissions of the volume to:
chown 1001:99 /data/db
chmod 775 /data/db
Solution
Maybe I am doing something completely wrong, so please tell me if I am wrong.
My solution would be:
- Change the operator so the init container runs as root.
- Change the
init-entrypoint.sh script so the id of the nobody user can be assigned correctly.
- Add to the
init-entrypoint.sh script a chown and chmod command like I mentioned above.
If this is correct, I can create a Percona Jira issue. I just want to know before, if this is the correct approach or I am wrong from the beginning.
Environment:
- Kubernetes 1.21
- psmdb-operator 1.9.0 (installed via helm)
- psmdb-db 1.9.0 (installed via helm)
Thanks!
Edit: Format
Hello @Johannes_Petz ,
I don’t have ceph in front of me, but I have a hunch that securityContext might solve the problem here.
Read more here: Configure a Security Context for a Pod or Container | Kubernetes
And you can use it with the Operator as well under spec.replsets..securityContext.
Seems we don’t have it documented. Will fix.
Hello @Sergey_Pronin ,
thank you for your answer.
I tried to create a psmdb with containerSecurityContext and podSecurityContext.
replsets:
- name: mongodb-set
size: 3
containerSecurityContext:
runAsUser: 1001
runAsGroup: 1001
fsGroup: 1001
and the second try
replsets:
- name: mongodb-set
size: 3
podSecurityContext:
runAsUser: 1001
runAsGroup: 1001
fsGroup: 1001
Before each try I deleted the whole namespace. So this were clear installs.
Unfortunately it did not work.
This is the result PerconaServerMongoDB resource (got it with helm dry-run):
apiVersion: psmdb.percona.com/v1-9-0
kind: PerconaServerMongoDB
metadata:
...
spec:
...
replsets:
- name: mongodb-set
size: 3
affinity:
antiAffinityTopologyKey: kubernetes.io/hostname
podDisruptionBudget:
maxUnavailable: 1
expose:
enabled: true
exposeType:
arbiter:
enabled: false
size: 1
affinity:
antiAffinityTopologyKey: kubernetes.io/hostname
resources:
limits:
cpu: 300m
memory: 0.5G
requests:
cpu: 300m
memory: 0.5G
volumeSpec:
persistentVolumeClaim:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
storageClassName: default
...
I cannot find the source of psmdb-db helm chart (Percona Helm Charts | percona-helm-charts).
But if I take a look at the helm chart template there is the securityContext pattern missing. (
cluster.yaml.txt )
I will now try to use the resource instead of the helm chart as dependency. I think this should work.
If you send me a link to the helm chart source for psmdb I could create a merge request or have a deeper look.
Johannes
As I thought, there is no securityContext in the charts replset configuration:
So the operator has an option for security context and would make use of it, but the psmdb chart has no such configuration.
It should be quite an easy pull request to add it. We have a global task to catch up helm chart with CR options, but it will not happen overnight.
Maybe I am able to come back in a couple of days to test my changes and create a pull request.