- Deploy and Configure MongoDB Database Resources >
- Deploy a MongoDB Database Resource >
- Deploy a Replica Set
Deploy a Replica Set¶
On this page
Note
At any place on this page that says Ops Manager, you can substitute Cloud Manager.
Important
- You can use the Kubernetes Operator to deploy MongoDB resources with Ops Manager version 4.0.11 or later and Cloud Manager.
- You can’t use the Kubernetes Operator to deploy MongoDB resources to Atlas.
A replica set is a group of MongoDB deployments that maintain the same data set. Replica sets provide redundancy and high availability and are the basis for all production deployments.
To learn more about replica sets, see the Replication Introduction in the MongoDB manual.
Use this procedure to deploy a new replica set that Ops Manager manages. After deployment, use Ops Manager to manage the replica set, including such operations as adding, removing, and reconfiguring members.
Prerequisites¶
To deploy a replica set using an object, you need to complete the following procedures:
Considerations¶
Starting in MongoDB Enterprise Kubernetes Operator version 1.3.0, you can only have one MongoDB resource per project. To learn how to migrate your project to a single-cluster configuration, see Migrate to One Resource per Project (Required for Version 1.3.0).
Deploy a Replica Set¶
Copy the highlighted section of this replica set resource.¶
Change the highlighted settings of this YAML file to match your desired replica set configuration.
Paste the copied example to create a new replica set resource.¶
Open your preferred text editor and paste the object specification into a new text file.
Change the highlighted settings to your preferred values.¶
Key | Type | Description | Example |
---|---|---|---|
metadata.name |
string | Label for this Kubernetes replica set object. Resource names must be 44 characters or less. See also
|
myproject |
spec.members |
integer | Number of members of the replica set. | 3 |
spec.version |
string | Version of MongoDB that this replica set should run. The format should be Important Ensure that you choose a compatible MongoDB Server version. Compatible versions differ depending on the base image that the MongoDB database resource uses. To learn more about MongoDB versioning, see MongoDB Versioning in the MongoDB Manual. |
3.6.7 |
string | Name of the ConfigMap with the Ops Manager connection
configuration. The
Value must match namespace and name of ConfigMap This value must match the namespace in which you created the Ops Manager project ConfigMap. Operator manages changes to the ConfigMap The Kubernetes Operator tracks any changes to the ConfigMap and reconciles the state of the MongoDB Kubernetes resource. |
<myconfigmap> |
|
spec.credentials |
string | Name of the Kubernetes secret you created as Ops Manager API authentication credentials for the Kubernetes Operator to communicate with Ops Manager. Value must use namespace and name of Secret This value must match the namespace in which you created the
secret and the Operator manages changes to the Secret The Kubernetes Operator tracks any changes to the Secret and reconciles the state of the MongoDB Kubernetes resource. |
<mycredentials> |
spec.type |
string | Type of MongoDB Kubernetes resource to create. | ReplicaSet |
spec.persistent |
string | Optional. Flag indicating if this MongoDB Kubernetes resource should use Persistent Volumes for storage. Persistent volumes are not deleted when the MongoDB Kubernetes resource is stopped or restarted. If this value is To change your Persistent Volume Claims configuration, configure the following collections to meet your deployment requirements:
Warning Your containers must have permissions to write to your Persistent Volume.
The Kubernetes Operator sets Note If you do not use Persistent Volumes, the Disk Usage and Disk IOPS charts cannot be displayed in either the Processes tab on the Deployment page or in the Metrics page when reviewing the data for this deployment. |
true |
Add any additional accepted settings for a replica set deployment.¶
You can also add any of the following optional settings to the object specification file for a replica set deployment:
spec.additionalMongodConfig
spec.backup.mode
spec.clusterDomain
spec.featureCompatibilityVersion
spec.logLevel
spec.podSpec.persistence.single
spec.podSpec.persistence.multiple.data
spec.podSpec.persistence.multiple.journal
spec.podSpec.persistence.multiple.logs
spec.podSpec.podAffinity
spec.podSpec.podAntiAffinityTopologyKey
spec.podSpec.nodeAffinity
spec.podSpec.podTemplate.metadata
spec.podSpec.podTemplate.spec
Warning
You must set spec.clusterDomain
if your Kubernetes cluster has
a default domain
other than the default cluster.local
. If you neither use the
default nor set the spec.clusterDomain
option, the
Kubernetes Operator might not function as expected.
Save this replica set config file with a .yaml
extension.¶
Start your replica set deployment.¶
Invoke the following Kubernetes command to create your replica set:
Track the status of your replica set deployment.¶
To check the status of your MongoDB Kubernetes resource, invoke the following command:
The -w
flag means “watch”. With the “watch” flag set, the output
refreshes immediately when the configuration changes until the status phase
achieves the Running
state.
See Troubleshoot the Kubernetes Operator for information about the resource deployment statuses.
Enable External Access for a Replica Set¶
Deploy a replica set with the Kubernetes Operator.¶
If you haven’t deployed a replica set, follow the instructions to deploy one.
You must enable TLS for the replica set with the
spec.security.tls.enabled
setting. The replica set must use
a custom certificate stored with spec.security.tls.ca
.
Add Subject Alternate Names to your TLS certificates.¶
Add each external DNS name to the certificate SAN.
Discover the dynamically assigned NodePorts.¶
Discover the dynamically assigned NodePorts:
NodePorts range from 30000 to 32767, inclusive.
Open your replica set resource YAML file.¶
Copy the highlighted section of this replica set resource.¶
Change the highlighted settings of this YAML file to match your desired replica set configuration.
Paste the copied example section into your existing replica set resource.¶
Open your preferred text editor and paste the object specification
at the end of your resource file in the spec
section.
Change the highlighted settings to your preferred values.¶
Key | Type | Necessity | Description | Example |
---|---|---|---|---|
spec.security.tls |
boolean | Optional | Set this value to By default, Kubernetes Operator requires hosts to use and accept TLS encrypted connections. Note To connect to a replica set from outside Kubernetes, set this
value to |
true |
spec.connectivity |
collection | Conditional | Add this parameter and values if you need your database to be accessed outside of Kubernetes. This setting allows you to provide different DNS settings within the Kubernetes cluster and to the Kubernetes cluster. The Kubernetes Operator uses split horizon DNS for replica set members. This feature allows communication both within the Kubernetes cluster and from outside Kubernetes. You may add multiple external mappings per host. Split Horizon Requirements
|
See Setting |
Confirm the external hostnames and NodePort values in your replica set resource.¶
Confirm that the external hostnames in the
spec.connectivity.replicaSetHorizons
setting are correct.
External hostnames should match the DNS names of Kubernetes worker nodes. These can be any nodes in the Kubernetes cluster. nodes do internal routing if the pod is run on another node.
Set the ports in spec.connectivity.replicaSetHorizons
to
the NodePort values that you discovered.
Example
Save your replica set config file.¶
Update and restart your replica set deployment.¶
Invoke the following Kubernetes command to update and restart your replica set:
Test the connection to the replica set.¶
Warning
Don’t use the --sslAllowInvalidCertificates
flag in production.
In production, share the Kubernetes CA files with client tools
or applications.
If the connection succeeds, you should see: