The goal of network services, such as Consul, is to make Kubernetes pods in different clusters or regions appear as if they were local to each other. This makes configuring XDCR within VoltDB itself easier; in most cases it is almost identical to how you configure clusters within local namespaces. However, how you configure the network service itself is very dependent on which service you are using and the hosting environment in which you are operating.

Using Consul as an example, Consul provides a "sidecar" — an additional process running in the same pod as the VoltDB process — that makes remote pods and clusters appear to be local to the pod itself. So rather than providing a remote IP address and port as the source for XDCR Network Discovery, you specify a local port. For example:

cluster:
  config:
    deployment:
      dr:
        id: 1
        role: xdcr
        connection:
          enabled: true
          source: "localhost:4444"

What port you specify and how you configure and start Consul and the Consul sidecar, is specific to the Consul product and your implementation of it. The same is true when using other third-party networking services. You may also need to provide additional annotations within the Helm configuration to complete the network setup, depending upon which network service you use. For example:

cluster:
  clusterSpec:
    additionalAnnotations:
      "consul.hashicorp.com/connect-service": "chicago-voltdb-cluster"
      "consul.hashicorp.com/connect-service-upstreams": "chicago-voltdb-cluster:5554:illinois"

See the product documentation for the specific service for further information.