10 月份，我们推出了 F5 NGINX Ingress Controller 2.0 版（nginxinc/kubernetes-ingress），增加了对 Kubernetes 1.22 和 Ingress API V1（networking.k8s.io/v1）的支持。您可能会想，那又怎样呢？
“那又怎样”是一个很微妙的问题，我们可以从三个相互关联的问题中一探究竟：
- 为什么 Kubernetes 的发布事关重大？
- 什么是 Ingress API，为什么升级到
networking.k8s.io/v1至关重要？ - NGINX Ingress Controller 2.0 对当前客户有何影响？
请继续阅读本文寻找答案，敬请关注将于 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 从发布之初至今的演变过程。
2016 年（v0.5.0）
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 大会。
2017 年（v1.0.0）
该项目已完成生产准备，其中 NGINX Plus 版本增加了对 JSON Web Token (JWT) 的关键支持。
在 2017 年 NGINX Conf 大会上，Michael Pleshakov 展示了生产级功能，包括高级负载均衡功能，即在Kubernetes 上将 NGINX Plus 用作负责应用负载均衡的 Ingress Controller。
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 资源和更易于管理的自定义模板中受益（请参阅 “隆重推出面向 Kubernetes 1.3.0 版本的 NGINX Ingress Controller”）。
- 11 月（v1.4.0） —— 添加了 TCP/UDP 支持，让四层流量管理成为了可能。其他功能还包括更轻松地开发自定义注释和支持 Random with Two Choices 负载均衡算法等（请参阅 “隆重推出面向 Kubernetes 1.4.0 版本的 NGINX Ingress Controller”）。
在 2018 年 NGINX Cenf 大会上，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 负载均衡的实现（请参阅 “隆重推出面向 Kubernetes 1.5.0 版本的 NGINX Ingress Controller”）。
- 12 月（v1.6.0） —— 在 docs.nginx.com 上创建文文档。。VS/VSR 资源增加了更丰富的负载均衡支持，并已做好生产准备。添加了 OpenTracing 支持，以更有效地监控和调试用例，并添加了作为非
root用户身份运行的功能，以提高安全性（请参阅 “隆重推出面向 Kubernetes 1.6.0 版本的 NGINX Ingress Controller”）。
在《下一代 NGINX Ingress Controller》中，Michael Pleshakov 再次现身 2019 年 NGINX Conf 大会，演示了 VS/VSR 的用例，包括蓝绿部署和 A/B 测试。
2020 年
除了 NGINX Ingress 资源的众多增强功能之外，今年的主题是与生态系统工具和 NGINX 产品相集成。
- 4 月（v1.7.0） —— 我们发布了 NGINX Ingress Operator，以帮助用户快速、轻松地在 OpenShift 4.x 环境中部署经过认证的 NGINX Ingress Controller。NGINX Ingress 资源继续增长，并支持其他协议、断路器及改进的验证和报告功能（请参阅 “隆重推出面向 Kubernetes 1.7.0 版本的 NGINX Ingress Controller”）。
- 7 月（v1.8.0） —— 与 F5 NGINX App Protect WAF 相集成，允许客户在与 Ingress Controller 相同的容器中部署灵活的轻量级 WAF。添加了通过代码段或自定义模板来自定义 NGINX Ingress 资源的功能，另外 URI 重写和访问控制列表等功能提供了更细粒度的控制（请参阅 “隆重推出面向 Kubernetes 1.8.0 版本的 NGINX Ingress Controller”）。
- 10 月（v1.9.0） —— 与 F5 NGINX Service Mesh 相集成，允许在相同的配置下管理南北向和东西向流量。添加了 Grafana 仪表盘，以轻松实现历史数据的可视化（请参阅 “Announcing NGINX Ingress Controller Release 1.9.0”）。
在 《借助 NGINX 和 OpenShift 保护生产应用》中，技术营销工程师 Amir Rawdat 演示了如何使用 NGINX Ingress Operator、利用 RBAC 进行跨功能配置、借助 NGINX App Protect 保护容器化应用以及及借助 JWT 验证客户端。
2021 年
安全防护是主旋律，并且越来越多关于生态融合的进展：
- 2 月（v1.10.0） —— 主要添加了 OpenID Connect (OIDC) 验证，使得用 JWT 验证以提供可靠的单点登录选项变得容易（请参阅 “使用 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 Container Marketplace 上购买”）。
- 10 月（v2.0.3） —— 虽然在功能上算不上是个里程碑，但是这个版本是与 Kubernetes API 的互操作性以及 Ingress 对象的演进的里程碑。这个变化意味着 NGINX Ingress Controller 2.0（以及之后的版本）是与 Kubernetes 1.19 及更高版本相兼容的。NGINX Ingress Controller 2.0 也是你在 Kubernetes 1.22 及更高版本中可以部署的唯一一个版本。
在 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。