NGINX Gateway Fabric 1.2.0 版本发布公告

NGINX | 2024年3月29日

我们很高兴与大家分享NGINX Gateway Fabric的最新动态。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 Open Source通常提供的指标外，还会导出其他高级指标，其中包括HTTP请求、流、连接等多种指标。有关完整列表，可查看NGINX的Prometheus导出器所提供的便捷列表。但请注意，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

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

图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 Open Source，也能平稳处理配置变更。但是，当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实例的环境内该指标的情况：

显示NGINX Gateway Fabric重新加载总次数的Prometheus图表

图 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服务，并引用上一步创建的 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

URL重写

使用URLRewrite筛选器，可以修改传入请求的原始URL，并将其重定向到其他URL，且不会影响性能。当后端应用更改其公开的API，但仍需保持与现有客户端的向后兼容性时，此功能尤其有用。还可以使用此功能向客户端公开一致的API URL，同时将请求重定向到使用不同API URL的不同应用，从而提供一个整合多个不同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的完整变更日志，请参阅发行说明。如需在Kubernetes上试用搭配NGINX Plus的NGINX Gateway Fabric，请立即开始30天免费试用，或联系我们，讨论您的使用场景。如果您希望参与项目、了解后续计划或查看NGINX Gateway Fabric的源代码，请访问我们的GitHub代码仓库！我们每两周于周一太平洋时间9:00／GMT 17:00举行一次社区会议。会议链接、最新动态、议程和会议记录均可在NGINX Gateway Fabric会议日历中查看。相关链接也始终可在我们的GitHub自述文件中找到。