splitHorizon DNS?

MongoDB Percona Operator for MongoDB
1

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

1 Like
2

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

3

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!

4

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

5

Hello @Sergey_Pronin
yes, I do.

6

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

7

@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.

8

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

9

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

10

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.

11

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.

12

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:

13

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

14

@rdxmbr they were added into both operator and helm chart. Have you tried it? :slight_smile: