<p>I have two service, S1 in cluster K1 and S2 in cluster K2. They have different hardware requirements. Service S1 needs to talk to S2.</p>

<p>I don't want to expose Public IP for S2 due to security reasons. Using NodePorts on K2 cluster's compute instances with network load-balancing takes the flexibility out as I would have to add/remove K2's compute instances in target pool each time a node is added/removed in K2.</p>

<p>Is there something like "service-selector" for automatically updating target-pool? If not, is there any other better approach for this use-case?</p>

<p>I can think of a couple of ways to access services across multiple clusters connected to the same GCP private network:</p>

<ol>
<li><p>Bastion route into k2 for all of k2's services:</p>

<p>Find the <code>SERVICE_CLUSTER_IP_RANGE</code> for the k2 cluster. On GKE, it will be the <code>servicesIpv4Cidr</code> field in the output of cluster describe:</p>

<pre><code>$ gcloud beta container clusters describe k2
...
servicesIpv4Cidr: 10.143.240.0/20
...
</code></pre>

<p>Add an advanced routing rule to take traffic destined for that range and route it to a node in k2:</p>

<pre><code>$ gcloud compute routes create --destination-range 10.143.240.0/20 --next-hop-instance k2-node-0
</code></pre>

<p>This will cause <code>k2-node-0</code> to proxy requests from the private network for any of k2's services. This has the obvious downside of giving <code>k2-node-0</code> extra work, but it is simple.</p></li>
<li><p>Install k2's kube-proxy on all nodes in k1.</p>

<p>Take a look at the currently running kube-proxy on any node in k2:</p>

<pre><code>$ ps aux | grep kube-proxy
... /usr/local/bin/kube-proxy --master=https://k2-master-ip --kubeconfig=/var/lib/kube-proxy/kubeconfig --v=2
</code></pre>

<p>Copy k2's kubeconfig file to each node in k1 (say <code>/var/lib/kube-proxy/kubeconfig-v2</code>) and start a second kube-proxy on each node:</p>

<pre><code>$ /usr/local/bin/kube-proxy --master=https://k2-master-ip --kubeconfig=/var/lib/kube-proxy/kubeconfig-k2 --healthz-port=10247
</code></pre>

<p>Now, each node in k1 handles proxying to k2 locally. A little tougher to set up, but has better scaling properties.</p></li>
</ol>

<p>As you can see, neither solution is all that elegant. Discussions are happening about how this type of setup should ideally work in Kubernetes. You can take a look at the <a href="https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/proposals/federation.md">Cluster Federation</a> proposal doc (specifically the <a href="https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/proposals/federation.md#cross-cluster-service-discovery">Cross Cluster Service Discovery</a> section), and join the discussion by opening up issues/sending PRs.</p>
