- Release Notes for MongoDB Enterprise Kubernetes Operator >
- 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
.
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.
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.
- Set CPU requests and limits to guarantee the CPU allocation and resource reporting.
- Set Memory requests and limits to guarantee the requested memory allocation for the WiredTiger cache and resource reporting.
Note
Monitoring tools report the size of the node rather than the actual size of the container.
Example
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
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.
mongos
uses in themongosPodSpec.podAffinity
.requiredDuringSchedulingIgnoredDuringExecution.labelSelector
matchExpressions
collection defines thelabel
the Operator uses to target on which pod the mongos
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
.
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.
Enable TLS¶
The Kubernetes Operator supports TLS encryption. Use TLS with your MongoDB deployment to encrypt your data over the network.
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.