Exposing cluster nodes with dedicated IP addresses

Using single entry point vs. accessing MongoDB Instances

Percona Operator for Percona Server for MongoDB provides two scenarios for accessing the database.

  1. If :ref`sharding` mode is turned on (default bahaviour), then database cluster runs special mongos Pods - query routers, which acts as an entry point for client applications,

    Percona Server for MongoDB Operator, sharding on
  2. If :ref`sharding` mode is turned off, the application needs access to all MongoDB Pods of the replica set:

    Percona Server for MongoDB Operator, sharding off

You can find more on sharding in the official MongoDB documentation.

Accessing the Pod

When Kubernetes creates Pods, each Pod has an IP address in the internal virtual network of the cluster. Creating and destroying Pods is a dynamic process, therefore binding communication between Pods to specific IP addresses would cause problems as things change over time as a result of the cluster scaling, maintenance, etc. Due to this changing environment, you should connect to Percona Server for MongoDB via Kubernetes internal DNS names in URI (e.g. using mongodb+srv://userAdmin:userAdmin123456@<cluster-name>-rs0.<namespace>.svc.cluster.local/admin?replicaSet=rs0&ssl=false to access one of the Replica Set Pods). URI-based access is strictly recommended.

Sometimes you cannot communicate with the Pods using the Kubernetes internal DNS names. To make Pods of the Replica Set accessible, Percona Server for MongoDB Operator can assign a Kubernetes Service to each Pod.

This feature can be configured in the replsets (for MondgoDB instances Pod) and sharding (for mongos Pod) sections of the deploy/cr.yaml file:

  • set ‘expose.enabled’ option to ‘true’ to allow exposing Pods via services,
  • set ‘expose.exposeType’ option specifying the IP address type to be used:
    • ClusterIP - expose the Pod’s service with an internal static IP address. This variant makes MongoDB Pod only reachable from within the Kubernetes cluster.
    • NodePort - expose the Pod’s service on each Kubernetes node’s IP address at a static port. ClusterIP service, to which the node port will be routed, is automatically created in this variant. As an advantage, the service will be reachable from outside the cluster by node address and port number, but the address will be bound to a specific Kubernetes node.
    • LoadBalancer - expose the Pod’s service externally using a cloud provider’s load balancer. Both ClusterIP and NodePort services are automatically created in this variant.

If this feature is enabled, URI looks like mongodb://userAdmin:userAdmin123456@<ip1>:<port1>,<ip2>:<port2>,<ip3>:<port3>/admin?replicaSet=rs0&ssl=false All IP adresses should be directly reachable by application.

Contact Us

For free technical help, visit the Percona Community Forum.
To report bugs or submit feature requests, open a JIRA ticket.
For paid support and managed or professional services, contact Percona Sales.