博客 | NGINX

NGINX Ingress 控制器版本 2.0： 你需要知道什么

NGINX-F5-horiz-black-type-RGB 的一部分
Brian Ehlert 缩略图
布莱恩·埃勒特
2021 年 12 月 27 日发布

10 月份，我们推出了 F5 NGINX Ingress Controller 2.0 版( nginxinc/kubernetes-ingress ) ，增加了对Kubernetes 1.22和Ingress API 1.0 版 ( networking.k8s.io/v1 ) 的支持。 你可能会想——那又怎么样？

这个“那又怎样”的问题很微妙，我们将通过回答三个相互关联的问题来回答它：

请继续阅读以找到答案，并关注2022 年 1 月 11 日Kubernetes 版本攻击时的作战计划。

为什么 Kubernetes 的发布如此重要？

这个问题的答案很简单，但也很复杂。 Kubernetes 的兼容性管理具有挑战性，因为 Kubernetes 操作员必须管理三类版本：

  1. Kubernetes 平台本身——每次发布新版本时，Kubernetes 团队都会停止维护旧版本。 继续使用这样的版本会对您的风险管理策略产生问题，并且会使故障排除变得更加困难，因为不再能获得 Kubernetes 团队的帮助。 目前，Kubernetes 项目维护最近三个次要版本（1.20、1.21 和 1.22）的发布分支。 Kubernetes 1.19 及更高版本获得大约 1 年的补丁支持，而 1.18 及更早版本获得大约 9 个月的补丁支持。 （1.18 及更早版本的时间跨度较短是因为 Kubernetes 过去每年发布四次，而不是现在的三次）。

  2. Kubernetes API – 每次 Kubernetes 发布时都会诞生新的 API，也会弃用旧的 API，API 的变化会影响相应的资源和工具。 当您升级 Kubernetes 平台时，您可能还必须升级 API。

  3. 您在 Kubernetes 中部署的工具– Kubernetes 或其 API 的重大更改可能会影响您的工具（例如 Ingress 控制器）和相应的资源是否继续正常运行。

因此，您需要跟踪三个时间线 - 一个用于 Kubernetes，一个用于 Ingress API，一个用于 NGINX Ingress Controller。 为了避免破坏 Kubernetes，您必须找到 Kubernetes 版本与 API 和 NGINX Ingress Controller 兼容的最佳点。 在没有检查兼容性的情况下升级这三个组件中的任何一个都可能产生严重的后果。 如果所有三个组件彼此不兼容……恭喜你，你的应用程序已经损坏了！

什么是 Ingress API 以及为什么networking.k8s.io/v1很重要？

Ingress API 使得 Ingress 控制器可以安全地公开您的 Kubernetes 应用程序。 networking.k8s.io/v1 API（又名 Kubernetes 1.19 中引入了 Ingress API v1。 当时，Kubernetes 同时支持v1beta1和v1 – 并自动将一个版本显示为另一个版本。 API 版本的这种“幕后”兼容性在操作上给您带来好处，但可能会阻碍您的规划工作。

随着 Kubernetes 1.22 的发布， v1成为 Ingress API 的唯一版本。这很重要，因为随着 Ingress API v1 成为“唯一”，所有测试版本（ extensions/v1beta1和networking.k8s.io/v1beta1 ）都将被弃用。 虽然这对尚未采用 Ingress API v1 的组织来说具有破坏性，但在 NGINX 我们认为这种变化是一个好兆头。 Ingress API 脱离测试版标志着其已发展成为一个成熟且完全实现的 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 的简史

自 2016 年首次发布以来，NGINX Ingress Controller 已经从一个新兴工具发展成为 Kubernetes 网络的强大工具。 让我们来回顾一下它从推出到现在的演变历程。

2016（ v0.5.0 ）

NGINX 工程师 Michael Pleshakov 在我们的 GitHub 仓库中发布了第一篇文章（ nginxinc/kubernetes-ingress ） ，使得可以使用 NGINX 和F5 NGINX Plus作为 Kubernetes Ingress 控制器（KIC）。

NGINX Ingress Controller 在2016 年欧洲 KubeCon上首次公开亮相。 查看录音： 第 1 天，使用 NGINX 为 Kubernetes 创建高级负载平衡解决方案； KubeCon EU 2016 。

2017 年（ v1.0.0 ）

该项目已达到生产就绪状态，包括基于 NGINX Plus版本对 JSON Web Tokens (JWT) 的关键支持。

在 2017 年 NGINX Conf 上，Michael Pleshakov 演示了生产功能，包括使用 NGINX Plus 作为 Kubernetes 上负载均衡applications的入口控制器中的高级负载均衡。

2018

NGINX Ingress Controller 在可见性、易用性和灵活性方面有了很大的改进：

在 2018 年 NGINX Conf 上，Michael Pleshakov 发表了题为《使用 NGINX 作为 Kubernetes 入口控制器》的演讲，分享了如何使用 Helm 部署 NGINX 入口控制器、配置 HTTP 和 TCP/UDP 负载均衡、使用 Prometheus 进行监控以及排除故障。

2019

我们推出了标准 Kubernetes Ingress 资源的替代方案，使执行高级功能变得更容易、更可靠。

在下一代 NGINX Ingress Controller中，Michael Pleshakov 重返 NGINX Conf 2019，演示 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 控制器是您的应用的正确选择，那么您可以在我们的GitHub 存储库中快速开始使用基于 NGINX 开源的 NGINX Ingress 控制器。

对于大规模生产部署，我们希望您尝试基于 NGINX Plus 的商业 NGINX Ingress Controller。 它可以免费试用 30 天，其中包括 NGINX App Protect。

阅读有关 F5 NGINX 的更多博客文章 ›

“这篇博文可能引用了不再可用和/或不再支持的产品。 有关 F5 NGINX 产品和解决方案的最新信息，请探索我们的NGINX 产品系列。 NGINX 现在是 F5 的一部分。 所有之前的 NGINX.com 链接都将重定向至 F5.com 上的类似 NGINX 内容。”