Lecture 246: EKS Pod Networking - Part 2
- 课程：[NEW] AWS Certified Advanced Networking Specialty 2026
- 视频时长：11:55
- 来源：Udemy Lecture 35813138
- Slide 数量：6
- 画面切换：01:35、03:34、06:03、08:03、09:58
扫描说明
逐条读取了 Transcript 面板中的 253 条英文 cue，并按播放器进度同步全长约 11:55 的视频。依据 External IPv4 Flow、Default Node SNAT、Public-subnet Internet Path、Default SNAT Limitation、External SNAT/NAT Gateway、Multus Multi-homing 划分为 6 个小节。6 张截图来自真实课程 Slide，统一为 1364×770。
Transcript 来自 Udemy 页面自带的英文自动字幕，没有使用 ASR。下面保留页面原文，包括其中的语法或识别错误。
1. VPC 内 Pod-to-Pod 无 NAT，离开 VPC CIDR 的 IPv4 Flow 进入另一套规则
时间范围：00:00–01:35
总结 / Summary
中文
Pod 从 VPC Subnet 获得 Private IP，同 VPC 内可以直接按 Pod IP 通信；当 Destination IPv4 不属于 VPC CIDR，例如 Internet、Peered VPC、Transit Gateway 或 VPN/Direct Connect On-prem，VPC CNI 默认会在 Node 上处理 Source NAT。判断路径时必须先问：Destination 是否在 VPC CIDR、使用 IPv4 还是 IPv6、Node 位于 Public 还是 Private Subnet、以及是否要让 Remote Network 看到原始 Pod IP。
English
Pods receive private addresses from VPC subnets and communicate directly by pod IP within the VPC. When an IPv4 destination lies outside the VPC CIDR, such as the Internet, a peered VPC, Transit Gateway, or an on-premises network over VPN or Direct Connect, VPC CNI applies a different default source-NAT path on the node. Analyze the destination CIDR, address family, public or private node subnet, and whether the remote network must see the original pod address.
Transcript
00:00 Hello and welcome to this lecture.
00:02 Now, in the earlier lecture,
00:03 we saw how CNI assigns private IP addresses to the pods
00:07 and then how pods can communicate with each other.
00:10 Now this is a next level where we'll see
00:12 how pod communicates with the external network.
00:15 Now this is a little complex
00:17 than what we have seen already.
00:20 And I hope at the end of the lecture,
00:22 you would be able to understand
00:23 end-to-end flow of pod networking, so let's get started.
00:27 Quick recap, every pod gets private IP address
00:31 from the VPC address space
00:33 and then pods can communicate directly without NAT
00:36 with each other if they're part of the same VPC.
00:39 So this works well
00:40 as long as pods needs to communicate within VPC.
00:44 But more often or not,
00:46 pod would want to communicate externally
00:48 maybe to the internet, maybe to other VPCs,
00:51 where there are additional application deployed.
00:54 Because if you talk about large ecosystem,
00:56 there will be multiple systems
00:58 and then application needs to communicate with each other.
01:01 Now, in that case, things are a little different
01:04 and let's see how that kind of communication works.
01:08 Now let's try to understand this communication.
01:10 So there is VPC, there is a public subnet
01:13 in which you have worker node
01:16 and then you have ENIs assigned.
01:18 And then ENI have secondary IPs
01:20 which are assigned to the pods.
01:22 Now on the right side, you have external network.
01:24 It could be internet and there could be other VPCs.
01:27 You could connect to transit gateway
01:29 or on-premises network over to VPN or RDS,
01:32 but this is external to the VPC.
2. 默认 IPv4 Egress：VPC CNI 把 Pod Source IP SNAT 为 Primary ENI Private IP
时间范围：01:35–03:34
总结 / Summary
中文
默认设置下，只要 IPv4 Destination 在 VPC CIDR 之外，aws-node 就把 Packet Source 从 Pod Secondary IP 改为 Node Primary ENI 的 Primary Private IPv4，再按 Route Table 发往 TGW、Peering、VPN/DX 或 Internet Path。这个 Stateful SNAT 让 Return Traffic 回到 Node，再由 Connection Tracking 还原给 Pod；Remote Side 看到的是 Node IP，不是 Pod IP。IPv6 使用 Global Unicast Address，不采用这类 IPv4 NAT；但“Global”不等于自动公网可达，仍必须有 Route、Egress-only/IGW 设计与 Security Policy。
English
By default, when an IPv4 destination is outside the VPC CIDR, aws-node rewrites the packet source from the pod secondary address to the primary private IPv4 address of the node's primary ENI, then follows the route table toward TGW, peering, VPN or DX, or an Internet path. Stateful SNAT returns traffic to the node, where connection tracking restores it to the pod; the remote side sees the node address, not the pod address. IPv6 global-unicast traffic does not use this IPv4 NAT model, but global addressing does not make it automatically Internet-reachable; routes and security policy still govern reachability.
Transcript
01:35 Now, the way CNI plugin has been implemented,
01:38 you need to understand that when a pod communicates
01:40 to any IPv4 address
01:43 that isn't within the CIDR block of the VPC,
01:46 then Amazon VPC CNI plugin translates the pod's IPv4 address
01:52 to the primary private IPv4 address of the primary ENI
01:57 which is assigned to that node.
01:59 Now, let's try to break this.
02:01 What it means is that if this pod here
02:04 where the IP address is shown in red
02:06 wants to communicate outside of the VPC CIDR,
02:10 then the traffic lands to the primary ENI first
02:14 and then there is a NAT which happens at this point
02:17 because traffic is going out of the VPC now.
02:20 So the source packet, source IP address
02:24 is replaced with the primary ENI's primary IP address,
02:28 which is 10.0.0.15 in that case.
02:30 So if you look at the flow,
02:32 this will make a request maybe to the internet,
02:35 but the traffic will first go to the primary ENI
02:38 and then the source IP address on the packet
02:41 will be replaced with the primary IP address of this ENI.
02:45 And then this packet will be sent out
02:47 depending on which route you take,
02:49 whether it's going to the transit gateway
02:51 or to other VPC through VPC peering likewise.
02:55 So this is what happens by default
02:58 when pod tries to communicate outside of the VPC network.
03:02 Now whatever we are talking,
03:03 it applies to the IPv4 addresses only
03:06 because IPv6 addresses are not network translated
03:12 because they are public by default,
03:15 so they don't need NATing to be enabled.
03:18 So this is for IPv4 address.
03:20 So that's the basic fundamentals of what happens
03:22 when the pod tries to reach outside of the VPC.
03:25 And now based on this knowledge,
03:27 let's try to understand what happens
03:29 when pod reaches the internet
03:30 or to the other networks outside of the VPC.
3. Public-subnet Node：EXTERNALSNAT=false 表示 Node SNAT 开启，再由 IGW 映射 Public IP
时间范围：03:34–06:03
总结 / Summary
中文
VPC CNI 的变量名容易反向理解：默认 AWS_VPC_K8S_CNI_EXTERNALSNAT=false 表示不把 NAT 交给 External Device，因此 Node-side SNAT 是 Enabled。Public-subnet Node 若有 Public/Elastic IP，Pod Egress 先从 Pod IP 变成 Node Primary Private IP，再由 Internet Gateway 做 Public IPv4 映射后访问 Internet。到 TGW/Peering/VPN-DX 的流量则以 Node Private IP 作为 Source。该模式简化 Outbound，但 Remote Network 无法从 Packet Source 识别具体 Pod。
English
The VPC CNI variable is easy to read backward. The default AWS_VPC_K8S_CNI_EXTERNALSNAT=false means NAT is not delegated to an external device, so node-side SNAT is enabled. For a public-subnet node with a public or Elastic IP, pod egress is first translated from the pod address to the node's primary private address, then the Internet gateway maps it to the public IPv4 address. Traffic toward TGW, peering, or VPN and DX uses the node private address as its source. This simplifies outbound access but hides the individual pod from the remote network.
Transcript
03:34 Okay, so the same diagram,
03:36 but then I have shown here multiple outside networks
03:40 like internet, transit gateway, VPC peering,
03:42 or RDS connection, for example, connected to the VPC,
03:45 and there is also internet gateway
03:48 because if traffic has to go out to the internet,
03:50 there should be internet gateway.
03:52 Now in this case, nodes are in public subnet
03:55 so that nodes can directly communicate with the internet.
03:59 Now, with CNI, there is some setting
04:03 which is called source NAT enabled,
04:05 which means whatever we talked in the last slide,
04:08 when pods goes out of the VPC network,
04:11 the pod's source IP is replaced
04:14 with the primary IP of the primary ENI.
04:16 Now, this is a default setting
04:18 and this is called source NAT enabled.
04:20 That means NATing is happening at the node level here.
04:24 And if you want to set that with Kubernetes settings,
04:28 then it is called EXTERNALSNAT is disabled
04:31 or EXTERNALSNAT is false.
04:33 So this is again a little confusing,
04:35 but understand that source NAT enabled
04:37 means NAT is happening at the node ENI level.
04:42 So if that is the case and node is in a public subnet
04:46 and this pod needs to communicate with the internet,
04:49 it needs to make an outbound request to the internet,
04:52 then, of course, when packet originates,
04:55 the source IP is the pod IP address,
04:58 it goes to the ENI, we just saw that in a previous slide.
05:01 And at this point, the source IP will be replaced
05:03 with the node ENI primary IP address that is 10.0.0.15
05:08 and now the traffic goes to internet
05:11 and internet gateway also does the NATing.
05:14 It replaces the source IP with the public IP of this ENI,
05:19 which is primary ENI, so that's node public IP
05:23 and then traffic goes to the internet.
05:25 So this is how the end-to-end communication happens
05:28 when pod reaches out to the internet.
05:30 So in this case, source NAT is enabled,
05:32 which means EXTERNALSNAT is disabled.
05:35 EXTERNALSNAT means somebody else is doing the NAT,
05:38 not the node, and we'll see those use cases as well.
05:41 Now if you continue with the same mechanism,
05:45 then pod can also reach to the external network
05:49 and this transit gateway here or VPC peering
05:51 will always see the primary IP address of the primary ENI.
05:55 They won't see the IP address of this pod
05:59 because it is getting NATed at the node level.
4. Node SNAT 隐藏 Pod Identity，并可能破坏 External-to-Pod 的对称 Return Path
时间范围：06:03–08:03
总结 / Summary
中文
所有外部 Flow 都被改写为 Node IP 时，Logging、Firewall Policy 与 Per-Pod Attribution 只能看到 Node。Remote Network 即使能路由到 Pod Subnet，Pod 的 Response 若再次被 Node SNAT，也可能因 Source Address 改变而破坏对称 Session。讲师把这一点概括为外部无法直接访问 Pod；更精确地说，Direct Inbound 还取决于双方 Route、Non-overlapping CIDR、VPC CNI Rule、SG/NACL/NetworkPolicy 与 Return-path SNAT。Production 不必一刀切关闭 SNAT，也可用 AWS_VPC_K8S_CNI_EXCLUDE_SNAT_CIDRS 仅保留指定 Private CIDR 的 Pod Source Identity。
English
When every external flow is rewritten to the node address, logging, firewall policy, and per-pod attribution see only the node. Even when the remote network can route to the pod subnet, a response that is SNATed by the node can break session symmetry by changing the source address. The lecture summarizes this as external networks being unable to reach pods directly. More precisely, direct inbound also depends on bidirectional routes, non-overlapping CIDRs, VPC CNI rules, security groups, NACLs, NetworkPolicy, and return-path SNAT. Production designs can use AWS_VPC_K8S_CNI_EXCLUDE_SNAT_CIDRS to preserve pod identity only for selected private CIDRs instead of globally disabling SNAT.
Transcript
06:03 Now, this is good for outbound traffic as you can see here
06:07 and same happens for any other pods as well,
06:11 whether it's this pod or this pod,
06:14 always primary ENI is being used.
06:16 Now this works well, but do you see any problem here?
06:19 Now, because all external networks
06:22 are now seeing the node IP address
06:24 and not the pod IP address directly,
06:27 they can't directly reach to the pod
06:30 because this is hidden now, this IP address.
06:33 That means if from peered VPC
06:35 you try to communicate with this pod, there is no network
06:39 which will allow you to directly reach to the pod.
06:42 Because it's an outboard request, it's allowed,
06:45 but inbound requests are not allowed.
06:48 They can't really reach
06:49 because these IPs are not exposed outside
06:54 because you are doing the NAT.
06:55 Same logic, when you have the NAT gateways,
06:58 an instance in a private subnet
06:59 needs to communicate with the internet,
07:02 then the NAT replaces the source IP address.
07:05 The same mechanism you can apply here,
07:07 that means outside network cannot reach to these pods
07:10 and that's a problem, right?
07:11 You don't want to do that.
07:13 Another problem is your worker node is in public subnet.
07:17 Typically you don't want that.
07:18 You want your worker nodes to be in private subnet
07:21 and then still your pod should be able to reach
07:24 to the internet.
07:26 Of course, you might have guessed
07:27 what could be the solution.
07:28 So a solution would be, of course, to use NAT gateways.
07:31 But in this case, you don't want this NATing to happen
07:37 at the node level.
07:39 NAT gateway should see your pod's IP address,
07:42 then you can reach outside through the NAT gateway.
07:46 And also you want to make sure that the IP addresses
07:49 of the pods are visible outside.
07:52 And in that case, you would have to disable the source NAT.
07:55 That means you are not doing the NAT at the node level,
07:58 but you are using some external NAT
08:00 for this kind of communication.
5. EXTERNALSNAT=true 保留 Pod IP 到 Private Network，Internet NAT 交给 NAT Gateway
时间范围：08:03–09:58
总结 / Summary
中文
设置 AWS_VPC_K8S_CNI_EXTERNALSNAT=true 会关闭 VPC CNI 的 Node-side SNAT，让 Packet 以 Pod IP 到达外部 Routing Device。对 Internet Egress，Private-subnet Route 把流量送到 Public-subnet NAT Gateway，由 NAT Gateway 改写为自己的 Private IP，再经 IGW 映射为 NAT Gateway Elastic IP；公网最终仍看不到 Pod IP。对 TGW、Peering、VPN/DX Private Destination，则不经过 NAT Gateway，Remote Network 可看到并按 Pod IP 回程。NAT Gateway 本身在默认 Node SNAT 下也能工作；启用 External SNAT 的关键价值是保留 Pod Identity/对称路径，而不是 NAT Gateway 可用性的必要条件。
English
Setting AWS_VPC_K8S_CNI_EXTERNALSNAT=true disables VPC CNI node-side SNAT, so packets reach the external routing device with the pod address intact. For Internet egress, a private-subnet route sends traffic to a NAT gateway in a public subnet; the NAT gateway rewrites it to its own private address, and the IGW maps that to the NAT gateway Elastic IP, so the Internet still never sees the pod address. For private destinations over TGW, peering, VPN, or DX, traffic bypasses the NAT gateway and the remote network can see and route back to the pod IP. A NAT gateway also works with default node SNAT; external SNAT is primarily about preserving pod identity and return-path symmetry, not a prerequisite for NAT-gateway use.
Transcript
08:03 And that's where NAT gateway comes into the picture.
08:05 So first setting you would have to do
08:06 is to disable the source NAT.
08:09 And if you want to do it at Kubernetes level,
08:11 you would have to fire this command
08:13 which says EXTERNALNAT is true now
08:15 or EXTERNALSNAT is true now,
08:17 so these are kind of opposite words,
08:20 but try to understand the difference.
08:23 So what we are saying is now node is not doing any NAT,
08:26 but then some external entity will do the NAT.
08:29 Now in this case, with the same example,
08:31 we have source IP as a pod.
08:33 No NATing would happen at ENI level.
08:36 Traffic will directly go to the NAT gateway,
08:37 of course, through the routing table.
08:39 NAT will replace the source IP with the NAT IP address,
08:43 then it will go to the internet gateway.
08:45 Internet gateway will replace the source IP
08:48 with the NAT gateway's public IP
08:50 and then traffic will go to the internet.
08:52 So this is about the outbound traffic. It works that way.
08:56 Similarly, if you want to go to the peer VPC,
09:00 the traffic directly from this pod
09:02 will go to the transit gateway or peered VPC or on-premises.
09:05 That means on-premise network
09:07 can also see the pod IP address directly.
09:10 There is no NATing happening here
09:13 because we have disabled the source NAT at the node level
09:17 and which also means if any of these networks
09:20 wants to communicate with the pod,
09:22 they can directly communicate.
09:24 So this is the next slide
09:25 where the same setting source NAT is disabled,
09:29 and if external network wants to communicate, they can do it
09:33 and they can directly reach to the pod's private IP address
09:36 because we have disabled the source NAT here.
09:39 I know this could be confusing or maybe a little complex,
09:42 but if you just follow what we talked in this lecture,
09:45 you should be able to understand what is source NAT
09:48 and what is an effect of source NAT
09:51 while using the NAT gateways
09:52 or reaching out to the external networks.
09:55 So I hope that is clear to you.
6. Multus CNI 为同一 Pod 增加 Secondary Interface，支持 Multi-homed Workload
时间范围：09:58–11:55
总结 / Summary
中文
普通 VPC CNI Pod 通常只有 eth0，连接一个 VPC Subnet/Primary Pod Network。Multus 是 Meta-CNI：它保留默认 VPC CNI Interface，同时调用其他 CNI（如 ipvlan、host-device 等）为同一 Pod 增加 net1、net2，从而把 Management、Data、Telco/NFV 或 High-performance Traffic 放到不同 Network。Multus 本身负责协调多个 Plugin，不等于每个 Secondary Interface 都是 AWS ENI；Address Management、Route、Security、Device Allocation 与 Lifecycle 必须由对应 Delegate CNI/Operator 设计。本讲将其作为扩展知识而非核心考试路径。
English
A normal VPC CNI pod generally has one eth0 connected to a VPC subnet and the primary pod network. Multus is a meta-CNI: it preserves that default VPC CNI interface while invoking other CNIs, such as ipvlan or host-device, to add net1 and net2. Management, data, telco or NFV, or high-performance traffic can therefore use separate networks. Multus coordinates delegate plugins; it does not imply that every secondary interface is an AWS ENI. Address management, routing, security, device allocation, and lifecycle remain responsibilities of the selected delegate CNI or operator. The lecture treats this as extension knowledge rather than the core exam path.
Transcript
09:58 Now, with that, I just want to touch upon one more feature,
10:01 which is not widely known,
10:03 but there is something called multi-home pods.
10:07 Now, multi-home pod means you could have multiple ENIs
10:11 for a single pod.
10:13 So far we are talking about multiple ENIs
10:15 assigned to the node,
10:16 but then every pod gets just one IP address,
10:20 that means pod can be a part of only one subnet.
10:23 But like EC2 could have multiple ENIs
10:26 for multi-home kind of architecture,
10:29 similarly pods could also have multiple ENIs
10:33 and this is enabled through something called Multus ENI.
10:37 And this is a link where you can read more about this,
10:40 but essentially if you see on the left side,
10:42 this is a pod without Multus where there is AWS EKS,
10:46 then there is a VPC CNI,
10:48 and every pod gets one network interface IP address.
10:52 And on the right side, this is the Multus implementation,
10:56 Multus CNI implementation.
10:58 Multus can provide you three interfaces to the same pod.
11:02 Now the left one is same as your existing pod networking
11:06 IPv4 address from the VPC.
11:08 And additionally, you could have other interfaces
11:12 attached to your pods.
11:14 So that's just one thing I wanted to mention.
11:17 I'm not really sure if it is covered
11:19 as a part of exam or not,
11:20 but still good to know that pod could be multi-home.
11:24 So it enables attaching multiple interfaces to the pods
11:28 and you can create multi-home pods with multiple interfaces.
11:31 And then AWS supports Multus with VPC CNI by default.
11:38 Okay, with that, we'll stop here.
11:39 I know this could be already overwhelming
11:42 to understand the pod networking,
11:45 but very important for your exam and in general
11:48 if you work on Kubernetes networking,
11:50 I think this will help you a lot.
11:52 So thanks for watching and stay tuned.
整讲总结 / Overall Summary
中文
EKS Pod Networking Part 2 的关键是分清谁做 Source NAT。默认 EXTERNALSNAT=false，Node 把离开 VPC CIDR 的 IPv4 Pod Source 改为 Primary ENI IP；EXTERNALSNAT=true 则保留 Pod IP，把 Internet NAT 交给 NAT Gateway，并让 TGW/Peering/Hybrid Network 看见 Pod Identity。真正可达还依赖双向 Route、CIDR、Security 与 Return Path。Multus 可为需要多网络的 Pod 增加 Secondary Interface。
English
EKS Pod Networking Part 2 is about identifying where source NAT occurs. With the default EXTERNALSNAT=false, the node rewrites IPv4 pod traffic leaving the VPC CIDR to the primary ENI address. With EXTERNALSNAT=true, the pod address is preserved, Internet NAT is delegated to a NAT gateway, and TGW, peering, or hybrid networks can retain pod identity. End-to-end reachability still requires bidirectional routes, CIDR planning, security, and a symmetric return path. Multus adds secondary interfaces for pods that require multiple networks.