Deploy and Configure MongoDB Database Resources >
Access Database Resources >
Connect to a MongoDB Database Resource from Outside Kubernetes

Connect to a MongoDB Database Resource from Outside Kubernetes¶

On this page

Prerequisite
Procedure

The following procedure describes how to connect to a MongoDB resource deployed by Kubernetes from outside of the Kubernetes cluster.

Prerequisite¶

For your databases to be accessed outside of Kubernetes, they must run one of the following versions of MongoDB:

3.6.17 or later
4.0.15 or later
4.2.3 or later

Procedure¶

How you connect to a MongoDB resource that the Kubernetes Operator deployed from outside of the Kubernetes cluster depends on the resource.

Standalone
Replica Set
Sharded Cluster

This procedure uses the following example:

copy

---
apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: <my-standalone>
spec:
  version: 4.2.2-ent
  opsManager:
    configMapRef:
      name: <configMap.metadata.name>
            # Must match metadata.name in ConfigMap file
  credentials: <mycredentials>
  type: Standalone
  persistent: true
  exposedExternally: true
...

To connect to your Kubernetes Operator-deployed MongoDB standalone resource from outside of the Kubernetes cluster:

1

Open your standalone resource YAML file.¶

2

Copy the highlighted section of this standalone resource.¶

Change the highlighted settings of this YAML file to match your desired standalone configuration.

---
apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: <my-standalone>
spec:
  version: 4.2.2-ent
  opsManager:
    configMapRef:
      name: <configMap.metadata.name>
            # Must match metadata.name in ConfigMap file
  credentials: <mycredentials>
  type: Standalone
  persistent: true

copy

  exposedExternally: true
...

3

Paste the copied example section into your existing standalone resource.¶

Open your preferred text editor and paste the object specification at the end of your resource file in the spec section.

4

Change the highlighted settings to your preferred values.¶

Key	Type	Necessity	Description	Example
`spec.exposedExternally`	Boolean	Optional	Set this value to `true` to allow external services to connect to the MongoDB deployment. This results in Kubernetes creating a NodePort service.	`true`

5

Save your standalone config file.¶

6

Update and restart your standalone deployment.¶

Invoke the following Kubernetes command to update and restart your standalone:

copy

kubectl apply -f <standalone-conf>.yaml

7

Discover the dynamically assigned NodePorts.¶

Discover the dynamically assigned NodePort:

copy

kubectl get services -n <namespace>

The list output should contain an entry similar to the following:

NAME                      TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)           AGE

<my-standalone>           NodePort    10.102.27.116   <none>        27017:30994/TCP   8m30s

Kubernetes exposes mongod on port 27017 within the Kubernetes container.
The NodePort service exposes the mongod via port 30994. NodePorts range from 30000 to 32767, inclusive.

8

Test the connection to the standalone.¶

To connect to your deployment from outside of the Kubernetes cluster, run the mongod command with the external FQDN of a node as the --host flag.

Example

If a node in the Kubernetes cluster has an external FQDN of ec2-54-212-23-143.us-west-2.compute.amazonaws.com, you can connect to this standalone instance from outside of the Kubernetes cluster using the following command:

mongo --host ec2-54-212-23-143.us-west-2.compute.amazonaws.com --port 30994

Tip

To obtain the external DNS of your Kubernetes cluster, you can run the following command:

copy

kubectl describe nodes

This command displays the external DNS in the Addresses.ExternalDNS section of the output.

Alternatively, you can output the external DNS directly by running:

copy

kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="ExternalDNS")].address }'

Important

This procedure explains the least complicated way to enable external connectivity. Other utilities can be used in production.

To connect to your Kubernetes Operator-deployed MongoDB replica set resource from outside of the Kubernetes cluster:

1

If you haven’t done so already, deploy a replica with the Kubernetes Operator.¶

Follow the instructions to :ref:` deploy a replica set <deploy-replica-set>`. To simplify the configuration, don’t enable TLS with the spec.security.tls.enabled setting.

2

Optional: If you already deployed a replica set with the Kubernetes Operator with TLS enabled, remove the CSRs for each host in your deployment.¶

Invoke the following command to retrieve the CSRs for each host:

copy

kubectl get csr

The command’s output resembles the following:

NAME                                        AGE       REQUESTOR                                                   CONDITION
my-secure-rs-0.mongodb                      33s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved, Issued
my-secure-rs-1.mongodb                      31s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved, Issued
my-secure-rs-2.mongodb                      24s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Approved, Issued

Repeat the following command for each host in your deployment to remove the CSRs:
copy
```
kubectl delete my-secure-rs-0.mongodb
```
Important

Remove only the TLS CSRs. Don’t remove X.509 or any other CSRs.

3

Create a NodePort for each pod.¶

Invoke the following commands to create the NodePorts:

copy

kubectl expose pod/<my-replica-set>-0 --type="NodePort" --port 27017
kubectl expose pod/<my-replica-set>-1 --type="NodePort" --port 27017
kubectl expose pod/<my-replica-set>-2 --type="NodePort" --port 27017

4

Discover the dynamically assigned NodePorts.¶

Discover the dynamically assigned NodePorts:

copy

$ kubectl get svc | grep <my-replica-set>
<my-replica-set>-0                      NodePort    172.30.39.228    <none>        27017:30907/TCP              16m
<my-replica-set>-1                      NodePort    172.30.185.136   <none>        27017:32350/TCP              16m
<my-replica-set>-2                      NodePort    172.30.84.192    <none>        27017:31185/TCP              17m
<my-replica-set>-svc                    ClusterIP   None             <none>        27017/TCP                    38m

NodePorts range from 30000 to 32767, inclusive.

5

Open your replica set resource YAML file.¶

6

Copy the highlighted section of this replica set resource.¶

Change the highlighted settings of this YAML file to match your desired replica set configuration.

---
apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: <my-replica-set>
spec:
  members: 3
  version: 4.2.2-ent
  type: ReplicaSet
  opsManager:
    configMapRef:
      name: <configMap.metadata.name>
  credentials: <mycredentials>
  persistent: true

copy

  security:
    tls:
      enabled: true
  connectivity:
    replicaSetHorizons:
      - "example-website": "web1.example.com:10017"
      - "example-website": "web2.example.com:10017"
      - "example-website": "web3.example.com:10017"
...

7

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.

8

Change the highlighted settings to your preferred values.¶

Key Type Necessity Description Example

spec.security.tls

.enabled

boolean

Optional

Set this value to true to enable TLS on the MongoDB deployment.

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.

true

spec.connectivity

.replicaSetHorizons

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

Make sure that each value in this array is unique.
Make sure that the number of entries in this array matches the value given in spec.members.
Set the spec.security.tls.enabled to true to enable TLS. This method to use split horizons requires the Server Name Indication extension of the TLS protocol.

See Setting

9

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

copy

  security:
    tls:
      enabled: true
  connectivity:
    replicaSetHorizons:
      - "example-website": "web1.example.com:30907"
      - "example-website": "web2.example.com:32350"
      - "example-website": "web3.example.com:31185"
...

10

Save your replica set config file.¶

11

Update and restart your replica set deployment.¶

Invoke the following Kubernetes command to update and restart your replica set:

copy

kubectl apply -f <replica-set-conf>.yaml

12

Check the status of your deployment.¶

The Kubernetes Operator creates the MongoDB resources and requests the Kubernetes CA to approve the database host’s certificates. Run the following command to verify that the certificates are pending approval:

copy

kubectl get mdb <resource-name> -o yaml -w

The status field of the output should resemble the following:

status:
  lastTransition: 2019-05-01T15:36:59Z
  message: Not all certificates have been approved by Kubernetes CA
  phase: Failed
  type: ""
  version: ""

If you do not see the status.message above, see Troubleshooting the Kubernetes Operator to help diagnose the issue.

13

Retrieve the CSRs for each host and agent in your deployment.¶

Invoke the following command to retrieve the CSRs for each host:

copy

kubectl get csr

The command’s output resembles the following:

NAME                                        AGE       REQUESTOR                                                   CONDITION
my-secure-rs-0.mongodb                      33s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-rs-1.mongodb                      31s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending
my-secure-rs-2.mongodb                      24s       system:serviceaccount:mongodb:mongodb-enterprise-operator   Pending

14

Approve the CSR for each host in your deployment.¶

Using the values returned in the NAME column, approve each certificate from the previous command’s output using the following command:

copy

kubectl certificate approve <NAME>

Example

The following commands approve the CSRs for the replica set example:

copy

kubectl certificate approve my-secure-rs-0.mongodb
kubectl certificate approve my-secure-rs-1.mongodb
kubectl certificate approve my-secure-rs-2.mongodb

kubectl prints a message to the console when a certificate is approved.

15

Test the connection to the replica set.¶

copy

mongo --host <my-replica-set>/web1.example.com:30907,web2.example.com:32350,web3.example.com:31185 --ssl --sslAllowInvalidCertificates

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:

copy

MongoDB Enterprise <my-replica-set>:PRIMARY>

This procedure uses the following example:

Without TLS
With TLS

---
apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: <my-sharded-cluster>
spec:
  version: 4.2.2-ent
  opsManager:
    configMapRef:
      name: <configMap.metadata.name>
            # Must match metadata.name in ConfigMap file
  shardCount: 2
  mongodsPerShardCount: 3
  mongosCount: 2
  configServerCount: 3
  credentials: my-secret
  type: ShardedCluster
  persistent: true
  exposedExternally: true
...

---
apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: <my-sharded-cluster>
spec:
  version: 4.2.2-ent
  opsManager:
    configMapRef:
      name: <configMap.metadata.name>
            # Must match metadata.name in ConfigMap file
  shardCount: 2
  mongodsPerShardCount: 3
  mongosCount: 2
  configServerCount: 3
  credentials: my-secret
  type: ShardedCluster
  persistent: true
  exposedExternally: true
  security:
    tls:
      enabled: true
      additionalCertificateDomains:
        - "additional-cert-test.com"
...

To connect to your Kubernetes Operator-deployed MongoDB sharded cluster resource from outside of the Kubernetes cluster:

1

Open your sharded cluster resource YAML file.¶

2

Copy the highlighted section of this sharded cluster resource.¶

Change the highlighted settings of this YAML file to match your desired sharded cluster configuration.

Without TLS
With TLS

---
apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: <my-sharded-cluster>
spec:
  version: 4.2.2-ent
  opsManager:
    configMapRef:
      name: <configMap.metadata.name>
            # Must match metadata.name in ConfigMap file
  shardCount: 2
  mongodsPerShardCount: 3
  mongosCount: 2
  configServerCount: 3
  credentials: my-secret
  type: ShardedCluster
  persistent: true

copy

  exposedExternally: true
...

---
apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: <my-sharded-cluster>
spec:
  version: 4.2.2-ent
  opsManager:
    configMapRef:
      name: <configMap.metadata.name>
            # Must match metadata.name in ConfigMap file
  shardCount: 2
  mongodsPerShardCount: 3
  mongosCount: 2
  configServerCount: 3
  credentials: my-secret
  type: ShardedCluster
  persistent: true

copy

  exposedExternally: true
  security:
    tls:
      enabled: true
      additionalCertificateDomains:
        - "additional-cert-test.com"
...

3

Paste the copied example section into your existing sharded cluster resource.¶

Open your preferred text editor and paste the object specification at the end of your resource file in the spec section.

4

Change the highlighted settings to your preferred values.¶

Without TLS
With TLS

Key	Type	Necessity	Description	Example
`spec.exposedExternally`	Boolean	Optional	Set this value to `true` to allow external services to connect to the MongoDB deployment. This results in Kubernetes creating a NodePort service.	`true`

Key Type Necessity Description Example

spec.exposedExternally Boolean Optional Set this value to true to allow external services to connect to the MongoDB deployment. This results in Kubernetes creating a NodePort service. true

spec.security

.tls.enabled

boolean

Optional

If this value is true, TLS is enabled on the MongoDB deployment.

By default, Kubernetes Operator requires hosts to use and accept TLS encrypted connections.

true

spec.security.tls

.additionalCertificateDomains

collection

Optional

List of every domain that should be added to TLS certificates to each pod in this deployment. When you set this parameter, every CSR that the Kubernetes Operator transforms into a TLS certificate includes a SAN in the form

<pod
name>.<additional cert domain>

.

true

5

Save your sharded cluster config file.¶

6

Update and restart your sharded cluster deployment.¶

Invoke the following Kubernetes command to update and restart your sharded cluster:

copy

kubectl apply -f <sharded-cluster-conf>.yaml

7

Discover the dynamically assigned NodePorts.¶

Discover the dynamically assigned NodePort:

copy

kubectl get services -n <namespace>

The list output should contain an entry similar to the following:

NAME                      TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)           AGE

<my-sharded cluster>      NodePort    10.106.44.30    <none>        27017:30078/TCP   10s

Kubernetes exposes mongod on port 27017 within the Kubernetes container.
The NodePort service exposes the mongod via port 30078. NodePorts range from 30000 to 32767, inclusive.

8

Test the connection to the sharded cluster.¶

To connect to your deployment from outside of the Kubernetes cluster, run the mongod command with the external FQDN of a node as the --host flag.

Example

If a node in the Kubernetes cluster has an external FQDN of ec2-54-212-23-143.us-west-2.compute.amazonaws.com, you can connect to this sharded cluster instance from outside of the Kubernetes cluster using the following command:

mongo --host ec2-54-212-23-143.us-west-2.compute.amazonaws.com --port 30078

Tip

To obtain the external DNS of your Kubernetes cluster, you can run the following command:

copy

kubectl describe nodes

This command displays the external DNS in the Addresses.ExternalDNS section of the output.

Alternatively, you can output the external DNS directly by running:

copy

kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="ExternalDNS")].address }'

← Connect to a MongoDB Database Resource from Inside Kubernetes Modify Ops Manager or MongoDB Kubernetes Resource Containers →