So 8 months is a long time in the world of Kubernetes, and we’ve made a lot of progress that I will share here as its relevant to the thread in general. 1.2.0 is out in around a month. What we have done is reuse the multi-network configuration stuff in Couchbase Server that is used to enable XDCR via IP and add in support for DNS names. Coupled with public addressability as a result of optionally using LoadBalancer rather than NodePort services we are now able to provide connectivity over the public internet, with full end-to-end TLS encryption.
As regards SDKs they should be able to connect using this mechanism from anywhere in the universe. I’m no expert on the Kafka connector but I can see it’s written in Java so highly likely uses the Java SDK under the hood.
I’ll revisit the networking documentation before 1.2.0 and ensure it’s very clear on networking options, never the easiest topic to describe
In the mean time if it’s holding up your testing, you can add client to the spec.exposedFeatures attribute. It’s up to you to ensure there is pure L3 routing (absolutely no DNAT, the IP address client connects to must be the same as what Couchbase Server advertises) between your Kafka container and the Kubernetes underlay network, a site-to-site VPN is usually the easiest to configure. Then to connect the Kafka connector to Couchbase Server follow the guide here https://docs.couchbase.com/operator/1.1/xdcr.html#using-ip-and-exposed-features.
Any more help you need just give me a holler!