加载失败
ingress-nginx（NGINX 的 Kubernetes Ingress Controller）在 KubeCon 前后宣布退役，激起社区对迁移路径与生产影响的密集讨论。Kubernetes 社区已推动 Gateway API（一个由 SIGs 维护、用于取代传统 Ingress 的更现代路由规范，GA 已发布两年）作为长期方案，并且已有多种实现可选，例如 Nginx Gateway Fabric（NGINX 的 Gateway 实现，含迁移工具）、Envoy Gateway（基于 Envoy Proxy）、以及 Traefik/HAProxy 的 Gateway 控制器。问题的复杂性来自两方面：一是大量教程与生产部署长期依赖 ingress-nginx 的 nginx-specific 注解，迁移会牵涉配置重写与安全模型调整；二是开源维护的现实（单一维护者、商业收购后企业不接手、捐赠不足）使得项目退役成为更广泛的可持续性话题。许多留言因此既讨论技术替代方案，也在质疑退役节奏与谁应为关键基础设施承担长期维护责任。
Kubernetes 正在推动 Gateway API 作为替代 Ingress 的长期方案；Gateway API 已 GA 两年，支持更细粒度的 Route 类型和更严格的安全/多租户模型。评论中大量提到现有替代实现可直接采用或作为迁移路径，例如 Nginx 提供的 Nginx Gateway Fabric（带有从 Ingress 到 Gateway 的迁移工具）、Envoy Gateway、Traefik 与 HAProxy 的 Gateway 控制器。许多人建议可以并行运行旧的 Ingress 与新的 Gateway，逐步迁移，但同时提醒不同实现对旧有 nginx 注解(annotations) 的兼容性存在差异，需逐项验证高级配置。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
多条评论把 ingress-nginx 退役归因于维护者和资金问题：项目长期由少数人或单一维护者支撑，维护者离职后项目进入 best-effort 状态，且在 NGINX 被 F5 收购后企业并未接手长期维护。有人描述维护者未能有效培养社区贡献者、社区 PR 难以推进；也有声音批评大量使用该项目的公司既不捐款也不出力，导致开源不可持续。讨论还涉及社区是否会 fork 并继续做安全补丁，以及这种“单点维护”如何放大项目风险。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
很多用户担心迁移成本：生产环境里大量使用 ingress-nginx 的自定义注解（annotations）和教程示例，使得把配置逐项改写为 Gateway API 或其他控制器变得繁重。有人指出官方和维护者给出的退役时间窗口过短（评论中提到 6 个月被认为不够），在托管平台（如 EKS）上会触发大规模升级和测试工作。评论还具体提到替代方案对 nginx 注解的兼容性很有限、Envoy 的底层配置学习曲线陡峭，以及社区治理和提交权限问题可能影响安全补丁的及时性。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
讨论里存在两类对立看法：一部分评论强调 Kubernetes 带来的运维统一性、immutable 容器、以及为大型非软件公司（如零售与制造）提供可替换组件的好处，有人举例用 ArgoCD 管理集群级服务实现自动化更新。另一部分人认为 Kubernetes 被过度采用、维护成本高且频繁变动，呼吁更稳定的 LTS 风格编排器或更轻量的替代方案（如 k3s、Talos、Nomad、Docker Swarm、ECS）。讨论进一步具体化了替代方案的权衡，例如 Nomad 在生产级别通常还需 Consul/Vault 等配套组件，从而把复杂性以不同方式搬入系统中。
许多评论显现对运维复杂性的情绪化反应：有人怀念早期 sysadmin 的相对简单，有人主张 KISS 原则并倾向 LTS 式工程来减少频繁迁移的痛苦。现实操作经验也被反复提及——例如倾向使用 managed 平台、轻量发行版（k3s）或直接“销毁重建节点而不 SSH 排查”，以降低长期运维负担。这些情绪影响了社区对退役决定的接受度，很多人感到无奈并担忧频繁变动会削弱生产稳定性与团队士气。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
Gateway API: Kubernetes 社区提出的新一代网关/路由规范（由 SIGs 维护），用于替代传统 Ingress；GA 已发布两年，支持多种 Route 资源（HTTPRoute、TCPRoute、TLSRoute、GRPCRoute 等），旨在提供更细粒度的路由、安全和多租户控制。
Ingress（Kubernetes Ingress API）: Kubernetes 的旧版 HTTP(S) 转发 API，历史久且被大量教程引用，但已长时间标记为“frozen”；实际流量由不同的 Ingress controller（如 ingress-nginx）实现。
ingress-nginx: 指 NGINX Ingress Controller，是 Kubernetes 生态中最早和最广泛使用的 Ingress 实现之一；该项目长期由少数维护者支撑，近期宣布退役。
Nginx Gateway Fabric: NGINX 提供的基于 NGINX 的 Gateway API 实现，官方宣称包含将旧 Ingress 对象转换为 Gateway 的迁移工具，用于从 ingress-nginx 平滑过渡。
Envoy Gateway: 基于 Envoy Proxy（高性能边缘/服务代理）的 Gateway API 实现，支持多种路由类型；适合由程序化工具生成配置，但直接手写底层 Envoy 配置可读性差。
Traefik: 流行的反向代理与 Ingress/Gateway 控制器，支持 Gateway API，并对部分 nginx-specific annotations 提供兼容层，但兼容范围有限。
annotations: Kubernetes 对象的注解（annotations）用于附加控制器特定的键值配置；在 Ingress 场景中大量 nginx 专用注解成为迁移到其它控制器或 Gateway API 的主要痛点。
ArgoCD: 一种 GitOps 持续部署工具，用于自动将 Git 仓库中的声明式配置同步到 Kubernetes 集群，评论中有人用它来管理集群级服务（例如 Cilium、Traefik）。