Couchbase AO 2.0 XDCR on Azure Kubernetes Service, within VNET and VNET Peer using NodePort

Hello Everyone,

I was able to setup the Couchbase cluster on AKS. Now this cluster will communicate with other Couchbase cluster in Azure over VNET Peering for data replication.

I need help on AKS NodePort external feature type, Where I would like to allows the cluster to be addressed with DNS over private networks (outside AKS Cluster), but withing same VNET or VNET Peer.

spec.networking.dns

The user is required to use these annotations to actually create the DNS entries as the services are created, updated and modified. The recommended solution is the Kubernetes External DNS integration. As such services will be annotated with external-dns.alpha.kubernetes.io/hostname.

The DNS configuration can also be used with the NodePort external feature type. This allows the cluster to be addressed with DNS over private networks e.g. through a VPN. In this mode of operation the Operator does not enforce the use of TLS. To create A records for your individual Couchbase server nodes, map the service DNS name annotation to the associated pod’s node IP address.

The individual DNS per-pod exposed service A records should be dynamically collated into an SRV record. This provides a stable name for the cluster as nodes are added and removed during the cluster lifecycle, and service discovery. The resource name for the given examples should be _couchbases._tcp.couchbase-0.us-east-1.example. com, with equal priority and weight and a port value of 11207.

Questions:

  1. How do i expose Couchbase endpoint DNS outside AKS cluser? Via External DNS?
  2. Should i use Node port or LoadBalancer type?

Actually that’s the wrong way of doing it (just recently updated!) The load-balancer networking is intended for putting clusters on the public internet only, and for nothing else. Since you are using Azure–which has a sensible networking model–you can just forward DNS from your source to your target cluster.

Have a read of https://docs.couchbase.com/operator/2.0/concept-couchbase-networking.html#inter-kubernetes-networking-with-forwarded-dns. We even have a short tutorial giving you ideas on how to configure DNS https://docs.couchbase.com/operator/2.0/tutorial-remote-dns.html.

So in this case, i don’t need to use LoadBalancer and External DNS right?

Also i’m trying to configure XDCR from client Couchbase cluster which is running on Azure VMs to remote Couchbase cluster running inside AKS. (VNET Peering)

To configure forward DNS on client side in Azure, do i need to create Azure Private DNS Zone?
And on the remote Couchbase cluster on AKS, i just have to make sure bi-directional traffic is allowed so that client can ping remote.

Correct, no public DNS, no DDNS replication (other than the built in Kubernetes stuff). One cluster need to be able to route to the other, and any firewall ports are open between the two.

You don’t need to do anything clever with the DNS, you are simply installing a DNS server with the XDCR source (or any SDK for that matter). Anything that matches the remote cluster’s domain gets forwarded to the remote Kubernetes DNS server. Simple!

Thank you for the quick response. I was able to resolve AKS cluster DNS from outside.
Also now able to add remote cluster (AKS) from my VMs Cluster (Source).
But when i try to add replication, it throws an error.
“:8092: getsockopt: connection refused”

I’m using NodePort type. And while adding remote cluster i did not specify any port.

You shouldn’t need to use “exposed features” at all with routed networking. It will cause Couchbase advertise the wrong addresses and confuse the client. Try removing spec.exposedFeatures and try again.