Kubernetes 一个用了很多年的功能即将被移除：Service ExternalIPs 为什么被官方废弃？

对于很多刚接触 Kubernetes 的同学来说，可能从未使用过 ExternalIPs；但对于一些早期部署的集群、私有云环境以及边缘计算场景来说，这曾经是一个非常常见的功能。

那么：

• ExternalIPs 到底是什么？
• 它解决了什么问题？
• 为什么 Kubernetes 官方决定废弃它？
• 现有集群应该如何应对？

今天我们就来聊聊这个即将退出历史舞台的 Kubernetes 功能。

什么是 ExternalIPs？

在 Kubernetes 中，Service 默认有几种常见类型：

ClusterIP
NodePort
LoadBalancer
ExternalName

其中最常用的是 ClusterIP 和 NodePort。

而 ExternalIPs 则是一种特殊能力。

例如：

apiVersion: v1
kind:Service
metadata:
name:nginx
spec:
selector:
    app:nginx
ports:
-port:80
    targetPort:80
externalIPs:
-192.168.10.100

创建完成后：

192.168.10.100:80
      ↓
Service
      ↓
Pod

集群会将访问该 IP 的流量直接转发到对应 Service。

换句话说：

ExternalIPs 允许管理员将一个外部 IP 地址直接绑定到 Kubernetes Service。

它为什么会出现？

时间回到 Kubernetes 早期。

那时候：

• 公有云 LoadBalancer 并不普及
• MetalLB 还没有诞生
• Gateway API 更不存在

很多企业部署的是：

裸金属服务器
私有云
机房环境

管理员需要一种简单方式：

指定一个固定IP
↓
映射到Service
↓
对外提供服务

于是 ExternalIPs 出现了。

在当时看来，这是一个非常方便的方案。

ExternalIPs 的工作原理

很多人误以为：

ExternalIPs = Kubernetes 分配 IP

实际上完全不是。

Kubernetes 并不会创建这个 IP。

例如：

externalIPs:
- 192.168.10.100

系统默认认为：

192.168.10.100
已经存在
并且能够路由到当前节点

Kubernetes 只是负责：

接收到该IP流量
↓
转发到Service
↓
转发到Pod

真正的网络路由配置仍然需要管理员自行完成。

问题开始出现

随着 Kubernetes 的普及，社区逐渐发现：

ExternalIPs 带来了大量安全问题。

最典型的问题就是：

IP 劫持

假设企业网络中存在：

192.168.1.10

原本属于某台业务服务器。

如果有人创建：

externalIPs:
- 192.168.1.10

那么流量可能被 Kubernetes Service 接管。

造成：

流量重定向
业务异常
安全风险

这种行为本质上类似于：

IP Hijacking
（IP 劫持）

权限边界不清晰

更严重的问题是：

很多开发人员拥有创建 Service 的权限。

例如：

kubectl apply -f service.yaml

但他们并不拥有网络管理权限。

然而通过：

externalIPs:
- x.x.x.x

却能够影响整个网络流量。

这就导致：

应用权限 ≠ 网络权限

权限边界被打破。

这也是 Kubernetes 社区长期争论的问题之一。

多租户环境风险更高

在企业 Kubernetes 集群中：

团队A
团队B
团队C

往往共享同一个集群。

如果允许任意创建：

externalIPs

那么可能出现：

团队A占用IP
团队B业务冲突
团队C流量异常

管理员很难进行统一管理。

因此越来越多的企业直接禁止使用该功能。

社区最终决定废弃

随着云原生生态逐渐成熟：

Kubernetes 已经拥有更安全、更标准的方案。

例如：

公有云

LoadBalancer Service

AWS、阿里云、腾讯云、华为云等均已支持。

裸金属环境

MetalLB

目前已经成为事实标准。

支持：

L2模式
BGP模式
IP地址池管理
高可用

远比 ExternalIPs 更完善。

新一代入口方案

Gateway API

正在逐步替代传统 Ingress。

未来：

Gateway API
+
LoadBalancer
+
MetalLB

将成为主流架构。

如果你的集群还在使用 ExternalIPs 怎么办？

时间线：什么时候轮到你的集群？

根据目前的公开信息，废弃的节奏大致是这样的：

• Kubernetes v1.36（2026 年 4 月发布）：.spec.externalIPs字段正式标记为 deprecated。当你创建或更新使用了该字段的 Service 时，kube-apiserver 会返回警告信息。同时引入 AllowServiceExternalIPs特性门控（默认关闭），用来关闭 kube-proxy 对该功能的支持。
• Kubernetes v1.43（预计 2027 年底左右）：计划彻底移除。官方预计在该版本中从 kube-proxy 中删除该行为的实现，并更新 Kubernetes 一致性标准，要求符合标准的实现不再提供支持。

这意味着你有大约一年半的时间完成迁移。

迁移方向如下：

公有云用户

直接使用：

Service Type=LoadBalancer

即可。

裸金属用户

推荐部署：

MetalLB

替代 ExternalIPs。

入口流量

推荐逐步向：

Gateway API

迁移。

写在最后

ExternalIPs 诞生于 Kubernetes 的早期阶段。

在那个云原生生态尚未成熟的年代，它解决了很多实际问题。

但随着：

• 网络模型演进
• 权限体系完善
• 多租户需求增加
• Gateway API 发展成熟

ExternalIPs 的设计缺陷也逐渐暴露出来。

从 Kubernetes 社区的决策可以看到一个明显趋势：

未来的 Kubernetes 不再鼓励“简单但危险”的能力，而是更强调标准化、安全性和可治理性。

对于运维人员来说，现在正是检查集群中是否仍然存在 ExternalIPs 配置，并制定迁移计划的最佳时机。