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.
If :ref`sharding` mode is turned on (default bahaviour), then database cluster runs special
mongosPods - query routers, which acts as an entry point for client applications,
If :ref`sharding` mode is turned off, the application needs access to all MongoDB Pods of the replica set:
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
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)
sharding (for mongos Pod) sections of the
- set ‘expose.enabled’ option to ‘true’ to allow exposing Pods via services,
- set ‘expose.exposeType’ option specifying the IP address type to be
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
All IP adresses should be directly reachable by application.