Skip to content
logo
Percona Operator for MongoDB
Add sidecar containers
Initializing search
    percona/k8spsmdb-docs
    percona/k8spsmdb-docs
    • Welcome
      • System requirements
      • Design and architecture
      • Comparison with other solutions
      • Install with Helm
      • Install with kubectl
      • Install on Minikube
      • Install on Google Kubernetes Engine (GKE)
      • Install on Amazon Elastic Kubernetes Service (AWS EKS)
      • Install on Microsoft Azure Kubernetes Service (AKS)
      • Generic Kubernetes installation
      • Install on OpenShift
      • Application and system users
      • Changing MongoDB options
      • Anti-affinity and tolerations
      • Labels and annotations
      • Exposing the cluster
      • Local storage support
      • Arbiter and non-voting nodes
      • MongoDB sharding
      • Transport encryption (TLS/SSL)
      • Data at rest encryption
      • Telemetry
        • About backups
        • Configure storage for backups
        • Making scheduled backups
        • Making on-demand backup
        • Storing operations logs for point-in-time recovery
        • Restore from a previously saved backup
        • Delete the unneeded backup
      • Upgrade MongoDB and the Operator
      • Horizontal and vertical scaling
      • Multi-cluster and multi-region deployment
      • Monitor with Percona Monitoring and Management (PMM)
      • Add sidecar containers
        • Adding a sidecar container
        • Getting shell access to a sidecar container
        • Mount volumes into sidecar containers
          • Persistent Volume
          • Secret
          • configMap
      • Restart or pause the cluster
      • Debug and troubleshoot
      • OpenLDAP integration
      • How to use private registry
      • Creating a private S3-compatible cloud for backups
      • Restore backup to a new Kubernetes-based environment
      • How to use backups to move the external database to Kubernetes
      • Install Percona Server for MongoDB in multi-namespace (cluster-wide) mode
      • Upgrading Percona Server for MongoDB manually
      • Custom Resource options
      • Percona certified images
      • Operator API
      • Frequently asked questions
      • Old releases (documentation archive)
      • Release notes index
      • Percona Operator for MongoDB 1.14.0 (2023-03-13)
      • Percona Operator for MongoDB 1.13.0 (2022-09-15)
      • Percona Operator for MongoDB 1.12.0 (2022-05-05)
      • Percona Distribution for MongoDB Operator 1.11.0 (2021-12-21)
      • Percona Distribution for MongoDB Operator 1.10.0 (2021-09-30)
      • Percona Distribution for MongoDB Operator 1.9.0 (2021-07-29)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.8.0 (2021-05-06)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.7.0 (2021-03-08)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.6.0 (2020-12-22)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.5.0 (2020-09-07)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.4.0 (2020-03-31)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.3.0 (2019-12-11)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.2.0 (2019-09-20)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.1.0 (2019-07-15)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.0.0 (2019-05-29)

    • Adding a sidecar container
    • Getting shell access to a sidecar container
    • Mount volumes into sidecar containers
      • Persistent Volume
      • Secret
      • configMap

    Using sidecar containers¶

    The Operator allows you to deploy additional (so-called sidecar) containers to the Pod. You can use this feature to run debugging tools, some specific monitoring solutions, etc.

    Note

    Custom sidecar containers can easily access other components of your cluster. Therefore they should be used carefully and by experienced users only.

    Adding a sidecar container¶

    You can add sidecar containers to Percona Distribution for MongoDB Replica Set, Config Servers, and mongos Pods. Just use sidecars subsection in the replsets, sharding.configsvrReplSet, and sharding.mongos of the deploy/cr.yaml configuration file. In this subsection, you should specify the name and image of your container and possibly a command to run:

    spec:
      replsets:
        ....
        sidecars:
        - image: busybox
          command: ["/bin/sh"]
          args: ["-c", "while true; do echo echo $(date -u) 'test' >> /dev/null; sleep 5; done"]
          name: rs-sidecar-0
        ....
    

    Apply your modifications as usual:

    $ kubectl apply -f deploy/cr.yaml
    

    Running kubectl describe command for the appropriate Pod can bring you the information about the newly created container:

    $ kubectl describe pod my-cluster-name-rs0-0
    
    Expected output
    ....
    Containers:
    ....
    rs-sidecar-0:
      Container ID:  docker://f0c3437295d0ec819753c581aae174a0b8d062337f80897144eb8148249ba742
      Image:         busybox
      Image ID:      docker-pullable://busybox@sha256:139abcf41943b8bcd4bc5c42ee71ddc9402c7ad69ad9e177b0a9bc4541f14924
      Port:          <none>
      Host Port:     <none>
      Command:
        /bin/sh
      Args:
        -c
        while true; do echo echo $(date -u) 'test' >> /dev/null; sleep 5; done
      State:          Running
        Started:      Thu, 11 Nov 2021 10:38:15 +0300
      Ready:          True
      Restart Count:  0
      Environment:    <none>
      Mounts:
        /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-fbrbn (ro)
    ....
    

    Getting shell access to a sidecar container¶

    You can login to your sidecar container as follows:

    $ kubectl exec -it my-cluster-name-rs0-0 -c rs-sidecar-0 -- sh
    / #
    

    Mount volumes into sidecar containers¶

    It is possible to mount volumes into sidecar containers.

    Following subsections describe different volume types, which were tested with sidecar containers and are known to work.

    Persistent Volume¶

    You can use Persistent volumes when you need dynamically provisioned storage which doesn’t depend on the Pod lifecycle. To use such volume, you should claim durable storage with persistentVolumeClaim without specifying any non-important details.

    The following example requests 1G storage with sidecar-volume-claim PersistentVolumeClaim, and mounts the correspondent Persistent Volume to the rs-sidecar-0 container’s filesystem under the /volume0 directory:

    ...
    sidecars:
    - image: busybox
      command: ["/bin/sh"]
      args: ["-c", "while true; do echo echo $(date -u) 'test' >> /dev/null; sleep 5; done"]
      name: rs-sidecar-0
      volumeMounts:
      - mountPath: /volume0
        name: sidecar-volume-claim
    sidecarPVCs:
    - apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: sidecar-volume-claim
      spec:
        resources:
          requests:
            storage: 1Gi
        volumeMode: Filesystem
        accessModes:
          - ReadWriteOnce
    

    Note

    Sidecar containers for mongos Pods have limited Persistent volumes support: sharding.mongos.sidecarPVCs option can be used if there is a single mongos in deployment or when ReadWriteMany/ReadOnlyMany access modes are used (but these modes are available not in every storage).

    Secret¶

    You can use a secret volume to pass the information which needs additional protection (e.g. passwords), to the container. Secrets are stored with the Kubernetes API and mounted to the container as RAM-stored files.

    You can mount a secret volume as follows:

    ...
    sidecars:
    - image: busybox
      command: ["/bin/sh"]
      args: ["-c", "while true; do echo echo $(date -u) 'test' >> /dev/null; sleep 5; done"]
      name: rs-sidecar-0
      volumeMounts:
      - mountPath: /secret
        name: sidecar-secret
    sidecarVolumes:
    - name: sidecar-secret
      secret:
        secretName: mysecret
    

    The above example creates a sidecar-secret volume (based on already existing mysecret Secret object) and mounts it to the rs-sidecar-0 container’s filesystem under the /secret directory.

    Note

    Don’t forget you need to create a Secret Object before you can use it.

    configMap¶

    You can use a configMap volume to pass some configuration data to the container. Secrets are stored with the Kubernetes API and mounted to the container as RAM-stored files.

    You can mount a configMap volume as follows:

    ...
    sidecars:
    - image: busybox
      command: ["/bin/sh"]
      args: ["-c", "while true; do echo echo $(date -u) 'test' >> /dev/null; sleep 5; done"]
      name: rs-sidecar-0
      volumeMounts:
      - mountPath: /config
        name: sidecar-config
    sidecarVolumes:
    - name: sidecar-config
      configMap:
        name: myconfigmap
    

    The above example creates a sidecar-config volume (based on already existing myconfigmap configMap object) and mounts it to the rs-sidecar-0 container’s filesystem under the /config directory.

    Note

    Don’t forget you need to create a configMap Object before you can use it.

    Contact Us

    For free technical help, visit the Percona Community Forum.

    To report bugs or submit feature requests, open a JIRA ticket.

    For paid support and managed or consulting services , contact Percona Sales.


    Last update: 2023-03-14
    Percona LLC and/or its affiliates, © 2009 - 2023
    Made with Material for MkDocs

    Cookie consent

    We use cookies to recognize your repeated visits and preferences, as well as to measure the effectiveness of our documentation and whether users find what they're searching for. With your consent, you're helping us to make our documentation better.