<p>I am trying to connect to kubelet running on a &quot;fake node&quot; from a EKS fargate pod.</p>
<p>For example I have two nginx pods with IPs <code>10.0.0.1</code> and <code>10.0.0.2</code> hosted in two fake nodes with the same IPs <code>10.0.0.1</code> and <code>10.0.0.2</code>.</p>
<p>From the pod <code>10.0.0.1</code> I can run correctly against <code>10.0.0.2</code>:</p>
<pre><code>curl -X GET https://10.0.0.2:10250/stats/summary --header &quot;Authorization: Bearer $TOKEN&quot; --insecure

{
 &quot;node&quot;: {
  &quot;nodeName&quot;: &quot;fargate-ip-10.0.0.2.us-east-2.compute.internal&quot;,
  &quot;systemContainers&quot;: [
   {
    &quot;name&quot;: &quot;pods&quot;,
    &quot;startTime&quot;: &quot;2021-03-02T11:21:55Z&quot;,
   [...]

</code></pre>
<ul>
<li><p>But if I try to curl the very same host <code>10.0.0.1:10250</code> I get a connection refused.</p>
</li>
<li><p>Doing the same from the second pod lead to the opposite result, I can query <code>10.0.0.1</code> and not <code>10.0.0.2</code>.</p>
</li>
<li><p>Notice that if I curl port 80 the nginx answers correctly, therefore it seems that when connecting from the pod itself the network is not able to understand that the request can be answered by the host</p>
</li>
<li><p>Moreover I know I can pass through the proxy (<code>curl -X GET https://172.20.0.1:443/api/v1/nodes/fargate-ip-10-0-0-1.us-east-2.compute.internal/stats/summary --header &quot;Authorization: Bearer $TOKEN&quot; --insecure</code>), but due to some limitations this is not feasible in my scenario</p>
</li>
</ul>

<p>So, on AWS Fargate, Pods and associated Nodes share the IP address:</p>
<pre><code>$ kubectl get pods -o=wide
NAME   READY   STATUS    RESTARTS   AGE   IP                NODE                                                       NOMINATED NODE   READINESS GATES
foo    1/1     Running   0          94m   192.168.152.183   fargate-ip-192-168-152-183.eu-central-1.compute.internal   &lt;none&gt;           &lt;none&gt;
$
$ kubectl get nodes -o=wide fargate-ip-192-168-152-183.eu-central-1.compute.internal
NAME                                                       STATUS   ROLES    AGE   VERSION              INTERNAL-IP       EXTERNAL-IP   OS-IMAGE         KERNEL-VERSION                  CONTAINER-RUNTIME
fargate-ip-192-168-152-183.eu-central-1.compute.internal   Ready    &lt;none&gt;   92m   v1.18.9-eks-866667   192.168.152.183   &lt;none&gt;        Amazon Linux 2   4.14.209-160.339.amzn2.x86_64   containerd://1.4.1
</code></pre>
<p>If you check routing table on the pod, you will find the following:</p>
<pre><code>$ kubectl exec -i -t foo -- ip r get 192.168.152.183
local 192.168.152.183 dev lo src 192.168.152.183 uid 0
    cache &lt;local&gt;
$
$ kubectl exec -i -t foo -- ip r get 192.168.152.20 # Notice different IP address.
192.168.152.20 dev eth0 src 192.168.152.183 uid 0
    cache
</code></pre>
<p>So if you try to reach your own IP address from within the Pod, traffic will flow trough the network stack local to the container, where kubelet is not reachable.</p>
<p>When accessing from the outside, you first hit the underlying host OS where <code>kubelet</code> is running. I guess there is some magic done then, which forwards traffic to the container.</p>
<p>Fargate do not allow running privileged containers or adding <code>CAP_SYS_ADMIN</code> capability, so it is not possible to bypass the local stack by overriding the routing table.</p>
<p>I don't know if there are other ways to do it in unprivileged way.</p>
