Navigation
This version of the documentation is archived and no longer supported. To learn how to upgrade your version of MongoDB Kubernetes Operator, refer to the upgrade documentation.
  • Reference >
  • MongoDB Enterprise Kubernetes Operator Production Notes

MongoDB Enterprise Kubernetes Operator Production Notes

On this page

This page details system configuration recommendations for the MongoDB Enterprise Kubernetes Operator when running in production.

Ensure Proper Persistence Configuration

You use a Kubernetes Operator to ensure stateful configurations of Kubernetes deployments. The storage of your Kubernetes deployment must persist, so verify that the Persistent Volume Claims are configured to meet your storage needs.

Note

The Kubernetes Operator:

  • Supports mounting storage devices to one or more directories called mount points.
  • Creates one Persistent Volume Claim per MongoDB mount point.
  • Sets the default path in each container to /data.
copy 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-sharded-cluster
spec:
  shardCount: 2
  mongodsPerShardCount: 3
  mongosCount: 2
  configServerCount: 3
  version: 4.0.0
  service: my-service
  featureCompatibilityVersion: "3.6"
  project: my-project
  credentials: my-credentials
  type: ShardedCluster
  persistent: true
  configSrvPodSpec:
    cpu: '0.5'
    memory: 512M
    podAntiAffinityTopologyKey: kubernetes.io/hostname
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: failure-domain.beta.kubernetes.io/zone
  mongosPodSpec:
    cpu: '0.8'
    memory: 1G
    podAntiAffinityTopologyKey: rackId
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  shardPodSpec:
    cpu: '0.6'
    memory: 3G
    persistence:
      multiple:
        data:
          storage: 20G
        logs:
          storage: 4G
          storageClass: standard
    podAntiAffinityTopologyKey: kubernetes.io/hostname

See also

Name Your MongoDB Service with its Purpose

If using your own MongoDB Service, set the spec.service parameter to something that helps you identify this deployment’s purpose.

copy 
1
2
3
4
5
6
7
8
9
apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-replica-set
spec:
  members: 3
  version: 4.0.0
  service: drilling-pumps-geosensors
  featureCompatibilityVersion: "3.6"

Specify Resource Requirements

For the replica sets, sharded clusters, and config servers you create using the Kubernetes Operator, set the resource utilization bounds for both compute and memory. Kubernetes refers to the lower bound of a resource as a request and the upper bound as a limit.

Note

Monitoring tools report the size of the node rather than the actual size of the container.

Example

copy 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-sharded-cluster
spec:
  shardCount: 2
  mongodsPerShardCount: 3
  mongosCount: 2
  configServerCount: 3
  version: 4.0.0
  service: my-service
  featureCompatibilityVersion: "3.6"
  project: my-project
  credentials: my-credentials
  type: ShardedCluster
  persistent: true
  configSrvPodSpec:
    cpu: '0.5'
    memory: 512M
    podAntiAffinityTopologyKey: kubernetes.io/hostname
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: failure-domain.beta.kubernetes.io/zone
  mongosPodSpec:
    cpu: '0.8'
    memory: 1G
    podAntiAffinityTopologyKey: rackId
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  shardPodSpec:
    cpu: '0.6'
    memory: 3G
    persistence:
      multiple:
        data:
          storage: 20G
        logs:
          storage: 4G
          storageClass: standard
    podAntiAffinityTopologyKey: kubernetes.io/hostname

Use Multiple Availability Zones

Set the Kubernetes Operator and StatefulSets to distribute all members of one replica set to different nodes to ensure high availability.

Example

copy 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-sharded-cluster
spec:
  shardCount: 2
  mongodsPerShardCount: 3
  mongosCount: 2
  configServerCount: 3
  version: 4.0.0
  service: my-service
  featureCompatibilityVersion: "3.6"
  project: my-project
  credentials: my-credentials
  type: ShardedCluster
  persistent: true
  configSrvPodSpec:
    cpu: '0.5'
    memory: 512M
    podAntiAffinityTopologyKey: kubernetes.io/hostname
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: failure-domain.beta.kubernetes.io/zone
  mongosPodSpec:
    cpu: '0.8'
    memory: 1G
    podAntiAffinityTopologyKey: rackId
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  shardPodSpec:
    cpu: '0.6'
    memory: 3G
    persistence:
      multiple:
        data:
          storage: 20G
        logs:
          storage: 4G
          storageClass: standard
    podAntiAffinityTopologyKey: kubernetes.io/hostname

Co-locate mongos Pods with Your Applications

The lightweight mongos instance can be run in the same node as your apps using MongoDB. The Kubernetes Operator supports standard Kubernetes node-affinity and node anti-affinity features. Using these features, you can force install the mongos on the same pod as your application.

Example

The podAffinity key determines if an application should be installed on the same pod, node, or data center as another application.

You add a label and value in the spec.template.metadata.labels YAML collection to tag the deployment.

You can then specify which label the mongos uses in the
mongosPodSpec.podAffinity
.requiredDuringSchedulingIgnoredDuringExecution.labelSelector
YAML collection. The matchExpressions collection defines the
label the Operator uses to target on which pod the mongos
should be installed.

In this example, the web-store value for the app key labels the pod on which the web-server is installed. The labelSelector key declares that the mongos app must be installed on the same pod that has its app label set to be In values that include web-store.

copy 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: web-store

mongosPodSpec:
  podAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values:
          - web-store

Manage Multitenancy with Labels

If you need to physically separate different MongoDB resources (such as test and staging environments) or want to place pods on some specific nodes (such as SSD support) use the pod affinity Kubernetes feature.

copy 
1
2
3
4
5
6
7
8
9
mongosPodSpec:
  podAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values:
          - web-store

Enable TLS

The Kubernetes Operator supports TLS encryption. Use TLS with your MongoDB deployment to encrypt your data over the network.

copy 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-tls-enabled-rs
spec:
  type: ReplicaSet
  members: 3
  version: 4.0.4
  project: my-project
  credentials: my-credentials
  security:
    tls:
      enabled: true
  additionalMongodConfig:
    net:
      ssl:
        mode: "preferSSL"

Enable Authentication

The Kubernetes Operator supports X.509 user authentication. You must create an additional CustomResourceDefinition for your MongoDB users and the MongoDB Agents. The Operator generates and distributes the certificate.

Example Deployment CRD

copy 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-tls-enabled-rs
spec:
  type: ReplicaSet
  members: 3
  version: 4.0.4
  project: my-project
  credentials: my-credentials
  security:
    clusterAuthenticationMode: x509
    tls:
      enabled: true

Example User CRD

copy 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
apiVersion: mongodb.com/v1
kind: MongoDBUser
metadata:
  name: user-with-roles
spec:
  username: "CN=mms-user-1,OU=cloud,O=MongoDB,L=New York,ST=New York,C=US"
  db: "$external"
  project: my-project
  roles:
    - db: "admin"
      name: "clusterAdmin"

© MongoDB, Inc 2008-present. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.