0

EKS Fargate is an AWS service for "serverless" hosting of some pods in a Kubernetes cluster. The docs mention that NAT is obligatory, why is this?

I tried using traceroute from a Fargate pod. I was able to trace the route to another pod (which hopped via the IP address of the host EC2 instance as expected). However, when I tried tracing the route to a ClusterIP service, traceroute could only get as far as the NAT's network interface. Why would internal cluster traffic between a Fargate pod and a ClusterIP (representing pods hosted by conventional nodes in the same cluster) appear to be routed via a NAT? (This seems odd because a NAT is ostensibly for traffic exiting the VPC that contains the Kubernetes cluster, whereas a ClusterIP service should only be reachable from inside the Kubernetes cluster.)

(Note, I also tried UDP or TCP SYN instead of ICMP ECHO, which gave 3 hops but all reporting the same IP as the target, and UDPLITE only gave 169.254.175.250 which I assume is Fargate infra?)

Improve this question
2
  • Has any answer solved your question? Then please accept it or your question will keep popping up here forever. Please also consider voting for useful answers.
    – Zac67 ♦
    Commented Jun 6 at 6:57
  • Thanks for the tip @Zac67. Unfortunately at this stage I'm still waiting for a useful answer, but in the meantime I'm intending to try VPC flow logs to see if they can shed more light, and also intending to test turning off the NAT to see what changes; will also inspect the routing tables (and iptables) in detail and report back after.
    – benjimin
    Commented Jun 6 at 8:45

1 Answer 1

Reset to default
0

From the linked article:

Pods that are running on Fargate are only supported on private subnets with NAT gateway access to AWS services

Basically, their private address domain is not compatible with AWS services, so their source addresses need to be translated for access, much like a private LAN's addresses need to be translated when accessing the public Internet.

NAT is always required when routing between different address domains, no matter the reason.

Improve this answer
5
  • Could you explain how the NAT (ostensibly only translating between VPC private IPs and public internet IPs) is involved in communicating between the private real IPs of EKS pods and the private virtual IPs of k8s services? Is it really still needed even for pods that do not try to access AWS services and the internet, or if using VPC endpoints? (Note this seems different than for non-fargate pods even though the VPC is the same.)
    – benjimin
    Commented May 15 at 4:42
  • NAT can be used to translate between any incompatible address domains.
    – Zac67 ♦
    Commented May 15 at 6:24
  • If the VPC address domain (assigned to nodes, the pods on EC2 nodes, and the "serverless" pods on fargate VMs) is "incompatible" with the ClusterIP virtual address domain, does EKS automatically grant API access privileges for the NAT to monitor the "service endpoints" Kubernetes objects so that the NAT can dynamically redirect ClusterIPs to the correct pod's IPs? Or does the NAT have some other way of knowing where this traffic should be proxied to?
    – benjimin
    Commented May 15 at 10:54
  • NAT doesn't proxy - a proxy works on L7 (off topic here), and NAT/NAPT works on L3+L4. NAT translates between an address domain on one interface and another address domain on a second interface, that's all it needs to know. The specific questions to AWS why and how I can't answer, sorry, but it's unlikely anyone here can.
    – Zac67 ♦
    Commented May 15 at 11:01
  • My confusion is that the source and destination are already in the same IP range and same subnet or L3/L4 "network segment", so it's not clear what useful address translation can be performed by a conventional NAT in this circumstance, and I'm also wondering if traceroute ICMP results could have been misleading. Maybe there are some relevant routing tables I can inspect..
    – benjimin
    Commented May 15 at 11:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.