Google Cloud在2026年9月25日把GKE Standard集群的单节点Pod上限从256提高到512。对运行大量小型服务、任务执行器和多租户工作负载的团队来说，同一节点可以容纳更多Pod，节点数量与集群管理开销有机会下降。
上限翻倍不等于把配置改成512就能获得两倍容量。Pod密度同时受CPU、内存、磁盘、网络、kubelet和IP地址空间影响。Google为257至512个Pod的节点分配一个/22地址段，也就是1024个Pod IP，网络规划必须先跟上。
512个Pod只适用于Standard集群
新的512上限面向GKE Standard，默认值仍然是每节点110个Pod。管理员需要在创建集群时设置默认上限，或在现有集群中创建新的节点池并单独指定。
Autopilot不会开放同样的手动配置。它会根据工作负载密度在8至256之间选择上限，用户无法把Autopilot节点直接改为512。
512是调度上限，不是每台节点都应该塞满的目标值。系统Pod也会占用名额，实际可分配给业务的数量低于配置值。
高密度节点会消耗更大的Pod地址段
GKE为每个节点预留的Pod地址数量至少是Pod上限的两倍，以降低Pod反复创建和删除时快速复用IP带来的问题。默认110个Pod对应每节点一个/24地址段，共256个地址。
当上限设置在257至512之间时，每个节点会获得一个/22地址段，共1024个地址。假设Pod二级网段大小固定，同一网段能够容纳的节点数量会明显减少。
集群扩容时不只需要节点主IP，还要为每台新节点准备完整的Pod CIDR。没有先算地址容量，节点自动扩容可能因为Pod IP不足而失败，即使CPU和实例配额仍然充足。
现有节点池不能原地修改上限
最大Pod数在集群或节点池创建后不可直接更改。已有节点池想采用512上限，需要创建新节点池，通过--max-pods-per-node=512指定参数，再逐步迁移工作负载。
迁移过程应先检查PodDisruptionBudget、反亲和规则、固定节点标签、本地存储和有状态服务。直接排空旧节点可能因可用副本不足或调度条件不匹配而卡住。
节点池级配置会覆盖集群默认值，因此同一集群可以按工作负载设置不同密度。轻量无状态任务使用高密度池，数据库和资源敏感服务保留较低密度，管理上更灵活。
Google建议高密度节点至少使用16核
Google在网络最佳实践中建议，超过默认110个Pod的高密度配置使用16核或更大的实例。Pod越多，kubelet状态维护、日志采集、网络规则、健康检查和容器运行时的管理开销越高。
大量小Pod还会放大突发CPU、内存回收、镜像拉取和磁盘I/O竞争。即使资源请求总和没有超过节点容量，短时间集中启动也可能让节点出现延迟尖峰。
上线前应使用真实副本数进行压力测试，观察Pod启动时间、kubelet延迟、conntrack、网络吞吐、磁盘等待和节点NotReady事件，而不是只确认调度器能把512个Pod放进去。
更高密度不一定带来更低成本
节点数量减少可能降低每节点固定开销，也能让部分资源利用率更高。但故障影响范围会扩大，一台节点重启时需要重新调度的Pod更多，镜像仓库、控制平面和网络都会承受更集中的恢复流量。
高密度节点还会减少副本跨主机分散的机会。关键服务需要配合拓扑分布约束、Pod反亲和与多个可用区，避免多个副本为了提高利用率被挤到同一台大节点上。
更稳妥的做法是先选一个无状态节点池，从128或256逐步提高密度，记录每Pod成本和故障恢复时间。确认IP空间、性能与可用性都符合要求后，再决定是否使用512上限。
