<p>I have setup a kubernetes cluster using kubeadm.</p>

<p><strong>Environment</strong></p>

<ol>
<li>Master node installed in a PC with public IP.</li>
<li>Worker node behind NAT address (the interface has local internal IP, but needs to be accessed using the public IP)</li>
</ol>

<p><strong>Status</strong></p>

<p>The worker node is able to join the cluster and running</p>

<pre><code>kubectl get nodes
</code></pre>

<p>the status of the node is ready. </p>

<p>Kubernetes can deploy and run pods on that node.</p>

<p><strong>Problem</strong></p>

<p>The problem that I have is that I'm not able to access the pods deployed on that node. For example, if I run </p>

<pre><code>kubectl logs &lt;pod-name&gt;
</code></pre>

<p>where pod-name is the name of a pod deployed on the worker node, I have this error:</p>

<pre><code>Error from server: Get https://192.168.0.17:10250/containerLogs/default/stage-bbcf4f47f-gtvrd/stage: dial tcp 192.168.0.17:10250: i/o timeout
</code></pre>

<p>because it is trying to use the local IP 192.168.0.17, which is not accessable externally. </p>

<p>I have seen that the node had this annotation:</p>

<pre><code>flannel.alpha.coreos.com/public-ip: 192.168.0.17
</code></pre>

<p>So, I have tried to modify the annotation, setting the external IP, in this way:</p>

<pre><code>flannel.alpha.coreos.com/public-ip: &lt;my_externeal_ip&gt;
</code></pre>

<p>and I see that the node is correctly annotated, but it is still using 192.168.0.17.</p>

<p>Is there something else that I have to setup in the worker node or in the cluster configuration?</p>

Davide
<p><em>there were a metric boatload of Related questions in the sidebar, and I'm about 90% certain this is a FAQ, but can't be bothered to triage the Duplicate</em></p>

<blockquote>
  <p>Is there something else that I have to setup in the worker node or in the cluster configuration?</p>
</blockquote>

<p>No, that situation is not a misconfiguration of your worker Node, nor your cluster configuration. It is just a side-effect of the way kubernetes handles Pod-centric traffic. It does mean that if you choose to go forward with that setup, you will not be able to use <code>kubectl exec</code> nor <code>kubectl logs</code> (and I think <code>port-forward</code>, too) since those commands do not send traffic through the API server, rather it directly contacts the <code>kubelet</code> port on the Node which hosts the Pod you are interacting with. That's primarily to offload the traffic from traveling through the API server, but can also be a scaling issue if you have a sufficiently large number of exec/log/port-foward/etc commands happening simultaneously, since TCP ports are not infinite.</p>

<p>I think it is <em>theoretically</em> possible to have your workstation join the overlay network, since by definition it's not related to the outer network, but I don't have a ton of experience with trying to get an overlay to play nice-nice with NAT, so that's the "theoretically" part.</p>

<p>I have personally gotten Wireguard to work across NAT, meaning you could VPN into your Node's network, but it was some gear turning, and is likely more trouble than it's worth.</p>
