Connect to a MongoDB Database Resource from Outside Kubernetes

Deploy a standalone resource with the Kubernetes Operator.

If you haven't deployed a standalone resource, follow the instructions to deploy one.

This procedure uses the following example:

20
---
21
apiVersion: mongodb.com/v1
22
kind: MongoDB
23
metadata:
24
  name: <my-standalone>
25
spec:
26
  version: "4.2.2-ent"
27
  opsManager:
28
    configMapRef:
29
      name: <configMap.metadata.name>
30
            # Must match metadata.name in ConfigMap file
31
  credentials: <mycredentials>
32
  type: Standalone
33
...

Create an external service for the MongoDB Pod.

To connect to your standalone resource from an external resource, configure the spec.externalAccess setting:

externalAccess: {}

This setting instructs the Kubernetes Operator to create an external LoadBalancer service for the MongoDB Pod in your standalone resource. The external service provides an entry point for external connections. Adding this setting with no values creates an external service with the following default values:

Optionally, if you need to add values to the service or override the default values, specify:

• Annotations specific to your cloud provider, in spec.externalAccess.externalService.annotations

• Overrides for the service specification, in spec.externalAccess.externalService.spec.

For example, the following settings override the default values for the external service to configure your standalone resource to create NodePort services that expose the MongoDB Pod:

externalAccess:
  externalService:
    annotations:
      # cloud-specific annotations for the service
    spec:
      type: NodePort # default is LoadBalancer
      port: 27017
      # you can specify other spec overrides if necessary

Verify the external services.

In your standalone resource, run the following command to verify that the Kubernetes Operator created the external service for your deployment.

$ kubectl get services

The command returns a list of services similar to the following output. For each database Pod in the cluster, the Kubernetes Operator creates an external service named <pod-name>-0-svc-external. This service is configured according to the values and overrides you provide in the external service specification.

NAME                                  TYPE         CLUSTER-IP   EXTERNAL-IP       PORT(S)           AGE
<my-standalone>-0-svc-external   LoadBalancer   10.102.27.116    <lb-ip-or-fqdn>   27017:27017/TCP    8m30s

Depending on your cluster configuration or cloud provider, the IP address of the LoadBalancer service is an externally accessible IP address or FQDN. You can use the IP address or FQDN to route traffic from your external domain.

Test the connection to the standalone resource.

To connect to your deployment from outside of the Kubernetes cluster, use the MongoDB Shell (mongosh) and specify the MongoDB Pod address that you've exposed through the external domain.

mongosh "mongodb://<my-standalone>.<external-domain>"

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 by providing a value for the spec.security.certsSecretPrefix setting. The replica set must use a custom CA certificate stored with spec.security.tls.ca.

Create an external service for the MongoDB Pods.

To connect to your replica set from an external resource, configure the spec.externalAccess setting:

externalAccess: {}

This setting instructs the Kubernetes Operator to create an external LoadBalancer service for the MongoDB Pods in your replica set. The external service provides an entry point for external connections. Adding this setting with no values creates an external service with the following default values:

Optionally, if you need to add values to the service or override the default values, specify:

• Annotations specific to your cloud provider, in spec.externalAccess.externalService.annotations

• Overrides for the service specification, in spec.externalAccess.externalService.spec.

For example, the following settings override the default values for the external service to configure your replica set to create NodePort services that expose the MongoDB Pods:

externalAccess:
  externalService:
    annotations:
      # cloud-specific annotations for the service
    spec:
      type: NodePort # default is LoadBalancer
      port: 27017
      # you can specify other spec overrides if necessary

Add Subject Alternate Names to your TLS certificates.

Add each external DNS name to the certificate SAN.

Verify the external services.

In your replica set, run the following command to verify that the Kubernetes Operator created the external service for your deployment.

$ kubectl get services

The command returns a list of services similar to the following output. For each database Pod in the cluster, the Kubernetes Operator creates an external service named <pod-name>-<pod-idx>-svc-external. This service is configured according to the values and overrides you provide in the external service specification.

NAME                                  TYPE         CLUSTER-IP   EXTERNAL-IP       PORT(S)           AGE
<my-replica-set>-0-svc-external   LoadBalancer   10.102.27.116    <lb-ip-or-fqdn>   27017:27017/TCP    8m30s

Depending on your cluster configuration or cloud provider, the IP address of the LoadBalancer service is an externally accessible IP address or FQDN. You can use the IP address or FQDN to route traffic from your external domain.

Open your replica set resource YAML file.

Copy the sample replica set resource.

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

1
---
2
apiVersion: mongodb.com/v1
3
kind: MongoDB
4
metadata:
5
  name: <my-replica-set>
6
spec:
7
  members: 3
8
  version: "4.2.2-ent"
9
  type: ReplicaSet
10
  opsManager:
11
    configMapRef:
12
      name: <configMap.metadata.name>
13
  credentials: <mycredentials>
14
  persistent: true

15
  security:
16
    tls:
17
      enabled: true
18
  connectivity:
19
    replicaSetHorizons:
20
      - "example-website": "web1.example.com:30907"
21
      - "example-website": "web2.example.com:32350"
22
      - "example-website": "web3.example.com:31185"
23
...

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.

Confirm the external hostnames and external service 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. Kubernetes nodes use internal routing if the pod runs on another node.

Set the ports in spec.connectivity.replicaSetHorizons to the external service values.

15
  security:
16
    tls:
17
      enabled: true
18
  connectivity:
19
    replicaSetHorizons:
20
      - "example-website": "web1.example.com:30907"
21
      - "example-website": "web2.example.com:32350"
22
      - "example-website": "web3.example.com:31185"
23
...

Save your replica set config file.

Update and restart your replica set deployment.

In any directory, invoke the following Kubernetes command to update and restart your replica set:

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

Test the connection to the replica set.

In the development environment, for each host in a replica set, run the following command:

mongosh --host <my-replica-set>/web1.example.com \
      --port 30907
      --ssl \
      --sslAllowInvalidCertificates

In production, for each host in a replica set, specify the TLS certificate and the CA to securely connect to client tools or applications:

mongosh --host <my-replica-set>/web1.example.com \
  --port 30907 \
  --tls \
  --tlsCertificateKeyFile server.pem \
  --tlsCAFile ca-pem

If the connection succeeds, you should see:

Enterprise <my-replica-set> [primary]

Deploy a sharded cluster with the Kubernetes Operator.

If you haven't deployed a sharded cluster, follow the instructions to deploy one.

You must enable TLS for the sharded cluster by configuring the following settings:

Create an external service for the mongos Pods.

To connect to your sharded cluster from an external resource, configure the spec.externalAccess setting:

externalAccess: {}

This setting instructs the Kubernetes Operator to create an external LoadBalancer service for the mongos Pods in your sharded cluster. The external service provides an entry point for external connections. Adding this setting with no values creates an external service with the following default values:

Optionally, if you need to add values to the service or override the default values, specify:

• Annotations specific to your cloud provider, in spec.externalAccess.externalService.annotations

• Overrides for the service specification, in spec.externalAccess.externalService.spec.

For example, the following settings override the default values for the external service to configure your sharded cluster to create NodePort services that expose the mongos Pods:

externalAccess:
  externalService:
    annotations:
      # cloud-specific annotations for the service
    spec:
      type: NodePort # default is LoadBalancer
      port: 27017
      # you can specify other spec overrides if necessary

Add Subject Alternate Names to your TLS certificates.

Add each external DNS name to the certificate SAN.

Each MongoDB host uses the following SANs:

<my-sharded-cluster>-<shard>-<pod-index>.<external-domain>
<my-sharded-cluster>-config-<pod-index>.<external-domain>
<my-sharded-cluster>-mongos-<pod-index>.<external-domain>

The mongos instance uses the following SAN:

<my-sharded-cluster>-mongos-<pod-index>-svc-external.<external-domain>

Configure the spec.security.tls.additionalCertificateDomains setting similar to the following example. Each TLS certificate that you use must include the corresponding SAN for the shard, config server, or mongos instance. The Kubernetes Operator validates your configuration.

1
---
2
apiVersion: mongodb.com/v1
3
kind: MongoDB
4
metadata:
5
  name: <my-sharded-cluster>
6
spec:
7
  version: "4.2.2-ent"
8
  opsManager:
9
    configMapRef:
10
      name: <configMap.metadata.name>
11
            # Must match metadata.name in ConfigMap file
12
  shardCount: 2
13
  mongodsPerShardCount: 3
14
  mongosCount: 2
15
  configServerCount: 3
16
  credentials: my-secret
17
  type: ShardedCluster
18
  externalAccess: {}
19
  security:
20
    tls:
21
      certsSecretPrefix: <prefix>
22
      additionalCertificateDomains:
23
         - "<external-domain>"
24
...

Verify the external services.

In your sharded cluster, run the following command to verify that the Kubernetes Operator created the external services for your deployment.

$ kubectl get services

The command returns a list of services similar to the following output. For each mongos instance in the cluster, the Kubernetes Operator creates an external service named <pod-name>-<pod-idx>-svc-external. This service is configured according to the values and overrides you provide in the external service specification.

NAME                                              TYPE         CLUSTER-IP     EXTERNAL-IP       PORT(S)           AGE
<my-sharded-cluster>-mongos-0-svc-external    LoadBalancer   10.102.27.116  <lb-ip-or-fqdn>   27017:27017/TCP    8m30s
<my-sharded-cluster>-mongos-1-svc-external    LoadBalancer   10.102.27.116  <lb-ip-or-fqdn>   27017:27017/TCP    8m30s

Depending on your cluster configuration or cloud provider, the IP address of the LoadBalancer service is an externally accessible IP address or FQDN. You can use the IP address or FQDN to route traffic from your external domain. This example has two mongos instances, therefore the Kubernetes Operator creates two external services.

Test the connection to the sharded cluster.

To connect to your deployment from outside of the Kubernetes cluster, use the MongoDB Shell (mongosh) and specify the addresses for the mongos instances that you've exposed through the external domain.

mongosh ""