splitHorizon DNS?

Hello,

I think about switching from MongoDBCommunity-Operator to the Percona MongoDB Operator. However, I need the splitHorizon for DNS, like it is documented here: Connect to a MongoDB Database Resource from Outside Kubernetes — MongoDB Kubernetes Operator upcoming

Does the Percona MongoDB Operator include this feature?

Thanks and kind regards.

Marc

Hey @rdxmbr,

the article you shared talks about exposing mongodb outside of k8s. We for sure do support it. Read more here: Exposing the cluster - Percona Operator for MongoDB

Thanks, @Sergey_Pronin

I had just read that. However, for this we need additional LoadBalancer-IPs or NodePorts.

With splitHorizon, it is possible to route the external traffic via traefik with IngressRouteTCP

This way it is possible to get external access

  • via Domains / SNI and TLS-certificates for this domains
  • without additional external IPs

I assume, this is not possible with the latest percona operator. Is it?

Kind regards!

Got it! You are right, it is not possible right now.
Do you use MongoDB Community Operator and rely on this feature?

Hello @Sergey_Pronin
yes, I do.

Hello again,

just to get that right: If I use the LoadBalancerIPs to connect to a replicaSet, how does the mongodb-cluster answer with the right LoadBalancerIP for the master instead of answering with the Pod-IP?

Thanks again and kind regards

@rdxmbr seems you are right, and it something that is not properly working in 1.14.0.
I raised a bug about it: [K8SPSMDB-929] Can't connect to MongoDB Replica Set via LoadBalancer - Percona JIRA

There are two ways / workarounds available right now:

  1. You can switch to 1.13.0 behavior by setting clusterServiceDNSMode to external. See more here: Custom Resource options - Percona Operator for MongoDB

  2. You can use mongos and a single shard

In the long run I believe we will need to implement proper SplitHorizon. Will work with the team on it.

Thanks for your information. I’m just testing 2. , seems good until now :+1:

There is another point: When using transactions, the connection to the mongos-pods via the k8s-clusterIP seems not to be ideal. As the k8s-services works as a loadBalancer in front of the mongos, the transactions fail. We run into the same issue as https://jira.mongodb.org/browse/CSHARP-3301

I am wondering if this would be better with connecting via a headless service, but I haven’t got this working yet.

EDIT: [K8SPSMDB-931] problems with transactions and mongos - missing headless service in statefulset - Percona JIRA

As a workaround we’ve added

my-cluster-name-mongos-0
my-cluster-name-mongos-1
my-cluster-name-mongos-2
my-cluster-name-mongos-0.default.svc.cluster.local
my-cluster-name-mongos-1.default.svc.cluster.local
my-cluster-name-mongos-2.default.svc.cluster.local

to our certificates and configured mongos with

expose:
  servicePerPod: true

Of course, this is not scalable.

Yes, servicePerPod was created exactly for the case where you have long running transactions and they can fall under different cursors / mongos pods.

As for not scalable - what do you mean? Do you mean that if you scale mongos from 3 to 5 nodes your certs will not be there? Or that your application will need reconfiguration?

In our experience mongos sizing is quite static as it is just a proxy and they do not consume a lot of resources, so scaling is rare.

Do you mean that if you scale mongos from 3 to 5 nodes your certs will not be there?

This.

In our experience mongos sizing is quite static as it is just a proxy and they do not consume a lot of resources, so scaling is rare.

:+1:

As with K8SPSMDB-886 - Update psmdb-db chart for 1.15.0 release · percona/percona-helm-charts@e4416fa · GitHub , splitHorizon has to be included in the meantime?

@Sergey_Pronin