IP 池耗尽后 Pod 集体 Pending：TKE 网络选型与节点池治理的 5 个生产决策
概述 凌晨两点，手机被告警轰炸。打开看，TKE 集群里 40 多个 Pod 突然全部进入 Pending 状态，业务接口大面积超时。kubectl describe pod 一看，调度失败原因清清楚楚写着 Insufficient tke.cloud.tencent.com/eni-ip。 这不是什么高深的技术难题。根因是 VPC-CNI 模式下，节点上弹性网卡（ENI）绑定的辅助 IP 用完了。但排查和修复花了 3 个小时——因为没人想到 IP 会耗尽，监控里压根没有这个指标，节点池弹性伸缩也扩不出来（新节点同样绑不上 IP，子网 IP 已被分配光）。 这件事给我最大的教训：TKE 网络选型不是选性能参数，是选故障模式。GlobalRouter 和 VPC-CNI 的差异远不止"性能差 10%“这么简单，它们在 IP 管理、扩缩容行为、监控指标和故障传播路径上完全不同。这篇文章从这次故障出发，拆解 5 个我实际踩过的生产决策，帮你在选型阶段就避开这些坑。 如果你正在用或准备上腾讯云 TKE（容器服务 Kubernetes 引擎），不管是从自建 K8s 迁移还是新建集群，网络模型选型和节点池治理是绕不过去的第一道关。选错了，后面补救的成本远高于选型时多花半天思考。 TKE 三种网络模型：你选的不是性能，是故障模式 先说清楚三种模型是什么，再说为什么选择本质上是"选故障模式”。 GlobalRouter：地址充裕但多了一层转发 GlobalRouter 是 TKE 基于腾讯云 VPC 全局路由能力实现的容器网络方案。原理不复杂：给每个工作节点分配一个 CIDR 网段（通常是 /24），节点上所有 Pod 从这个网段拿 IP，节点充当路由器，通过 VPC 底层路由策略实现 Pod 间通信。 # 查看节点分配的容器网段 kubectl get node <node-name> -o jsonpath='{.spec.providerID}' # GlobalRouter 模式下，每个节点有独立的容器 CIDR 它的优势很明显：容器网段和 VPC 网段不重叠，地址空间充裕，一个 /24 就够 254 个 Pod。扩展性强，标准 K8s 功能无缝兼容， Pod 重启或迁移 IP 会变但 Service 层屏蔽了这个问题。...