宣布推出 NGINX Gateway Fabric 1.2.0 版

我们很高兴与大家分享有关 NGINX Gateway Fabric 的最新消息，它是我们对 Kubernetes Gateway API 的一致实现。我们最近将其更新至 1.2.0 版，其中包含多项令人兴奋的新功能和改进。 此版本专注于增强平台的功能并确保其满足用户的需求。 我们已包含 F5 NGINX Plus 支持并扩展了我们的 API 范围以涵盖最需要的用例。 我们相信这些增强功能将为所有用户创造更好的体验，并帮助他们更有效地实现目标。

图 1： NGINX Gateway Fabric 的设计和架构概述

NGINX Gateway Fabric 1.2.0 概览：

• NGINX Plus 支持- NGINX Gateway Fabric 现在支持数据平面的 NGINX Plus，可提供更高的可用性、详细的指标和实时可观察性仪表板。
• BackendTLSPolicy – TLS 验证允许 NGINX Gateway Fabric 确认后端应用的身份，防止恶意应用劫持连接。 此外，TLS 加密集群内的流量，确保客户端和后端应用之间的安全通信。
• URLRewrite - NGINX Gateway Fabric 现在支持 Route 对象中的 URL 重写。 利用此功能，您可以轻松修改原始请求URL并将其重定向到更合适的目的地。 这样，当您的后端应用发生 API 变化时，您可以保持向客户端公开的 API 保持一致。
• 产品遥测——借助 NGINX Gateway Fabric 中现有的产品遥测，我们可以通过了解您在环境中如何使用产品来帮助进一步提高基础设施的运营效率。 此外，我们计划在会议期间定期与社区分享这些见解。

我们将在下面深入了解这些新功能。

NGINX Gateway Fabric 1.2.0 有哪些新功能？

NGINX Plus 支持

NGINX Gateway Fabric 1.2.0 版本已发布，支持 NGINX Plus，为用户带来许多新好处。 通过新的升级，用户现在可以在其部署中利用 NGINX Plus 的高级功能，包括额外的 Prometheus 指标、动态上游重新加载和 NGINX Plus 仪表板。 此次升级还允许您选择直接从 NGINX 获取对您环境的支持。

其他 Prometheus 指标

在使用 NGINX Plus 作为数据平面时，其他高级指标将与您通常使用 NGINX 开源获得的指标一起导出。 一些亮点包括有关 http 请求、流、连接等的指标。 有关完整列表，您可以查看 NGINX 的 Prometheus 导出器以获得方便的列表，但请注意，导出器不是 NGINX Gateway Fabric 严格要求的。 通过安装任何 Prometheus 或与 Prometheus 兼容的抓取工具，您可以将这些指标抓取到可观察性堆栈中，并使用架构中的一个一致的层构建仪表板和警报。 Prometheus 指标可通过 HTTP 端口 9113 自动在 NGINX Gateway Fabric 中获取。 您还可以通过更新 Pod 模板来更改默认端口。 如果您正在寻找简单的设置，您可以访问我们的GitHub 页面，获取有关如何部署和配置 Prometheus 以开始收集的更多信息。 或者，如果您只是想查看指标并跳过设置，则可以使用 NGINX Plus 仪表板，如下一节所述。 在集群中安装 Prometheus 后，您可以通过在后台运行端口转发来访问其仪表板。kubectl -n surveillance port-forward svc/prometheus-server 9090:80

图 2： Prometheus 图表显示 NGINX Gateway Fabric 连接已接受

即使您使用默认的 NGINX Open Source 作为数据平面，上述设置也能正常工作！ 但是，您将看不到 NGINX Plus 提供的任何附加指标。 随着集群规模和范围的增长，我们建议了解 NGINX Plus 指标如何帮助您快速解决容量规划问题、事件甚至后端应用故障。

动态上游重新加载

动态上游重新加载（与 NGINX Plus 一起安装时由 NGINX Gateway Fabric 自动启用）允许 NGINX Gateway Fabric 无需重新加载即可更新 NGINX 配置。 传统上，当 NGINX 重新加载时，现有连接由旧的工作进程处理，而新配置的工作进程处理新的连接。 当所有旧连接都完成后，旧工作程序将停止，NGINX 仅使用新配置的工作程序继续运行。 通过这种方式，即使在 NGINX 开源中也可以优雅地处理配置更改。 然而，当 NGINX 处于高负载状态时，同时维护新旧工作进程可能会产生资源开销，从而导致问题，尤其是在尝试尽可能精简地运行 NGINX Gateway Fabric 时。 NGINX Plus 中的动态上游重新加载功能通过提供配置更改的 API 端点来绕过此问题，NGINX Gateway Fabric 将自动使用（如果存在），从而减少了在重新加载过程中处理新旧工作者所需的额外资源开销。 当您开始更频繁地对 NGINX Gateway Fabric 进行更改时，重新加载也会更频繁地发生。 如果您好奇当前安装的 NGF 中重新加载的频率或时间，您可以查看 Prometheus 指标nginx_gateway_fabric_nginx_reloads_total 。 要全面深入地了解该问题，请查看 Nick Shadrin 的文章！ 以下是 Prometheus 仪表板中两个 NGINX Gateway Fabric 部署环境中的指标示例：

图 3： Prometheus 图表显示 NGINX Gateway Fabric 重新加载总数

NGINX Plus 仪表板

如前所述，如果您正在寻找一种无需安装 Prometheus 或可观察性堆栈即可快速查看 NGINX Plus 指标的方法，NGINX Plus 仪表板可让您实时监控性能指标，您可以使用它来排除故障并关注资源容量。 仪表板为您提供 NGINX Plus 提供的所有指标的不同视图，并且可通过内部端口轻松访问。 如果您想快速了解仪表板功能，请访问我们的仪表板演示网站demo.nginx.com 。 要访问 NGINX Gateway Fabric 安装上的 NGINX Plus 仪表板，您可以通过端口转发将连接转发到本地计算机上的端口 8765： kubectl port-forward -n nginx-gateway 8765:8765接下来，打开您喜欢的浏览器并在地址栏中输入 http://localhost:8765/dashboard.html。

图4： NGINX Plus 仪表板概述

后端 TLS 策略

此版本现在附带了期待已久的BackendTLSPolicy支持。 BackendTLSPolicy 在 NGINX Gateway Fabric 和应用之间引入了加密的 TLS 通信，大大增强了通信通道的安全性。 下面是一个示例，展示了如何在根据受信任的证书颁发机构 (CA) 验证服务器证书时通过指定 TLS 密码和协议等设置来应用策略。 BackendTLSPolicy 使用户能够保护 NGF 和后端之间的流量。 您还可以设置最低 TLS 版本和密码套件。 这可以防止恶意应用劫持连接并加密集群内的流量。 要配置后端 TLS 终止，首先创建一个包含要使用的 CA 认证的ConfigMap 。 如需管理内部 Kubernetes 证书的帮助，请查看本指南。

种类： ConfigMap
apiVersion：v1
元数据：
名称：backend-cert
数据：
ca.crt：
<-----证书开始-----
-----证书结束-----
>

接下来，我们创建 BackendTLSPolicy，它针对我们的安全应用服务并引用上一步中创建的 ConfigMap：

api版本：gateway.networking.k8s.io/v1alpha2
种类： BackendTLSPolicy
元数据：
名称：backend-tls
规范：
目标引用：
组：''
种类： 服务
名称：secure-app
命名空间：default
tls：
caCertRefs：
- 名称：backend-cert
组：''
种类： ConfigMap
主机名：secure-app.example.com

URL重写

使用 URLRewrite 过滤器，您可以修改传入请求的原始 URL，并将其重定向到其他 URL，而且对性能没有任何影响。 当您的后端应用更改其公开的 API，但您希望保持现有客户端的向后兼容性时，这特别有用。 您还可以使用此功能向客户端公开一致的 API URL，同时将请求重定向到具有不同 API URL 的不同应用，从而提供结合了几种不同 API 功能的“体验”API，为您的客户端提供便利和性能。 首先，让我们为 NGINX 网关结构创建一个网关。 这将使我们能够定义 HTTP 侦听器并配置端口 80 以获得最佳性能。

api版本：gateway.networking.k8s.io/v1
种类： 网关
元数据：
名称：cafe
规范：
网关类名：nginx
监听器：
- 名称：http
端口： 80
协议： HTTP

让我们创建一个 HTTPRoute 资源并配置请求过滤器以将任何对 /coffee 的请求重写为 /beans。 我们还可以提供一个 /latte 端点，该端点被重写以包含后端要处理的 /latte 前缀（“/latte/126”变为“/126”）。

api版本：gateway.networking.k8s.io/v1
种类： HTTPRoute
元数据：
名称：咖啡
规范：
父引用：
- 名称：咖啡馆
节名称：http
主机名：
-“cafe.example.com”
规则：
- 匹配：
- 路径：
类型： PathPrefix
值：/coffee
过滤器：
- 类型： URLRewrite
urlRewrite:
路径：
类型： ReplaceFullPath
replaceFullPath: /beans
backendRefs:
- 名称：coffee
端口： 80
- 匹配项：
- 路径：
类型： PathPrefix
值：/latte
过滤器：
- 类型： URLRewrite
urlRewrite:
路径：
类型： ReplacePrefixMatch
replacePrefixMatch：/
backendRefs：
- 名称：咖啡
端口： 80

HTTP 重写功能有助于确保客户端端点之间的灵活性以及它们与后端的映射方式。 它还允许将流量从一个 URL 重定向到另一个 URL，这在将内容迁移到新网站或 API 流量时特别有用。 尽管 NGINX Gateway Fabric 支持基于路径的重写，但它目前不支持基于路径的重定向。 请告知我们这是您的环境所需要的功能。

产品遥测

我们决定将产品遥测作为一种被动收集反馈的机制纳入 1.2 版本中。 此功能将从您的环境中收集各种指标，并每 24 小时将其发送到我们的数据收集平台。 不会收集任何 PII，您可以在此处查看所收集内容的完整列表。 我们致力于提供完全透明的遥测功能。 虽然我们会记录我们收集的每个字段，并且您可以通过我们的代码验证我们收集的内容，但您始终可以选择完全禁用它。 我们计划根据在社区会议上与社区收集的统计数据，定期审查有趣的观察结果，所以请务必参加！

资源

有关 NGINX Gateway Fabric 1.2.0 的完整更新日志，请参阅发行说明。 要尝试使用 NGINX Gateway Fabric for Kubernetes 和 NGINX Plus，请立即开始30 天免费试用或联系我们讨论您的用例。 如果您想参与其中，了解接下来的内容，或查看 NGINX Gateway Fabric 的源代码，请查看我们在GitHub上的存储库！ 我们每两周的星期一举行一次社区会议，时间为太平洋时间上午 9 点/格林威治标准时间下午 5 点。 会议链接、更新、议程和笔记均位于NGINX Gateway Fabric 会议日历中。 我们的 GitHub readme 中也始终提供链接。