<p>I have a Kubernetes v1.13 cluster with Calico + flannel as CNI. All Nodes have a publicly routable ip address and are running Ubuntu 16.04.</p>

<p>Some Nodes are located in a company network, being both located in the LAN and DMZ, and therefore having access to internal services while still being publicly accessible. Others are hosted VMs at a cloud provider.</p>

<p><a href="https://i.stack.imgur.com/WDA7L.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/WDA7L.png" alt="Cluster"></a></p>

<p>Consider the simplified example above. I want a Kubernetes Pod to access <code>Internal Server C</code> (which is just a regular server and not part of the cluster). I could enforce the Pod to be scheduled on the internal <code>Node B</code> only, but as there is only a low latency and bandwidth required for the connection, and there is way more resources on <code>Node A</code>, I would prefer to use <code>Node B</code> just as some kind of <em>gateway</em>. (Consider several <code>Node B</code>s, so there is actually no SPOF).</p>

<p>My current approach is to use a DaemonSet with a Node Selector targeting all <em>internal</em> (<em>B</em>) Nodes, defining an HAProxy Pod. Those HAproxy instances can be reached as a Kubernetes Service and forward requests to the internal destination services.</p>

<p>Do you see a better or more straightforward way to realize the connection from a Pod located at any Node to a target that can only be reached by a subset of Nodes?</p>

muffel
<p>Based on what you say here:</p>

<blockquote>
  <p>I could enforce the Pod to be scheduled on the internal Node B only, but as there is only a low latency and bandwidth required for the connection, and there is way more resources on Node A, I would prefer to use Node B just as some kind of gateway.</p>
</blockquote>

<p>I think what you're looking for is an <a href="http://www.cnblogs.com/pinganzi/p/7389854.html" rel="nofollow noreferrer">Ambassador</a> pattern. Basically you would create this kind of containers located in your <code>B</code> zone, and your traffic would go to this containers/pods using a <code>ClusterIP</code> service since it's within the cluster.</p>

<p>Then, these containers would have running a <strong>proxy</strong> inside them (kind of what you have now on your daemons), that would route the traffic transparently to the regular server you're targeting. </p>

<p>Other links that may be useful could be <a href="https://learn.microsoft.com/en-us/azure/architecture/patterns/ambassador" rel="nofollow noreferrer">this from MS</a> or <a href="https://www.slideshare.net/luebken/container-patterns" rel="nofollow noreferrer">this slideshows (p.42)</a>.</p>

<p>If this presents a big advantage against what you have already running I'm not sure, but I do prefer to work with just pods and minimize other components if it's possible.</p>
