原文作者：Brian Ehlert of F5, Jenn Gile of F5
原文链接：NGINX Ingress Controller 2.0 版：那些你不得不知道的事儿 - NGINX
转载来源：NGINX官方网站
（首次发布于2021.12.27）
10 月份，我们推出了 F5 NGINX Ingress Controller 2.0 版（nginxinc/kubernetes-ingress），增加了对 Kubernetes 1.22 和 Ingress API V1（networking.k8s.io/v1）的支持。您可能会想，那又怎样呢？
“那又怎样”是一个很微妙的问题，我们可以从三个相互关联的问题中一探究竟：
请继续阅读本文寻找答案，敬请关注将于 2022 年 1 月 11 日发布的 《Kubernetes 版本攻击应对计划》
为什么 Kubernetes 的发布事关重大？
这个问题的答案既简单又复杂。Kubernetes 的兼容性管理极具挑战性，原因是 Kubernetes 操作员必须管理三种版本：
-
The Kubernetes 平台本身 —— Kubernetes 团队每发布一个新的 Kubernetes 版本，就会停止维护上一个旧版本。对于您的风险管理策略而言，继续使用这样的老版本是个问题，并且由于 Kubernetes 团队不再提供支持，故障排除也将变得更加困难。目前，Kubernetes 项目正在维护的是三个最新子版本（1.20、1.21 和 1.22）分支。Kubernetes 1.19 及更高版本的补丁支持持续了 1 年左右，而 1.18 及更早版本的补丁支持为期 9 个月左右。（1.18 及更早版本的支持时间较短，是因为 Kubernetes 过去每年发布四次，而现在每年发布三次）。
-
Kubernetes API —— 每次 Kubernetes 发布时，都会有新的 API 诞生，而过时的 API 会被弃用，API 的变化将会影响相应的资源和工具。升级 Kubernetes 平台可能还需要升级 API。
-
部署在 Kubernetes 中的工具 —— Kubernetes 或其 API 的重大变更可能会影响您的工具（例如 Ingress Controller）以及相应资源的正常运行。
因此，您需要跟踪三个时间线：Kubernetes 时间线、Ingress API 时间线及 NGINX Ingress Controller 时间线。为了避免破坏 Kubernetes，您必须找到让 Kubernetes 版本与 API 和 NGINX Ingress Controller 兼容的最佳平衡点。如果不检查兼容性就升级其中任何一个组件，就会产生严重的后果。如果这三个组件不能相互兼容，那您就有麻烦了！
![]()
什么是 Ingress API，为什么 networking.k8s.io/v1 至关重要？
Ingress Controller 可通过 Ingress API 安全地暴露您的 Kubernetes 应用。Kubernetes 1.19 就已经引入了 networking.k8s.io/v1 API（又叫 Ingress API v1）。 那时候，Kubernetes 同时支持 v1beta1 和 v1，并会自动将两种版本呈现为同一个版本。虽然 API 版本的这种“幕后”兼容性为您带来了操作上的便利，但同时也会为您的工作计划带来阻碍。
随着 Kubernetes 1.22 的发布，Ingress API 就只有 v1 版了。这一点很重要，因为这种唯一性让所有 beta 版本（extensions/v1beta1 和 networking.k8s.io/v1beta1）都被淘汰了。虽然这对尚未采用 Ingress API v1 的企业造成了巨大冲击，但我们认为这种变化未尝不是一件好事。这标志着 Ingress API 正式从 beta 版发展为成熟且完全实现的 API。那么，为什么这种变化很重要？这又回到了版本管理的问题上。假设您将现有集群升级到 Kubernetes 1.22，但仍然使用与 v1beta1 Ingress 相关的资源，那么您的 Ingress 资源就麻烦了！
NGINX Ingress Controller 2.0 对当前客户有何影响？
由于 NGINX Ingress Controller 与 Ingress API 紧密耦合，v1 的发布对作为产品提供商的我们以及作为客户的您产生了重大影响，因此我们直接将 NGINX Ingress Controller 的版本号从 1.x 跳到了 2.x。我们重新构建了 NGINX Ingress Controller 2.0，使其能够利用 Ingress API v1 以及与 Kubernetes 1.22 完全兼容。
如果您使用 NGINX Ingress Controller，您需要立即根据版本采取相应的措施，以免破坏 Kubernetes、您的 Ingress 资源或 NGINX Ingress Controller：
Kubernetes 1.18 及更早版本：
-
确保您使用的是 NGINX Ingress Controller 1.12，以充分利用可用的功能集。（当您升级到 NGINX Ingress Controller 2.0 时，您还需要升级到 Kubernetes 1.19 或更高版本。）
-
制定一个计划，在未来几个月内迁移到更新的 Kubernetes（和 NGINX Ingress Controller）版本，因为一旦发布新的 Kubernetes 版本，Kubernetes 1.18 就不再受支持。
Kubernetes 1.19–1.21:
-
升级到 NGINX Ingress Controller 2.0。
-
如果您尚未将 Ingress 相关资源迁移到 networking.k8s.io/v1（请参阅 NGINX Ingress Controller 2.0 发行说明请立即制定计划。Kubernetes 1.19–1.21 支持当前的所有 Ingress API（包括 v1beta1 和 v1）版本，您可以随时进行转换。
-
如果您还没有转换，请立即将您的 Ingress 和 IngressClass 资源迁移到 networking.k8s.io/v1。
-
如果您在 Ingress 资源中正在使用已经弃用的 kubernetes.io/ingress.class 注释，我们建议您切换到 ingressClassName 字段。
-
请参考我们的文档与示例（与 networking.k8s.io/v1 和 Ingress 资源的 ingressClassName 字段一起提供）来制定更新计划。
Kubernetes 1.22:
- 确保您已运行 NGINX Ingress Controller 2.0，因为之前版本的 NGINX Ingress Controller 与 Kubernetes 1.22 不兼容并且不支持 Ingress API v1。
NGINX Ingress Controller 的发展史
NGINX Ingress Controller 于 2016 年首次发布，从一个稚嫩的工具发展至今已经成为了 Kubernetes 网络流量管理的强大工具。以下是 NGINX Ingress Controller 从发布之初至今的演变过程。
NGINX 工程师 Michael Pleshakov 在我们的 GitHub 仓库（nginxinc/kubernetes-ingress）中发布了第一个版本，使得将 NGINX 和 F5 NGINX Plus 用作 Kubernetes Ingress Controller (KIC) 成为可能。
NGINX Ingress Controller 在 2016 年欧盟 KubeCon 大会上首次亮相。查看视频记录：第 1 天，借助 NGINX 为 Kubernetes 创建高级负载均衡解决方案；2016 年欧盟 KubeCon 大会。
该项目已完成生产准备，其中 NGINX Plus 版本增加了对 JSON Web Token (JWT) 的关键支持。
在 2017 年 NGINX Conf 大会上，Michael Pleshakov 展示了生产级功能，包括高级负载均衡功能，即在Kubernetes 上将 NGINX Plus 用作负责应用负载均衡的 Ingress Controller。
2018 年
NGINX Ingress Controller 的可视化、易用性和灵活性大大增强：
在 2018 年 NGINX Cenf 大会上，Michael Pleshakov 展示了如何将 NGINX 用作 Kubernetes Ingress Controller，并分享了如何使用 Helm 部署 NGINX Ingress Controller、配置 HTTP 和 TCP/UDP 负载均衡、通过 Prometheus 监控及故障排除。
2019 年
我们首次推出了标准 Kubernetes Ingress 资源的替代方案，使高级功能的执行变得更容易、更可靠。
在《下一代 NGINX Ingress Controller》中，Michael Pleshakov 再次现身 2019 年 NGINX Conf 大会，演示了 VS/VSR 的用例，包括蓝绿部署和 A/B 测试。
2020 年
除了 NGINX Ingress 资源的众多增强功能之外，今年的主题是与生态系统工具和 NGINX 产品相集成。
在 《借助 NGINX 和 OpenShift 保护生产应用》中，技术营销工程师 Amir Rawdat 演示了如何使用 NGINX Ingress Operator、利用 RBAC 进行跨功能配置、借助 NGINX App Protect 保护容器化应用以及及借助 JWT 验证客户端。
2021 年
安全防护是主旋律，并且越来越多关于生态融合的进展：
在 NGINX Sprint 2.0 线上大会中，软件工程师 Aidan Carson 在他的演讲“掌握微服务的端到端加密”中演示了如何用 NGINX Ingress Controller 防护边缘节点、如何利用 NGINX Service Mesh 在服务间构建安全访问控制，以及如何利用二者及 mTLS 来保护出向流量。
下一步：试用 NGINX Ingress Controller
如果您认为开源 Ingress Controller 对您的应用来说是最好的选择，那么您可前往 GitHub 仓库，立即下载 NGINX 开源版 NGINX Ingress Controller。
如果是大型生产部署，您不妨试试基于 NGINX Plus 的商业版 NGINX Ingress Controller。它提供 30 天免费试用版，其中包括 NGINX App Protect。
更多资源
想要更及时全面地获取NGINX相关的技术干货、互动问答、系列课程、活动资源？
请前往NGINX开源社区：
