<p><strong>Question</strong>: How can I provide reliable access from (non-K8s) services running in an GCE network to other services running inside Kubernetes?</p>

<p><strong>Background</strong>: We are running a <strong>hosted K8s</strong> setup in the <strong>Google Cloud Platform</strong>. Most services are <strong>12factor apps</strong> and <strong>run</strong> just <strong>fine</strong> within K8s. Some <strong>backing stores</strong> (databases) are run <strong>outside of K8s</strong>. Accessing them is easy by using headless services with manually defined endpoints to fixed internal IPs. Those services usually do not need to "talk back" to the services in K8s.</p>

<p>But <strong>some services</strong> running in the internal GCE network (but <strong>outside of K8s</strong>) need to <strong>access services running within K8s</strong>. We can expose the K8s services using <code>spec.type: NodePort</code> and talk to this port on any of the K8s Nodes IPs. But how can we automatically find the right NodePort and a valid Worker Node IP? Or maybe there is even a better way to solve this issue.</p>

<p>This setup is probably not a typical use-case for a K8s deployment, but we'd like to go this way until PetSets and Persistent Storage in K8s have matured enough.</p>

<p>As we are talking about internal services I'd like to avoid using an external loadbalancer in this case.</p>

<p>You can make cluster service IPs meaningful outside of the cluster (but inside the private network) either by creating a "bastion route" or by running kube-proxy on the machine you are connecting from (see <a href="https://stackoverflow.com/questions/31664060/how-to-call-a-service-exposed-by-a-kubernetes-cluster-from-another-kubernetes-cl/31665248#31665248">this answer</a>).</p>

<p>I think you could also point your resolv.conf at the cluster's DNS service to be able to resolve service DNS names. This could get tricky if you have multiple clusters though.</p>
