NGINX Ingress Controller 2.0版：需要了解的信息

NGINX | 2021年12月27日

10月，我们发布了F5 NGINX Ingress Controller 2.0版（nginxinc/kubernetes-ingress），新增了对Kubernetes 1.22和Ingress API版本1（networking.k8s.io/v1）的支持。您可能会想：这有什么意义？

这个“那又怎样”的问题并非三言两语就能说清。我们将通过回答以下3个相互关联的问题来作答：

为什么Kubernetes版本发布如此重要？
什么是Ingress API？为什么升级到networking.k8s.io/v1很重要？
NGINX Ingress Controller 2.0对现有客户有何影响？

继续阅读以了解答案，并于2022年1月11日收看“Kubernetes版本来袭时的应对方案”。

为什么Kubernetes版本发布如此重要？

这个问题的答案看似简单，实则复杂。Kubernetes的兼容性管理颇具挑战，因为Kubernetes运维人员必须管理三类版本：

Kubernetes平台本身：每次发布新版本时，Kubernetes团队都会停止维护一个较旧版本。继续使用此类版本会给风险管理策略带来问题，也会增加故障排除的难度，因为无法再获得Kubernetes团队的帮助。目前，Kubernetes项目维护最近3个次要版本（1.20、1.21和1.22）的发布分支。Kubernetes 1.19及更高版本可获得约1年的补丁支持，而1.18及更低版本获得的补丁支持约为9个月。（1.18及更低版本的支持期较短，是因为Kubernetes过去每年发布4次，而目前每年发布3次。）
Kubernetes API：每次发布Kubernetes新版本时，都会推出新的API并弃用过时的API，而API变更会影响相应的资源和工具。升级Kubernetes平台时，可能还需要升级API。
在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（又称Ingress API v1）随Kubernetes 1.19引入。当时，Kubernetes同时支持v1beta1和v1，并会自动将其中一个版本呈现为另一个版本。这种API版本的底层兼容机制有助于简化运维，但可能会妨碍规划工作。

随着Kubernetes 1.22发布，v1成为Ingress API的唯一版本。这一点非常重要，因为Ingress API v1成为唯一版本后，所有Beta版本（extensions/v1beta1和networking.k8s.io/v1beta1）均被弃用。对于尚未采用Ingress API v1的组织而言，这会造成影响，但NGINX认为这一变化是积极信号。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 的一段（不算简短的）历史

自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在KubeCon EU 2016上首次公开亮相。观看录像：第1天：使用NGINX为Kubernetes创建高级负载均衡解决方案；KubeCon EU 2016。

2017（v1.0.0）

该项目已达到生产就绪状态，其中基于NGINX Plus的版本提供了对JSON Web令牌（JWT）的关键支持。

在NGINX Conf 2017上，Michael Pleshakov在《使用NGINX Plus作为Ingress Controller为Kubernetes上的应用提供负载均衡》中演示了包括高级负载均衡在内的生产环境功能。

2018

NGINX Ingress Controller在可见性、易用性和灵活性方面实现了显著增强：

5月（v1.2.0）：该项目采用新的NGINX Plus API，nginx-ingress镜像迁移至官方NGINX Docker Hub。此版本首次支持gRPC、被动健康检查、Helm图表和Prometheus。
8月（v1.3.0）：NGINX Plus客户现在可以将指标导出到Prometheus，并利用主动健康检查；所有用户都能受益于Helm图表和可合并Ingress资源的改进，以及更便捷的自定义模板管理（请参阅《NGINX Ingress Controller for Kubernetes 1.3.0版发布公告》）。
11月（v1.4.0），新增TCP/UDP支持，可实现第4层流量管理。其他功能包括简化自定义注解的开发，并支持“二选一随机”负载均衡算法（请参阅《NGINX Ingress Controller for Kubernetes 1.4.0版发布公告》）。

在NGINX Conf 2018大会上，Michael Pleshakov登台发表演讲《使用NGINX作为Kubernetes Ingress Controller》，分享如何使用Helm部署NGINX Ingress Controller、配置HTTP和TCP/UDP负载均衡、使用Prometheus进行监控，以及排查问题。

2019

我们推出了标准Kubernetes Ingress资源的替代方案，让高级功能的实现更轻松、更可靠。

5月（v1.5.0）：引入VirtualServer和VirtualServerRoute（VS/VSR）资源，作为一种新的配置方法。VS/VSR是首批NGINX Ingress资源，提供原生、类型安全且采用缩进格式的配置方式，可简化Ingress负载均衡的实施（请参阅《NGINX Ingress Controller for Kubernetes 1.5.0版发布公告<.htmla>》）。
12月（v1.6.0），文档已发布至docs.nginx.com。VS/VSR资源新增了更丰富的负载均衡支持，并达到生产就绪状态。新增OpenTracing支持，以更好地满足监控和调试需求；同时支持以非root用户身份运行，以提升安全性（请参阅《NGINX Ingress Controller for Kubernetes 1.6.0版发布公告》）。

在《新一代NGINX Ingress Controller》中，Michael Pleshakov再次登上NGINX Conf 2019，演示VS/VSR在蓝绿部署和A/B测试等用例中的应用。

2020

除了对NGINX Ingress资源进行多项增强外，今年的重点是与生态系统工具和NGINX产品集成。

4月（v1.7.0），我们发布了NGINX Ingress Operator，为在OpenShift 4.x环境中部署NGINX Ingress Controller提供一种快速、简便且经过认证的方式。NGINX Ingress资源持续扩展，新增了对更多协议和断路器的支持，并改进了验证和报告功能（请参阅《NGINX Ingress Controller for Kubernetes 1.7.0版发布公告》）。
7月（v1.8.0）：通过集成F5 NGINX App Protect WAF，客户可以在与Ingress控制器相同的容器中部署轻量、灵活的WAF。此外，还支持通过代码片段或自定义模板定制NGINX Ingress资源，并提供URI重写和访问控制列表等功能，实现更精细的控制（请参阅《NGINX Ingress Controller for Kubernetes 1.8.0版发布公告》）。
10月（v1.9.0）：通过与F5 NGINX Service Mesh集成，可在同一配置中管理南北向和东西向流量。新增Grafana仪表板，可轻松直观呈现历史数据（请参阅NGINX Ingress Controller 1.9.0版发布公告）。

在《使用NGINX和OpenShift保护生产环境应用》中，技术营销工程师Amir Rawdat演示了如何使用NGINX Ingress Operator、利用基于角色的访问控制（RBAC）实现跨职能配置、使用NGINX App Protect保护容器化应用，以及使用JWT验证客户端。

2021

安全是主要主题之一，同时还将实现更多生态系统集成。

2月（v1.10.0）：主要新增了OpenID Connect（OIDC）身份验证，可轻松使用JWT身份验证来提供可靠的单点登录（SSO）选项（请参阅《使用OpenID Connect和NGINX Ingress Controller轻松实现可靠的单点登录》）。
3月（v1.11.0），WAF和负载均衡策略得到重大增强，进一步提升了功能和灵活性，包括运行状况检查和状态报告（请参阅《使用NGINX Ingress Controller增强TCP/UDP负载均衡和WAF配置》）。
7月（v1.12.0）：此版本的亮点主要在于简化部署。除了可通过AWS Container Marketplace购买外，还可以从F5 Container Registry拉取预构建镜像（请参阅《NGINX现已在AWS Marketplace for Containers中上线》）。
10月（v2.0.3）。虽然此版本在功能方面并非重大里程碑，但它标志着与Kubernetes API互操作以及Ingress对象演进的重要进展。这项变更意味着NGINX Ingress Controller 2.0及更高版本与Kubernetes 1.19及更高版本兼容。此外，在Kubernetes 1.22及更高版本中，只能部署NGINX Ingress Controller 2.0及更高版本。

在NGINX Sprint 2.0会议演讲中，软件工程师Aidan Carson以“利用端到端加密掌控微服务”为主题，演示了如何使用NGINX Ingress Controller保护边缘、使用NGINX Service Mesh在服务之间设置安全访问控制，以及如何结合使用这两款产品，通过mTLS保护出站流量。