Percona MongoDB Operator with PersistentVolumeClaim (on CephFS)

MongoDB Percona Operator for MongoDB
,
1

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:

  • the volumes needs permissions for user id 99 (nobody), so the init container can copy entry and start scripts to the volume. See here init-entrypoint.sh
  • the volumes needs permissions for user id 1001 (mongodb), so the mongodb container has access to the database data directory.
    spec:
  ...
  containers:
  - args:
    - ...
    - --dbpath=/data/db
    - ...
    command:
    - /data/db/ps-entry.sh
  ...

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:

  1. Change the operator so the init container runs as root.
  2. Change the init-entrypoint.sh script so the id of the nobody user can be assigned correctly.
  3. 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

2 Likes
2

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.

2 Likes
3

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

1 Like
4

The source is here: percona-helm-charts/charts/psmdb-db at main · percona/percona-helm-charts · GitHub

So you are looking at the right place :slight_smile:

1 Like
5

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.

1 Like
6

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.

1 Like
7

Maybe I am able to come back in a couple of days to test my changes and create a pull request.

2 Likes