Kubernetes Service ExternalIPs 将被弃用：运维为什么要尽快排查
Kubernetes 1.36 宣布 Service ExternalIPs 的弃用和移除方向，本文解释它的安全风险、排查方法和替代方案。
Kubernetes 1.36 的一条重要安全消息是：Service 的 .spec.externalIPs 字段进入弃用和移除路径。这个字段很早就存在，很多老集群或非云环境可能还在用。
从运维角度看，它不是一个“可有可无的小字段”，而是一个需要认真排查的集群安全点。
ExternalIPs 是什么
Service 的 .spec.externalIPs 可以让 Service 通过指定的外部 IP 暴露访问入口。它看起来像是一个简单的负载均衡替代方案：
apiVersion: v1
kind: Service
metadata:
name: demo
spec:
externalIPs:
- 192.168.1.100
ports:
- port: 80
targetPort: 8080在一些裸金属集群、实验环境或早期迁移环境里，这种配置可能被用来快速暴露服务。
问题在于，它默认假设集群用户是可信的。
为什么它有安全风险
如果集群里存在多租户、多个团队共享 namespace、或者某些账号可以创建 Service，就可能出现流量劫持风险。
简单说，攻击者可以创建一个 Service，把 externalIPs 指向某个本不属于它的 IP，从而影响原本应该流向其他服务的流量。这类问题和 CVE-2020-8554 相关，Kubernetes 社区早就建议禁用。
这也是为什么 Kubernetes 后续提供了 DenyServiceExternalIPs admission controller。
先排查集群是否正在使用
可以用下面的命令检查所有 namespace：
kubectl get svc -A -o jsonpath='{range .items[?(@.spec.externalIPs)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.externalIPs}{"\n"}{end}'如果输出为空，说明当前没有 Service 使用 ExternalIPs。
如果有输出，要继续确认：
- 这个 Service 属于哪个业务？
- 这个 IP 是否真的归该业务使用？
- 是否有替代方案？
- 谁有权限创建或修改 Service？
检查谁能创建 Service
很多安全问题不是字段本身，而是权限太宽。可以检查 RBAC：
kubectl auth can-i create service --as system:serviceaccount:demo:app -n demo
kubectl auth can-i update service --as system:serviceaccount:demo:app -n demo也可以整体查看绑定：
kubectl get rolebinding,clusterrolebinding -A如果普通业务账号能随意创建或修改 Service，就要重新设计权限边界。
推荐替代方案
云环境：优先使用 LoadBalancer
在公有云或私有云集成环境中，优先使用：
spec:
type: LoadBalancer由云厂商负载均衡控制器负责分配和管理入口。
裸金属：使用 MetalLB 或类似方案
裸金属集群可以考虑 MetalLB、BGP 方案或企业内部负载均衡系统。它们的优势是有明确的 IP 地址池管理和控制器逻辑，而不是让任何 Service 直接声明外部 IP。
HTTP/HTTPS：使用 Gateway API 或 Ingress
如果只是 Web 流量，建议使用 Gateway API 或仍在维护的 Ingress Controller，而不是 ExternalIPs。
需要注意：Ingress NGINX 已经在 Kubernetes 官方公告中进入退休状态。现有集群可以继续运行，但长期应评估迁移到仍维护的网关方案。
如果短期不能替换怎么办
可以先做三件事：
- 启用
DenyServiceExternalIPs。 - 收紧能创建和修改 Service 的 RBAC。
- 对现有 ExternalIPs 建立白名单和变更审批。
在安全加固中，先阻止新增风险，再逐步迁移旧配置，是比较现实的策略。
学习者应该掌握什么
这类问题很适合作为 Kubernetes 安全学习案例。它能帮你理解：
- Service 不只是“暴露端口”的对象。
- 网络配置和 RBAC 权限强相关。
- 旧功能可能因为历史兼容而存在，但不适合继续默认使用。
- 安全加固要结合 admission、RBAC、网络和审计。
总结
Service ExternalIPs 的弃用不是单纯 API 清理，而是 Kubernetes 对“不安全默认行为”的持续修正。
如果你负责集群运维，建议把 ExternalIPs 排查加入升级检查清单。没有使用最好；如果正在使用，就要尽快规划替代方案。