隆重宣布推出 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 现在支持在路由对象中重写 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 Exporter 的说明列表 — 但请注意，Exporter 并非 NGINX Gateway Fabric 所必需。

只要安装了 Prometheus 或兼容 Prometheus 的抓取工具，便可将这些指标抓取到可观测性堆栈，并使用单一且一致的架构层来构建仪表盘和警报。NGINX Gateway Fabric 通过 HTTP 端口 9113 自动提供 Prometheus 指标。您也可以通过更新 Pod 模板来更改默认端口。

如果您希望采用简单设置，请访问我们的 GitHub 页面，详细了解如何部署并配置 Prometheus 以开始收集指标。或者，若您只想查看指标而跳过设置，则可使用 NGINX Plus 仪表盘，这将在下一节中进行介绍。

在将 Prometheus 安装至集群后，可以通过在后台运行端口转发来访问其仪表盘。

kubectl -n monitoring port-forward svc/prometheus-server 9090:80

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

即便使用默认的 NGINX 开源版作为数据平面，上述设置也同样有效！不过，您将无法看到 NGINX Plus 提供的任何额外指标。鉴于集群规模和范围不断扩大，我们建议您了解 NGINX Plus 指标可如何帮助您快速解决容量规划问题、事件甚至后端应用故障。

动态上游重载

安装 NGINX Plus 时，NGINX Gateway Fabric 会自动启用动态上游重载功能。该功能允许 NGINX Gateway Fabric 在不重新加载 NGINX 的情况下，更新 NGINX 配置。

过去，当 NGINX 重新加载时，现有连接由旧的 worker 进程处理，而新连接则由新配置的 worker 进程处理。当处理完所有旧连接后，旧的 worker 进程就会停止，NGINX 只使用新配置的 worker 进程继续工作。通过这种方式，即使在 NGINX 开源版中，配置更改也能得到优雅地处理。

不过，当 NGINX 处于高负载状态时，同时维护新旧 worker 可能会产生资源开销，进而引发问题，尤其是在试图尽可能精简地运行 NGINX Gateway Fabric 时。NGINX Plus 的动态上游重载功能通过为配置更改提供一个 API 端点，NGINX Gateway Fabric 会自动使用该端点绕过这一问题，从而减少了在重载过程中处理新旧 worker 进程所需的额外资源开销。

当您开始更频繁地对 NGINX Gateway Fabric 进行更改时，重新加载也将更加频繁。如欲了解当前安装的 NGF 重载的频率或时间，请查看 Prometheus 指标 nginx_gateway_fabric_nginx_reloads_total。如需全面、深入地了解这一问题，请点击此处，查看 Nick Shadrin 的文章！

以下示例展示了 Prometheus 仪表盘中采用两个 NGINX Gateway Fabric 部署的环境的指标：

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

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 仪表盘概览

BackendTLSPolicy

此版本现在提供了备受期待的 BackendTLSPolicy 支持。BackendTLSPolicy 在 NGINX Gateway Fabric 和应用之间引入了加密 TLS 通信功能，可大幅增强通信通道的安全性。以下示例展示了如何在依据受信任证书颁发机构 (CA) 的要求验证服务器证书时，通过指定 TLS 密码和协议等设置来实施策略。

借助 BackendTLSPolicy，用户能够确保 NGF 与其后端之间的流量安全。您还可以设置最低 TLS 版本和密码套件，从而防止恶意应用劫持连接，并对集群内的流量进行加密。

如需配置后端 TLS 卸载，首先要创建一个 ConfigMap，其中需包含所要使用的 CA 认证。有关内部 Kubernetes 证书管理方面的帮助，请查看本指南。

kind: ConfigMap
apiVersion: v1
metadata:
  name: backend-cert
data:
  ca.crt: 
         < -----BEGIN CERTIFICATE-----
	   -----END CERTIFICATE-----
          >

接下来，创建 BackendTLSPolicy，它支持我们的 secure-app service，并引用在上一步中创建的 ConfigMap：

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendTLSPolicy
metadata:
  name: backend-tls
spec:
  targetRef:
    group: ''
    kind: Service
    name: secure-app
    namespace: default
  tls:
    caCertRefs:
    - name: backend-cert
      group: ''
      kind: ConfigMap
    hostname: secure-app.example.com

URLRewrite

借助 URLRewrite 过滤器，您可以修改传入请求的原始 URL，并将其重定向到不同的 URL，而不会对性能产生任何影响。当后端应用更改其公开的 API，但您又想保持现有客户端的向后兼容性时，此功能特别有用。您还可以使用此功能向客户端公开一致的 API URL，同时将请求重定向到具有不同 API URL 的不同应用，从而提供一种“体验型”API。该 API 兼具多个不同 API 的功能，可提高客户端的便利性和性能。

首先，我们为 NGINX Gateway Fabric 创建一个网关。这便于我们定义 HTTP 监听器，并配置 80 端口，以实现最佳性能。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: cafe
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    port: 80
    protocol: HTTP

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

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: coffee
spec:
  parentRefs:
  - name: cafe
    sectionName: http
  hostnames:
  - "cafe.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /coffee
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplaceFullPath
          replaceFullPath: /beans
    backendRefs:
    - name: coffee
      port: 80
  - matches:
    - path:
        type: PathPrefix
        value: /latte
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /
    backendRefs:
    - name: coffee
      port: 80

HTTP 重写功能不仅有助于确保客户端端点与后端之间映射的灵活性，而且还允许将流量从一个 URL 重定向到另一个 URL，这在将内容迁移到新网站或 API 流量时大有帮助。

尽管 NGINX Gateway Fabric 支持基于路径的重写，但目前不支持基于路径的重定向。如果您的环境需要这项功能，请告诉我们。

产品遥测

我们决定在 1.2 版本中增加产品遥测功能，作为被动收集反馈的机制。该功能将从您的环境中收集各种指标，并每 24 小时向我们的数据收集平台发送一次指标。它不会收集任何个人身份信息 (PII)。请点击此处，查看收集内容的完整列表。

我们承诺就遥测功能保持完全透明。我们会记录所收集的每个字段，您可以选择准许我们收集哪些内容，并可以随时完全禁用这项功能。我们计划在社区会议上与大家一起定期查看根据我们收集的统计数据得出的分析结果，敬请关注！

资源

有关 NGINX Gateway Fabric 1.2.0 的完整变更日志，请查看版本说明。如欲试用 NGINX Plus NGINX Gateway Fabric for Kubernetes，请立即下载 30 天免费试用版或者联系我们讨论您的用例。

如欲加入我们、了解后续计划或查看 NGINX Gateway Fabric 的源代码，请访问我们在 GitHub 上的仓库！

我们每两周举行一次社区会议，时间为太平洋时间周一上午 9 点/格林尼治标准时间下午 5 点。有关会议链接、更新、议程及笔记，请查看 NGINX Gateway Fabric 会议日历。此外，您还可从我们的 GitHub 自述文件中随时获取链接。