The ability to add
spec.replsets.externalNodes depends on
spec.replsets.expose.enabled: true, so in order to be able to add
externalNodes one also needs to expose replica sets with a service-per-pod or MCS.
I quite, honestly do not understand why there is such a dependency.
psmdb.MongoHost is used to calculate the name of the host to be added to replicaset, config replicaset and shards, but it depends on whether it is exposed or not, and even more so on how it is exposed, with variants around
spec.clusterServiceDNSMode, which are not a part of either
So, IMO, there are 2 issues, which are interconnected:
The ability to add external nodes when replicasets are not exposed
The way replicaset names are calculated based on the type of exposure
While I am not too sure how to address #2 (and even if it needs to be addressed), can someone help me understand why we cannot add external nodes if replicasets are not exposed?
Cross site replication a.k.a external nodes are mainly introduced for enabling replication between two different k8s clusters or between on-prem instances and k8s. Mongo nodes needs to be able to reach each other in replicaset. You need to expose your replica and primary clusters for that. The decision to force exposing the replicaset is there for making misconfigurations hard.
Do you want to add external nodes from separate namespace that runs in the same Kubernetes cluster? What’s your use case?
Thank you for getting back - really appreciate it.
So, in my case I already have a a pod-to-pod connectivity between multiple k8s clusters via cilium mesh, and pods can reach each other. so in my case the default MongoHost name is perfect, I just need to add external pod names, which can be addressed like
And here I could have the remote db cluster deployed to the different namespace, or use a different domain suffix.
Also, now that we are getting to multiple “exposure” scenarios, like MCS, ServiceMesh, ClusterMesh (with cilium), etc. I think that some re-factoring around the CRD and MongHost may be warranted…