SRE reference · EKS traffic path

Internet → Pod: where the packet goes, and what to check when it doesn't

Hop 0 / 10
Path

Traffic path from the Internet to a Pod on Amazon EKS, across an ingress VPC and the cluster VPC A client resolves DNS to an internet-facing NLB/ALB in an ingress VPC; the load balancer forwards to a target group of Pod IPs, which route across a Transit Gateway to the EKS cluster VPC, through the subnet route table to the Pod's ENI and security group, then via the service-mesh Envoy sidecar to the app container. Stepping lights each hop; kube-proxy is shown as the instance-mode alternative. resolve:443/svc-a/svc-bVPC attachmentVPC attachmentiptables → :15006iptables → :15006localhostlocalhost Ingress VPC · 10.10.0.0/16Public subnet · 10.10.1.0/24EKS cluster VPC · 10.20.0.0/16Private subnet · 10.20.32.0/19EC2 node i-0a1b2c3d · 10.20.5.11Pod svc-a · netnsPod svc-b · netns Route 53public DNSClientinternet userIGWALB · listener :443203.0.113.20 · internet-facing/svc-a → Target group A/svc-b → Target group BTarget group Asvc-a10.20.34.56:8080Target group Bsvc-b10.20.40.78:8080Route table (ingress)10.20.0.0/16 → tgw-0abc0.0.0.0/0 → igwVPC routerTransit Gatewaytgw-0abcTGW route table10.10.0.0/16 → ingress10.20.0.0/16 → clusterVPC routerRoute table (cluster)10.20.0.0/16 → local10.10.0.0/16 → tgw-0abcPod ENI10.20.34.56Envoy:15006 mTLSapp · svc-a10.20.34.56:8080Pod ENI10.20.40.78Envoy:15006 mTLSapp · svc-b10.20.40.78:8080kube-proxyhost netns · NodePort (instance mode)usesusesbranch ENI + iptables livein each Pod's own netns;kube-proxy in the host netns
Zones client / DNS ingress VPC · LB routing cluster VPC · node pod · mesh
Hop 0 / 10

Troubleshoot this hop

    The path, hop by hop

    Assumes the common enterprise pattern: an internet-facing load balancer in a dedicated ingress VPC, the AWS Load Balancer Controller in IP target mode (targets are Pod IPs), VPC CNI (Pod IPs are VPC IPs), Transit Gateway between VPCs, and a service mesh (Istio-style) sidecar. Swap values for your environment.

    #HopWhat routes itVerify withCommon cause when it stops here

    Inside the Pod — the iptables that reach the sidecar

    These NAT rules live in the Pod's own network namespace, installed by istio-init (or the Istio CNI). An inbound request is REDIRECT-ed to Envoy's inbound listener on :15006 before it ever reaches the app; the outbound rules break the loop so Envoy's own traffic (uid 1337) isn't re-captured. View them with kubectl exec <pod> -c istio-proxy -- iptables-save -t nat.

    # nat table — inside the Pod's netns

# 1) every inbound TCP packet jumps into Istio's own chain
-A PREROUTING -p tcp -j ISTIO_INBOUND

# 2) leave Envoy's own management ports alone (RETURN = don't touch)
-A ISTIO_INBOUND -p tcp --dport 15008 -j RETURN   # HBONE tunnel (newer Istio)
-A ISTIO_INBOUND -p tcp --dport 15090 -j RETURN   # Envoy metrics
-A ISTIO_INBOUND -p tcp --dport 15021 -j RETURN   # health / readiness
-A ISTIO_INBOUND -p tcp --dport 15020 -j RETURN   # agent
# 3) …everything else → the redirect chain
-A ISTIO_INBOUND -p tcp -j ISTIO_IN_REDIRECT

# 4) THE line that sends traffic to the sidecar:
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15006

# outbound: stop Envoy's own egress from being re-captured (the loop-break)
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN     # traffic FROM Envoy (uid 1337) → skip
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN               # loopback to the app stays local
-A ISTIO_OUTPUT -p tcp -j ISTIO_REDIRECT
-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001   # app's outbound → Envoy :15001

    Ports & ids to know: 15006 Envoy inbound (the REDIRECT target) · 15001 Envoy outbound · 15008 HBONE mTLS tunnel · 15021 health · 15090/15020 metrics · uid/gid 1337 = istio-proxy (the loop-break). This is Istio default REDIRECT mode; TPROXY and ambient/HBONE differ. No rules present → istio-init/CNI didn't run and Envoy is being bypassed.