从大模型训练与推理出发：亚马逊云科技容器环境 IP 消耗、规划与 VPC CNI 优化
内容提要
本文探讨亚马逊云科技容器环境中IP地址消耗问题，重点针对大模型训练/推理场景下大型GPU节点Pod密度低但VPC CNI默认预留大量IP导致子网浪费。文章分析EKS、ECS等场景的IP消耗风险，提出优化方案：优先考虑IPv6、Prefix Delegation、Custom Networking等架构调整，也可通过设置MINIMUM_IP_TARGET、WARM_IP_TARGET等参数控制单节点IP分配，并强调需同步配置kubelet maxPods、监控和验证。
延伸解读
IP 浪费比：一个实用的观察指标
文章提出了一个非官方但实用的指标：IP浪费比 = CNI已分配secondary IP / 实际使用独立IP的Pod数。该指标可帮助快速评估集群中IP的利用效率。当该比值远大于1时，说明存在大量IP被预留但未被Pod使用，尤其是在大型GPU节点上。建议定期计算该指标，并结合子网剩余地址和Pod密度进行综合判断，以决定是否需要调整CNI参数或优化网络架构。
参数调优的权衡：弹性与浪费
文章强调，通过设置MINIMUM_IP_TARGET、WARM_IP_TARGET等参数可以控制单节点IP分配，但必须权衡弹性与浪费。将WARM_IP_TARGET设为0虽然能减少IP浪费，但会牺牲突发扩容能力，可能导致新Pod因IP不足而创建失败。亚马逊云科技建议将MINIMUM_IP_TARGET与正数WARM_IP_TARGET配合使用，以保留一定弹性。因此，在调整参数时，需根据业务对扩容速度和IP利用率的实际需求进行权衡。
架构优化优先于参数压缩
文章明确指出，压缩warm pool只是战术优化，长期来看应优先考虑架构层面的调整。亚马逊云科技推荐优先评估IPv6、Secondary CIDR、Custom Networking和Enhanced Subnet Discovery等方案。这些方案能从根源上解决IPv4地址空间不足的问题，而参数调优仅适用于临时缓解或特定场景。因此，在规划IP容量时，应首先考虑架构优化，再考虑通过CNI参数进行微调。
Q&A
在亚马逊云科技容器环境中，大模型训练场景为什么容易造成IP地址浪费？
大型GPU节点通常只运行少量Pod，但Amazon VPC CNI默认会预留一整张ENI的地址容量（WARM_ENI_TARGET=1），导致大量IP未被实际使用，造成子网地址浪费。
如何优化Amazon VPC CNI以减少IP浪费？
可以通过设置MINIMUM_IP_TARGET、WARM_IP_TARGET、WARM_ENI_TARGET和MAX_ENI等参数来控制单节点IP分配，例如设置MINIMUM_IP_TARGET=10、WARM_IP_TARGET=0、WARM_ENI_TARGET=0、MAX_ENI=1，以减少预分配IP。
除了调整CNI参数，还有哪些更推荐的IP规划方案？
亚马逊云科技更推荐优先考虑IPv6、Prefix Delegation、Custom Networking、Secondary CIDR和Enhanced Subnet Discovery等架构调整，这些方案能从根本上解决IPv4地址空间不足的问题。
调整VPC CNI参数时，为什么需要同步配置kubelet maxPods？
因为CNI地址上限不等于调度上限，如果kubelet仍报告较大的Pod容量，调度器可能继续分配Pod，导致Pod因IP不足而创建失败。因此需要同步调整maxPods，确保调度容量与IP容量一致。
在EKS中，默认的IP分配行为是怎样的？
默认情况下，EKS节点上的aws-node DaemonSet（ipamd）会调用EC2 API管理ENI和IP，默认WARM_ENI_TARGET=1，即保持一张空闲ENI及其地址容量，导致大型实例即使只有少量Pod也会预留大量IP。
使用Prefix Delegation时需要注意哪些问题？
Prefix Delegation按/28（16个地址）分配，需要子网有连续地址块，否则会出现InsufficientCidrBlocks错误。同时需要同步调整maxPods，并注意子网碎片化问题。
如何监控容器环境的IP地址使用情况？
可以使用CNI Metrics Helper和CloudWatch监控已分配ENI数量、分配给Pod的IP数量、子网剩余地址等指标，并设置告警，告警阈值应覆盖一次最大扩容、升级或故障切换的需求。
在滚动升级或蓝绿部署时，IP消耗会有什么变化？
滚动升级或蓝绿部署期间，新旧节点会同时存在，每台新节点都会建立CNI warm pool，导致IP峰值可能高于普通节点数量翻倍，因此需要按峰值规划子网容量。
