F5 NGINX Ingress Controller 5.3.0 的发布赶上了一个很现实的时间点：Kubernetes 社区已经宣布，社区维护的 ingress-nginx 项目将在 2026 年 3 月停用。对很多集群来说，Ingress 不是边缘组件，而是生产流量进入服务的第一道门。现在需要做的不是临时换个镜像，而是重新盘点 ingress 策略、控制器能力、迁移风险和运维边界。
这次发布为什么值得关注
5.3.0 本身是一条版本线，但它背后的问题更大：大量团队长期把 ingress-nginx 当作 Kubernetes 默认答案。它熟悉、文档多、示例多，也被许多 Helm chart 和平台模板默认引用。一旦社区维护进入停用倒计时，风险会逐步转移到使用方：安全修复、兼容性、升级路径、生产事故响应，都需要重新评估。
F5 NGINX Ingress Controller 的吸引力在于它仍然围绕 NGINX 这个开发者熟悉的代理栈展开。对于已经使用 NGINX 配置模型、熟悉 Ingress 资源、希望保留开源选择的团队，它比彻底换到另一套网关模型更容易进入评估清单。
需要注意的是，版本号本身不等于迁移完成。控制器行为、注解兼容性、TLS 处理、负载均衡策略、日志格式、Prometheus 指标、WAF 或高级流量策略，都会影响真实工作量。
从“能跑”到“可运营”的评估维度
迁移 ingress 控制器时，最容易低估的是注解和默认行为。Ingress API 是标准的，但控制器注解不是。一个集群里常见的这些配置都可能绑定在 ingress-nginx 的实现上：
- 请求体大小限制
- 连接和读取超时
- rewrite 规则
- upstream keepalive
- TLS redirect
- canary 或灰度路由
- 真实客户端 IP 透传
- 自定义 NGINX snippet
因此评估 F5 NGINX Ingress Controller 5.3.0 时，建议把现有 Ingress 当作“配置资产”而不是普通 YAML。先扫描、归类，再决定哪些可以等价迁移，哪些需要改成新的资源或控制器支持的配置方式。
可以这样实践：先列出集群里所有 Ingress 及其注解，找出对 ingress-nginx 的直接依赖。
kubectl get ingress --all-namespaces -o json \
| jq -r '.items[] | [
.metadata.namespace,
.metadata.name,
((.metadata.annotations // {}) | keys | join(","))
] | @tsv'
如果你只想看 ingress-nginx 相关注解，可以运行：
kubectl get ingress --all-namespaces -o json \
| jq -r '.items[] |
select((.metadata.annotations // {}) | keys[]? | startswith("nginx.ingress.kubernetes.io/")) |
"\(.metadata.namespace)/\(.metadata.name)"'
这一步很朴素，但很关键。它能把“我们应该没用什么特殊能力”变成可检查的清单。
一个可改造的最小 Ingress 示例
下面是一个最小示例，用来说明迁移评估时应把 ingressClassName 明确写出来。不同控制器的 class 名称需要按实际安装方式调整；这里假设目标控制器使用 nginx 作为 IngressClass 名称。
运行前需要修改：
host改成你的测试域名service.name改成你的服务名service.port.number改成服务端口ingressClassName改成实际安装的 F5 NGINX Ingress Controller 对应 class
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: demo-web
namespace: default
spec:
ingressClassName: nginx
rules:
- host: demo.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: demo-web
port:
number: 80
应用到测试环境：
kubectl apply -f demo-ingress.yaml
kubectl describe ingress demo-web -n default
kubectl get ingressclass
验证请求路径时，不要只看 kubectl get ingress 是否出现地址。还应该直接向入口地址发请求，确认 Host、TLS、重定向和后端服务行为符合预期。
curl -i -H 'Host: demo.example.com' http://INGRESS_ADDRESS/
把 INGRESS_ADDRESS 替换为负载均衡器地址、节点地址或本地测试入口。
迁移时不要跳过并行验证
生产集群里直接替换默认 IngressClass 风险很高。更稳妥的做法是让新旧控制器短期并行，用不同的 ingressClassName 承接不同测试对象。这样可以逐个服务验证，而不是把所有路由一次性切过去。
可以这样实践：为新控制器保留单独 class，然后只迁移一个低风险服务。
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: f5-nginx
spec:
controller: nginx.org/ingress-controller
随后业务 Ingress 使用：
spec:
ingressClassName: f5-nginx
这里的 spec.controller 需要以你实际安装文档和控制器参数为准。示例表达的是迁移方法：通过 IngressClass 隔离流量入口，而不是修改所有现有资源。
在并行阶段，建议至少记录这些结果：
- 每个服务是否依赖 ingress-nginx 专属注解
- HTTP 到 HTTPS 的跳转是否一致
- 大请求、长连接、WebSocket 是否正常
- 真实客户端 IP 是否被应用正确读取
- 访问日志字段是否满足排障需求
- Prometheus 指标名称和告警规则是否需要调整
- 回滚时 DNS、负载均衡器和 IngressClass 如何恢复
采用建议：把 2026 年 3 月当作工程截止线
ingress-nginx 停用不是某一天突然发生的事故，而是一个明确的维护边界。越早开始，越容易用小批量服务验证；越晚开始，越容易在安全升级、平台改造和业务发布之间抢窗口。
对 F5 NGINX Ingress Controller 5.3.0 的评估可以从三件事开始：
- 扫描现有 Ingress 和注解，建立迁移清单。
- 在非生产集群安装并配置独立 IngressClass，跑真实业务样例。
- 对比日志、指标、TLS、重写、超时和回滚流程，而不是只验证 200 OK。
如果你的团队已经围绕 NGINX 建立了排障经验和配置习惯，F5 NGINX Ingress Controller 是一个值得认真验证的候选项。但它仍然需要一次工程化迁移：把隐含行为显式化，把专属注解清点出来，把入口流量切换做成可回滚的步骤。这样到社区 ingress-nginx 停用时，你面对的是计划内变更，而不是被动救火。