Lecture 245: EKS Pod Networking - Part 1
- 课程：[NEW] AWS Certified Advanced Networking Specialty 2026
- 视频时长：15:59
- 来源：Udemy Lecture 35813122
- Slide 数量：7
- 画面切换：03:09、04:22、07:36、09:55、12:11、14:50
扫描说明
逐条读取了 Transcript 面板中的 327 条英文 cue，并按播放器进度同步全长约 15:59 的视频。依据 Kubernetes Network Model、CNI/VPC CNI、ENI Secondary IP、Maximum Pods、Prefix Delegation、IPv6、Pod-to-Pod Communication 划分为 7 个小节。7 张截图来自真实课程 Slide，统一为 1364×770。
Transcript 来自 Udemy 页面自带的英文自动字幕，没有使用 ASR。下面保留页面原文，包括其中的语法或识别错误。
1. Kubernetes Network Model：Pod 是可直接寻址的网络实体
时间范围：00:00–03:09
总结 / Summary
中文
Kubernetes Network Model 要求每个 Pod 拥有自己的 IP；同一 Pod 内的 Container 共享 Network Namespace/IP，可经 localhost 互通；任意 Pod 之间、Node 与 Pod 之间应能在不做 NAT 的情况下通信；Pod 自己看到的 Source/Destination Identity 应与其他实体看到的一致。这里的目标是建立 Flat、直接可寻址的 Pod Network，而不是让每个 Container 单独拥有 VPC IP。实际可达性仍受 Route、Security Group、NACL、Kubernetes NetworkPolicy 与 Application Listener 约束。
English
The Kubernetes network model gives every pod its own IP address. Containers in the same pod share a network namespace and IP and can communicate over localhost. Pods must be able to communicate with other pods, and nodes with pods, without NAT; the address a pod sees for itself should be the address other participants use. This creates a flat, directly addressable pod network rather than giving every container a separate VPC address. Actual reachability still depends on routes, security groups, NACLs, Kubernetes NetworkPolicy, and application listeners.
Transcript
00:00 Hello and welcome to this lecture,
00:02 Amazon EKS Pod Networking.
00:04 Now this is one of the important lecture of this section
00:08 because we are going to learn
00:09 how the IP addresses are assigned to pods,
00:13 how pods communicate with each other.
00:15 And in the following lectures,
00:16 we'll see more details around
00:18 how pods communicate with external network,
00:21 how pods are exposed as services,
00:23 and all this could be a part of your exam questions.
00:27 Now, one thing to just reiterate that
00:29 we are not really getting too deep into
00:32 how Kubernetes work and how deployment works in Kubernetes
00:35 because in itself, it could be a long course.
00:39 Idea is here to just cover the networking part,
00:42 and that's to focusing on the EKS.
00:45 So please, pardon, if you think that this course,
00:48 or this lectures doesn't cover enough depth of Kubernetes,
00:52 however I still try to keep it little simple
00:55 even if you don't have much of Kubernetes knowledge.
00:57 You should be able to understand what's happening here.
01:00 And for those who don't know Kubernetes,
01:02 I have included a lecture
01:04 to introduce you to the Kubernetes,
01:07 so I hope that's fine with you.
01:09 Okay, so let's understand how EKS Pod networking works.
01:13 So before we get into the specifics of EKS,
01:16 how it supports the Pod networking,
01:18 it is important to understand
01:20 some of the principles of Kubernetes networking,
01:24 and that is defined as a part of Kubernetes network model.
01:27 Now this has been defined by CNCF as you know,
01:30 Cloud Native Computing Foundation.
01:32 So CNCF defines some networking specification,
01:36 and then this is up to the network provider
01:39 how they implement this specifications.
01:41 So some of the specifications which CNCF defines
01:45 are every port gets its own IP address.
01:48 That means port should be treated
01:50 more like a first class citizen of the network,
01:53 not like containers, like if multiple containers
01:56 are running on the same host, typically,
01:58 they have a different OL network inside,
02:01 but pod should get their own IP address.
02:05 Second, containers in the same pod
02:07 share the same network IP address space.
02:09 That means they do not need to have separate IP addresses,
02:13 but they can talk over the local host network.
02:17 Third, all pods can communicate with all other pods
02:20 without using the network address translation.
02:23 And somewhere links to the first point
02:25 that if there are two pods,
02:27 they're kind of first class citizen of the network,
02:30 and they can directly communicate with each other
02:32 without having any NAT devices,
02:35 or any proxy devices in between.
02:37 Similarly, all nodes can communicate
02:39 with all pods without NAT,
02:41 so there shouldn't be NAT
02:43 when nodes wants to communicate with the pod.
02:46 And finally, the IP that a pod sees itself
02:50 as is the same IP that others sees it as.
02:53 Little confusing statement,
02:55 but essentially what it means that
02:56 there is no destination not happening,
02:59 that means whatever IP pods is, others
03:02 who wants to connect to the pod
03:04 also sees the same IP address.
03:06 So these are the specification defined by CNCF,
2. CNI 定义标准接口，Amazon VPC CNI 将 Kubernetes 接入 VPC
时间范围：03:09–04:22
总结 / Summary
中文
CNI（Container Network Interface）是 Runtime 调用 Network Plugin 的标准接口；Cloud Provider 或第三方实现 Plugin，以完成 Interface Creation、IP Allocation 与 Route/Rule Programming。EKS 默认使用 Amazon VPC CNI，把 Pod Addressing 接到现有 VPC Subnet：Plugin 在 Worker Node 上创建/附加 ENI，并从 Subnet Address Space 为 Pod 提供地址。因此 Pod 可像 VPC 内的一等网络实体一样参与 Routing，但也会消耗 Subnet IP Capacity。
English
CNI, the Container Network Interface, is the standard interface through which runtimes invoke networking plugins. Cloud providers and third parties implement plugins to create interfaces, allocate addresses, and program routes or rules. EKS uses the Amazon VPC CNI by default to connect pod addressing to existing VPC subnets: the plugin creates or attaches ENIs to worker nodes and supplies pod addresses from subnet address space. Pods therefore participate in VPC routing as first-class network entities, while consuming subnet IP capacity.
Transcript
03:09 and all these specifications are then implemented as of CNI.
03:14 Now, CNI is Container Network Interface.
03:17 So every cloud provider, for example AWS or Google or Azure,
03:23 will define their own CNI plugin,
03:25 so AWS also did the same thing.
03:28 There is CNI plugin implemented for AWS VPC
03:32 to support this kind of networking.
03:35 And that plugin is called VPC CNI, of course, right?
03:38 So let's get into the VPC CNI.
03:41 So Amazon VPC CNI plugin does exactly
03:44 what the specification says.
03:46 Now if you look at this VPC, you have the subnets,
03:50 and then you could assign IPv4 or IPv6
03:53 that we already learned in EKS architecture.
03:57 Then you have the worker nodes,
03:58 and these nodes have the pods, right?
04:00 So how does VPC CNI assigns IP addresses
04:04 to the individual pods?
04:06 Now that's interesting because
04:08 so far, you might have just assigned
04:10 one IP address to the EC2 instance,
04:13 but now one instance hosts multiple pods.
04:18 Then how could you assign
04:19 multiple IP addresses to those pods?
3. IPv4 Pod 使用 ENI Secondary IP，容量受 Instance-type ENI/IP Limit 约束
时间范围：04:22–07:36
总结 / Summary
中文
一块 ENI 有 Primary IP，也可有多个 Secondary IP；默认 IPv4 模式下，VPC CNI 把 Secondary IPv4 分配给 Pod，ENI Primary IP 留给 Node/ENI 本身。可挂 ENI 数和每块 ENI 的 IPv4 Address 数由 EC2 Instance Type 决定，因此同一 Subnet 中的 Pod IP 与 Node IP 可直接走 VPC Fabric。Amazon VPC CNI 是 EKS 的默认/受支持方案；Calico 等第三方 CNI 也可提供 Overlay 或 Network Policy 能力，但 Addressing、Support Boundary 与 Operational Model 会不同。
English
An ENI has a primary address and can have multiple secondary addresses. In the default IPv4 mode, the VPC CNI assigns secondary IPv4 addresses to pods while the primary address remains associated with the node or ENI. The number of attachable ENIs and addresses per ENI depends on the EC2 instance type, so pod and node addresses in the same VPC can use native VPC forwarding. Amazon VPC CNI is the default supported EKS model; third-party CNIs such as Calico can add overlay or network-policy capabilities, but their addressing, support boundaries, and operational models differ.
Transcript
04:22 So what Amazon VPC CNI does for this,
04:25 it creates and attaches ENI to the worker nodes.
04:29 Now you know that when we say IP address,
04:31 ultimately it comes from the elastic network interfaces
04:34 which AWS provides and you can attach multiple ENI
04:38 to the same EC2 machine, right?
04:41 And then one CNI is not just one IP address,
04:44 there is something called a primary IP address,
04:46 and then there are multiple secondary IP addresses.
04:50 So ENI consists of multiple IP addresses altogether.
04:55 And in terms of VPC CNI,
04:58 it assigns the secondary IP addresses to the pods.
05:01 So in this diagram, you see there is a primary ENI,
05:05 which comes with the primary IP address,
05:07 and then there are additional secondary IP addresses.
05:10 Now, this really depends on your instance type,
05:13 so different instance type would support
05:16 different number of ENIs,
05:18 maybe some instances support just one ENI,
05:20 in that case, it'll be just one primary ENI,
05:23 but some instances might support more than one ENI,
05:27 maybe three, maybe 10,
05:29 so there is already documented instance types,
05:32 and supported ENI, which you can check for that.
05:35 But here you can see that there is a primary ENI,
05:39 and then there is primary IP address attached to that ENI.
05:43 And there are multiple secondary IP addresses.
05:46 Now this is also depending on instance type
05:48 how many secondary IPs one ENI will support,
05:52 and we'll look into that shortly.
05:54 But in this diagram, you can see
05:55 this instance type has two ENIs, one is called primary ENI,
05:59 another is called secondary ENI.
06:01 And then ENI has primary IP address,
06:04 and ENI has secondary IP addresses.
06:07 So altogether, you can see,
06:09 there are three secondary IP addresses for ENI one,
06:13 and three secondary IPs for ENI two.
06:16 Now what VPC CNI does,
06:18 it assigns this secondary IPs to the pods.
06:22 It doesn't assign the primary IP,
06:24 it only assigns the secondary IPs.
06:26 So thing to remember that VPC CNI attaches secondary IPs.
06:31 And here we are all talking about the IPv4 addresses.
06:35 So likewise, all these IPs which you see here
06:38 are now assigned to the pods,
06:39 and that's where Pod gets the IP addresses
06:42 from your VPC address space.
06:45 So they become kind of first class citizen of your VPC.
06:49 Now, Amazon EKS officially supports
06:51 the Amazon VPC CNI plugin for Kubernetes,
06:54 that's what we are seeing here.
06:56 But there are also a lot of
06:58 third party implementation of the CNI
07:01 because CNI is a specification, right?
07:03 So anybody can implement, you can also write CNI,
07:07 and can plug it into, you know, EKS for example.
07:10 So likewise there are different companies
07:13 who have their own networking plug-ins.
07:15 I have worked on Calico, which is very famous.
07:18 It allows to have the network policies,
07:22 and it has lot many controls when it comes to the security.
07:26 But then you can choose which CNA plugin works best for you.
07:30 Otherwise, AWS VPC CNI is officially supported by EKS.
4. 无 Prefix Delegation 时，ENI/IP Slot 决定 Maximum Pods per Node
时间范围：07:36–09:55
总结 / Summary
中文
本讲给出的传统 IPv4 估算式是 Max Pods = ENI 数 × (每 ENI IPv4 数 − 1) + 2；减 1 是排除每块 ENI 的 Primary IP，+2 表示保留的 Host-network Pod Allowance。以 m5.large 的 3 ENI、每 ENI 10 IPv4 为例得到 29。这个公式描述经典 VPC CNI Secondary-IP 模式，不应被当作所有现代 Cluster 的绝对上限：AMI max-pods 配置、VPC CNI 版本、Prefix Delegation、Custom Networking、CPU/Memory 与 EKS/Kubernetes Recommended Cap 都会改变实际可调度数。
English
The lecture uses the traditional IPv4 estimate Max Pods = ENI count × (IPv4 addresses per ENI − 1) + 2. Subtracting one excludes each ENI's primary address, while the +2 represents a host-network pod allowance. An m5.large with three ENIs and ten IPv4 addresses per ENI therefore yields 29. This describes the classic VPC CNI secondary-IP mode and is not an absolute limit for every modern cluster: AMI max-pods settings, VPC CNI version, prefix delegation, custom networking, CPU and memory, and EKS or Kubernetes recommended caps affect the schedulable total.
Transcript
07:36 So that's in short is the VPC CNA.
07:39 Now, after this you might have got question.
07:43 If that is the case
07:44 where you can only attach the secondary IPs,
07:47 then how many parts I can host on a node?
07:49 So, let's look at that now.
07:53 So maximum pods per node and here also,
07:56 we are talking about IPv4 to start with.
07:58 Now, as you might have guessed,
08:00 it really depends on how many ENIs
08:02 you can attach to the particular instance,
08:05 and then how many secondary IPs that ENI has, right?
08:09 So for example, you can find this table
08:13 in AWS documentation.
08:15 If it's m5.large instance, it supports maximum three ENIs,
08:20 and then it supports 10 IPv4 addresses
08:24 per networking interface,
08:25 and 10 IPv6 addresses per interface.
08:29 And if you want to calculate now,
08:31 how many parts you can attach,
08:33 then formula will be something like this.
08:36 Total number of network interfaces,
08:38 so there are three into maximum IPs
08:42 per network interface minus one, minus one
08:45 because primary IP is not assigned to the pods plus two.
08:49 Now this plus two is for
08:51 because Kubernetes would have two pods,
08:54 one for host networking,
08:55 and one for kube-proxy on every node.
08:58 So these are the additional pods
09:00 that anyways Kubernetes runs.
09:03 So max pod would be this formula.
09:06 Now if you take an example of m5.large, for example,
09:09 then m5.large has three network interfaces,
09:12 10 IPv4 addresses per network interface.
09:15 So it becomes 29 pods.
09:18 So if you have m5.large instance,
09:20 you can host 29 total pods.
09:23 Now, someone can say that 29 pods is less,
09:27 I'm not able to use full capacity of my instance,
09:31 and I want to increase this number.
09:33 And this is typically called you know, pod density.
09:37 How much is a pod density for the node?
09:39 And this has been the problem
09:40 with maybe a lot of customers which AWS served.
09:44 And then AWS came up with some advanced networking
09:47 where one host or one instance could host additional pods.
09:52 So let's look at that now, how it is possible.
5. Prefix Delegation 用 /28 或 /80 扩大 Pod IP Pool，但不等于应塞满 Node
时间范围：09:55–12:11
总结 / Summary
中文
Nitro-based EC2 可让 VPC CNI 把 Prefix 而非单个 Secondary IP 关联到 ENI Slot：IPv4 /28 提供 16 个地址，IPv6 /80 提供极大的 Address Pool。这样减少逐个分配 IP 的限制与 API Pressure，显著提高 Pod Density；本讲以 m5.large 给出从 29 到理论 434 个 IPv4 Pod 的地址容量示例。但 Address Availability 不等于合理的 Compute/Scheduler Capacity；Kubernetes 常见推荐上限为每 Node 110 Pod（较大实例/新版 EKS 可能采用其他 Cap），应以当前 EKS AMI Calculator、Instance Type 与 Workload Resource 为准。
English
On Nitro-based EC2 instances, the VPC CNI can associate a prefix rather than one secondary address with an ENI slot. An IPv4 /28 supplies 16 addresses, while an IPv6 /80 supplies a very large pool. This reduces per-address allocation constraints and API pressure and can greatly increase pod density; the lecture uses an m5.large example that grows from 29 to a theoretical IPv4 address capacity of 434 pods. Address availability is not the same as sensible compute or scheduler capacity. A common Kubernetes recommendation is 110 pods per node, although larger instances and current EKS versions may use other caps, so use the current EKS AMI calculator, instance type, and workload resources.
Transcript
09:55 So increase available IP addresses for the pods.
09:58 If you have more IP addresses,
09:59 of course you can host more pods, right?
10:02 Now for that, AWS launched a new feature,
10:04 but it is only supported on Nitro-based instances.
10:07 Now, that feature is called prefix delegation.
10:11 Now what is prefix delegation?
10:13 Instead of individual IP addresses,
10:16 you could assign the CIDR block to your ENIs.
10:20 Instead of single IP addresses,
10:22 you can give a full CIDR block
10:24 with /28 for IPv4, and /80 block for IPv6.
10:30 Now you know that /28 provides 16 IP addresses.
10:33 That means instead of one secondary IP,
10:37 you get 16 secondary IPs.
10:39 And if you have 10 secondary IPs supported,
10:43 then you would have 160 secondary IPs.
10:46 So that means your range is now increased
10:49 by almost 16 times for IPv4,
10:53 and then in trillions for IPv6 addresses, right?
10:58 So this is a special feature supported on Nitro instances.
11:02 And here you can see that
11:04 you can support many, many IP addresses,
11:07 and that means you can launch many many pods
11:09 on the same EC2 instance type.
11:12 If you take just the same example of m5.large,
11:16 then for IPv4 addresses, you could support
11:20 434 pods instead of 29 pods.
11:23 Okay, but is that the way typically you would do that?
11:27 I mean would you really host 434 pods on the single node?
11:32 Though technically you can launch those many pods,
11:35 but then Kubernetes itself has some kind of limitation,
11:38 and recommendation how many maximum pods
11:40 you should typically have on any node.
11:43 And that limited based on, you know,
11:46 your processes which are running on those nodes
11:48 kube-proxy, kubelite, EPS server traffic,
11:52 and the way Kubernetes manages the state of the nodes,
11:56 and schedule the pods on the nodes,
11:59 there is a recommended number, which is 110.
12:03 So it's recommended that you shouldn't typically exceed
12:06 this limit of number of pods per instance type.
6. EKS IPv6 Cluster 依赖 Nitro/Fargate 与 /80 Prefix，不是 Pod Dual-stack
时间范围：12:11–14:50
总结 / Summary
中文
IPv6 模式面向 Nitro-based Node 与 Fargate；EC2 Node 上必须把 Amazon VPC CNI 配置为 IPv6 Prefix Delegation，由 ENI /80 Prefix 给 Pod 分配全局唯一 IPv6。课程口径是 Cluster 选择 IPv4 或 IPv6，单个 Pod 不同时获得两种地址；VPC/Node 仍需 IPv4 能力支持 EKS/VPC 的部分控制与兼容路径，Subnet 还要启用 Auto-assign IPv6。讲师同时指出当时 Windows Pod/Service 不支持 IPv6。EKS IP-family、Dual-stack 与 Windows 支持持续演进，这些状态型结论应在实施前核对当前 AWS Documentation。
English
IPv6 mode targets Nitro-based nodes and Fargate. On EC2 nodes, Amazon VPC CNI must use IPv6 prefix delegation so pods receive globally unique IPv6 addresses from an ENI /80 prefix. The lecture presents a cluster as choosing IPv4 or IPv6 rather than assigning both address families to one pod. The VPC or node still needs IPv4 capability for parts of the EKS and VPC control or compatibility paths, and subnets must enable automatic IPv6 assignment. It also states that Windows pods and services did not support IPv6 at recording time. EKS IP-family, dual-stack, and Windows capabilities evolve, so verify these stateful claims in current AWS documentation before implementation.
Transcript
12:11 Okay, we talked about IPv4 addresses.
12:13 Now, let's talk about IPv6 addresses.
12:16 As you know, IPv6 addresses are public and globally unique.
12:21 And there are a lot of IPv6 addresses.
12:24 You start with /56 range for your VPC,
12:27 and then you can create subnet with /64 which gives you,
12:32 so two to the 64 IP addresses for your subnet,
12:35 which is again in trillions, right?
12:38 So you can assign IPv6 addresses
12:40 to your VPC and to your subnets.
12:43 But then there are certain limitations
12:44 which you need to know.
12:46 First of all, IPv6 addresses
12:48 are supported for Nitro based instances.
12:50 So Nitro is Amazon design hypervisor,
12:54 which is much more efficient than the open source,
12:57 or commercial hypervisor which are there in the market.
13:01 And most of the new instance types that AWS is launching
13:05 is based on the Nitro hypervisor.
13:07 So IPv6 IP addresses are supported
13:10 for Nitro-based instances as well as for AWS Fargate.
13:14 Now, we learned that you could launch your pods on Fargate,
13:18 and in that case you can assign
13:20 IPv6 addresses to those pods.
13:22 So by default, Kubernetes assigns
13:24 IPv4 addresses to the pods, but as you know,
13:27 you could also create your cluster with IPv6 addresses,
13:31 but EKS doesn't support dual-stack.
13:33 That means pod cannot have both
13:35 IPv4 and IPv6 address at the same time,
13:38 so keep that in mind.
13:39 Now for EC2 nodes, you must configure
13:42 the Amazon VPC CNI add-on
13:44 with IPv6 prefix delegation, and IPv6,
13:48 that means if you want to use IPv6 addresses
13:51 then you should must use the prefix delegation
13:54 what we just learned in the last slide.
13:57 That means you need to define
13:58 the /80 prefix for IPv6 addresses,
14:02 and then you can assign those addresses to the pods.
14:06 Further, you must also assign IPv4 address to your VPC.
14:10 Now, this is confusing one way we are saying that
14:13 you can't use both the IP addresses
14:15 at the same time for the pods, that's true.
14:18 But in order for this IPv6 addresses to work,
14:22 you need to assign IPv4 range to your VPC
14:25 because the way VPC has built,
14:28 it needs IPv4 addresses for functioning.
14:31 And then subnet must have
14:32 auto-assign and IPv6 address enabled
14:35 so that when pods are launched in that subnet,
14:38 and the nodes are launched in that subnet,
14:40 they automatically get the IPv6 addresses.
14:44 And finally, IPv6 addresses are not supported
14:47 for Windows pods and services as of now.
7. 同 VPC Pod-to-Pod 直接使用 Pod IP，跨边界流量留到 Part 2
时间范围：14:50–15:59
总结 / Summary
中文
同一 VPC 中，不同 Worker Node 上的 Pod 使用各自 VPC-routable Pod IP 直接通信，不需要 SNAT/DNAT 或 Overlay Gateway；VPC Router 依据 Subnet Route 转发，Return Path 也直接回到 Source Pod IP。这满足 Kubernetes Network Model 的身份一致性。所谓“Direct”并不绕过 Security Control：Security Group for Pods、Node SG、NACL、NetworkPolicy 与 Application Port 仍可能阻断 Flow。Pod 访问 Internet、Peered/TGW VPC、VPN/Direct Connect On-prem 等 External Network 时，Source NAT 与 Route 行为不同，是下一讲主题。
English
Within one VPC, pods on different worker nodes communicate directly using their VPC-routable pod addresses, without a pod-to-pod SNAT, DNAT, or overlay gateway. The VPC fabric forwards according to subnet routing, and the return path addresses the source pod directly, satisfying Kubernetes identity consistency. Direct does not bypass security controls: security groups for pods, node security groups, NACLs, NetworkPolicy, and application ports can still block the flow. Source-NAT and routing behavior changes when pods reach the Internet, peered or transit-gateway VPCs, or on-premises networks over VPN or Direct Connect, which is the subject of Part 2.
Transcript
14:50 Now, the important part
14:53 how Pod communicates with other pods.
14:55 Now, if all the pods are part of the same VPC,
14:59 you know that pod have their own IP addresses,
15:03 so they can communicate directly with each other.
15:03 And if you remember, this was kind of
15:08 defined in a specification as well
15:11 that pod should be able to communicate
15:12 with each other without any NAT, right?
15:15 So if on the left side there is a pod
15:18 wants to communicate on another pod, on another worker node,
15:21 it just talks directly over normal VPC communication.
15:25 So pods within the same VPC
15:27 can communicate directly using the Pod IP address.
15:30 So, we just understood the basics of the Pod networking.
15:34 Now we will get into more specifics about
15:37 how pods can communicate to the external world.
15:39 That means to the internet or to the other VPCs
15:42 connected through transit gateway,
15:44 or to on-premise network over VPN or EDX.
15:49 And it works little differently.
15:51 So, it is important that you understand all those things.
15:54 So, we'll cover that shortly in the next lecture.
15:56 So, thanks for watching and stay tuned.
整讲总结 / Overall Summary
中文
EKS Pod Networking Part 1 的核心链路是：Kubernetes 要求 Pod 直接可寻址；Amazon VPC CNI 把 Pod 接入 VPC，并在经典 IPv4 模式中使用 ENI Secondary IP。Instance ENI/IP Limit 决定传统 Pod Density，Nitro Prefix Delegation 用 /28 或 /80 扩大地址池，但实际 Max Pods 还受 EKS/AMI 与计算资源约束。IPv6 Cluster 使用 /80 Prefix，Pod-to-Pod 在同 VPC 中直接按 Pod IP 通信。
English
EKS Pod Networking Part 1 follows one central chain: Kubernetes requires directly addressable pods; Amazon VPC CNI connects them to the VPC and, in classic IPv4 mode, uses ENI secondary addresses. Instance ENI and address limits determine traditional pod density, while Nitro prefix delegation expands the pool with /28 or /80 prefixes; actual max pods still depend on EKS, AMI, and compute limits. IPv6 clusters use /80 prefixes, and pods in one VPC communicate directly by pod IP.