很高興與大家分享NGINX Gateway Fabric 的最新消息,它是我們對Kubernetes Gateway API 的一致性實作。我們最近將其更新到了1.2.0 版本,並增加了一些令人期待的全新功能和改進功能。此版本主要專注於增強平台功能,並確保其滿足用戶需求。我們不僅增添了對於F5 NGINX Plus 的支援,而且還擴增了API 選項,以涵蓋最受歡迎的用例。我們相信,這些增強功能將為所有使用者帶來更好的體驗,並幫助他們更有效率地實現目標。
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
即便使用預設的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 部署的環境的指標:
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 。
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