Skip to main content
Bumped by Community user
Bumped by Community user
deleted 2 characters in body; edited title
Source Link
Zac67
  • 88.1k
  • 4
  • 73
  • 137

Why does EKS Fargate require a NAT?

EKS Fargate is an AWS service for "serverless" hosting of some pods in a Kubernetes cluster. The docs mention that a 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?)

Why does EKS Fargate require a NAT?

EKS Fargate is an AWS service for "serverless" hosting of some pods in a Kubernetes cluster. The docs mention that a 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?)

Why does EKS Fargate require NAT?

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?)

Bumped by Community user
added 190 characters in body; added 5 characters in body
Source Link

EKS Fargate is an AWS service for "serverless" hosting of some pods in a Kubernetes cluster. The docs mention that a 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?)

EKS Fargate is an AWS service for "serverless" hosting of some pods in a Kubernetes cluster. The docs mention that a 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.)

EKS Fargate is an AWS service for "serverless" hosting of some pods in a Kubernetes cluster. The docs mention that a 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?)

Source Link

Why does EKS Fargate require a NAT?

EKS Fargate is an AWS service for "serverless" hosting of some pods in a Kubernetes cluster. The docs mention that a 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.)