Kubernetes 1.36 弃用 externalIPs 后如何平滑迁移？

Kubernetes 1.36 正式弃用 Service 的 externalIPs 字段后，许多运维团队面临一个现实问题：存量业务还在用这个字段暴露服务，而新版本已经开始在控制平面层面收紧这条路径。弃用不等于立即失效，但方向已经明确——后续版本会从 kube-proxy 的实现中彻底移除相关行为。与其等到升级窗口被强制压缩，不如趁现在就把迁移路径走通。

迁移的核心思路不是“禁用后不管”，而是先盘清楚存量，再按业务类型分流。第一步是扫描集群里所有使用了 externalIPs 的 Service，逐项确认每个实例是否仍然必要。这一步不能跳过，因为启用 DenyServiceExternalIPs 准入控制器后，任何对 externalIPs 的新增或修改请求都会被直接拒绝，存量字段虽然还能读取和删除，但已经无法再调整。如果业务方在不知情的情况下尝试修改，会直接收到 Forbidden 错误，线上变更就会卡住。

盘完存量后，替代方案的选型要按集群环境区分。云环境下的集群可以直接切换到 LoadBalancer 类型的 Service，让云厂商的负载均衡器接管公网入口，这是最平滑的路径。裸机或自建集群则通常考虑 MetalLB 这类裸机负载均衡方案，或者退回 NodePort 配合外部负载均衡设备。这里有个容易被忽略的点：如果业务依赖固定的外部 IP 地址，切换到 LoadBalancer 后要注意 loadBalancerIP 字段的分配策略，确保新方案能保留原有地址，否则下游调用方的白名单配置全部要改。

对于确实无法立即迁移的存量 Service，比较务实的做法是引入自定义准入策略做白名单管控。Kubernetes 1.36 时代，ValidatingAdmissionPolicy 已经是成熟方案，可以基于命名空间或标签维度，只允许特定业务继续使用 externalIPs，其余请求一律拒绝。这比直接依赖 DenyServiceExternalIPs 的一刀切更灵活，也为后续逐步收敛提供了管理抓手。

迁移节奏上，建议分三步走。第一阶段先启用 DenyServiceExternalIPs 准入控制器，同时保留存量字段的读取能力，观察一段时间内的拒绝日志，确认没有业务在“悄悄依赖”这个功能。第二阶段根据第一阶段收集到的信息，把确需保留的场景纳入白名单策略，其余业务按计划迁移到替代方案。第三阶段才是真正清理——当所有存量使用都清零后，再考虑在后续版本升级中彻底移除相关配置。这个顺序的好处是，每一步都有明确的验证节点，不会出现“禁用了但不知道谁在用”的被动局面。

整个迁移过程中，最需要警惕的是“以为没人用”的误判。externalIPs 这个字段的使用往往藏在历史遗留的配置里，可能是一个三年前创建的 Service，也可能是某个 Helm Chart 的默认值。建议在启用准入控制器之前，先跑一遍全量扫描，把结果同步给各个业务方确认，而不是自己判断。另外，审计日志要提前配置好，重点关注 decision=forbid 的事件，这样一旦有请求被拦截，能第一时间追溯到具体来源。

externalIPs 的弃用本质上是 Kubernetes 在收拢控制平面中“过于强大且难以治理”的能力。对运维团队来说，这既是约束也是机会——趁这次迁移，把服务暴露方式统一梳理一遍，反而能消除不少历史遗留的安全隐患。迁移完成后，建议把这项检查纳入常规的安全基线，定期核查准入控制器配置，避免未来集群重建或升级时配置漂移。