NGINX Kubernetes Gateway 是一個按照“Kubernetes Gateway API 規範”來執行的控制器，該規範是從“Kubernetes Ingress API 規範”演變而來的。Gateway API 是由Kubernetes網絡特別興趣小組(SIG‑NETWORK) 管理的開源項目，旨在改善Kubernetes 的服務網絡並實現其標準化。NGINX 是該項目的積極貢獻者。

如果您目前正積極使用Kubernetes，那麼Ingress API 對象和許多可用的Ingress 實施對您來說一定不陌生。Gateway API 是暴露Kubernetes 應用和API 的最新方法。如欲了解有關當前其他可用選項的更多信息，請參閱《Kubernetes 網絡入門》。

近幾年來，隨著越來越多的企業跨各種混合雲和多雲環境在生產級Kubernetes 集群中部署Ingress controller，他們逐漸認識了使用Gateway API 來解決各項挑戰的必要性：

• 其中一個挑戰是，最初的Ingress 資源在設計時只考慮了一個用戶角色，即監督整個配置的Kubernetes 運維人員或管理員。這種模型在許多擁有多個團隊的企業中都不適用，包括應用開發人員、平台運維人員、安全管理員等，他們在協作開發和交付應用的過程中需要控制Ingress 配置的不同方面。Gateway API用了新的模式，並使其能夠輕鬆地委託多個角色對網絡配置進行控制。

• 另一個挑戰是許多Ingress 實施中的註釋和自定義資源類型(CRD) 激增，它們解鎖了不同數據平面的功能，並實現了Ingress 資源中沒有內置的功能，例如基於標頭的匹配、流量加權和多協議支持。Gateway API 可將此類功能作為核心API 標準的一部分來進行提供。

NGINX Kubernetes Gateway 是什麼？

NGINX Kubernetes Gateway 由Ingress controller 發展而來，它解決了現代客戶環境中多個團隊管理Kubernetes 基礎架構的難題。此外，它還提供了許多無需實施CRD 就可以實現的功能，簡化了部署和管理流程。NGINX Kubernetes Gateway 利用經過驗證的NGINX 技術作為其數據平面，能夠提供一流的性能、可視性和安全性。

NGINX Kubernetes Gateway 通過將基於角色的訪問控制(RBAC) 映射到相關角色（基礎架構提供商、集群操作員和應用開發人員），對三個主要的Gateway API 資源（GatewayClass、Gateway 和Route）進行了標準化。

明確定義並劃分不同角色的職責範圍有助於簡化管理。具體來說，基礎架構提供商負責為Kubernetes 集群定義GatewayClasses，集群運維人員則負責在集群中部署和配置Gateway（包括策略），而應用開發人員可以自由地將Route 附加到Gateway，以對外暴露應用。

此外，NGINX Kubernetes Gateway 通過對大多數用例的內置核心功能進行標準化處理，簡化了Kubernetes 環境中服務網絡的部署和管理，從而減少了對CRD 的需求。NGINX Kubernetes Gateway 內測版實施主要通過七層（HTTP 和HTTPS）路由交付Ingress controller 功能。未來的功能發展將受社區反饋和用例的驅動，包括四層路由功能。根據Gateway API 和NGINX Kubernetes Gateway 的長期路線圖，它們最終將交付由Ingress controller 提供的功能超集。

NGINX Kubernetes Gateway 與NGINX Ingress Controller 有何不同？

F5 NGINX Ingress Controller通過實施Ingress API 規範來提供核心功能，並且使用自定義註釋、CRD 和NGINX Ingress 資源提供擴展功能。NGINX Kubernetes Gateway 遵守Gateway API 規範，能夠在簡化實施的同時，更好地與處理服務網絡配置的組織角色對齊。

下表比較了標準Ingress API、帶CRD 的NGINX Ingress Controller 和Gateway API 的關鍵高級特性，描述了它們各自的功能。

NGINX Kubernetes Gateway 是否會取代NGINX Ingress Controller？

NGINX Kubernetes Gateway 不會取代NGINX Ingress Controller。更確切地說，它是一種基於Gateway API 規範內測版的新興技術，僅用於進行評估， 並不適用於生產環境。NGINX Ingress Controller 則是一種成熟、穩定、適用於生產環境並廣為客戶所用的技術。它可以通過自定義註釋和CRD 針對特定用例量身定制。舉例來說，NGINX Ingress Controller 需要使用NGINX Ingress 資源（包括VirtualServer、VirtualServerRoute、TransportServer 和Policy ）來實施基於角色的方法。

我們認為，NGINX Kubernetes Gateway 短期內不會取代NGINX Ingress Controller —— 如果真要取代也是幾年之後的事情了。NGINX Ingress Controller 將繼續為各種環境和用例中的南北向網絡流量管理髮揮著重要作用，包括負載均衡、流量限制、流量分割和安全防護。

NGINX Kubernetes Gateway 是一種API 網關嗎？

從名稱上看，“Gateway API（網關API）”聽起來像是“API 網關”，但事實並非如此。正如我們在《API 網關vs. Ingress Controller vs. Service Mesh該怎麼選？》中討論的那樣，“API 網關”描述了一組可以通過不同類型的代理（ADC 或負載均衡器和反向代理最為常見，Ingress Controller 和Service Mesh 日漸興起）實現的用例。也就是說，就像NGINX Ingress Controller 一樣，NGINX Kubernetes Gateway 可用於API 網關用例，包括將請求路由到特定的微服務、實施流量策略及支持灰度和藍綠部署。其內測版主要用於處理HTTP/HTTPS 流量，未來計劃還將支持更多協議和用例。

安裝

本指南將引導您完成如何在使用 Kubernetes 集群上安裝 NGINX Kubernetes Gateway。

先決條件

• kubectl

部署 NGINX Kubernetes 

注意：NGINX Kubernetes Gateway 只能在nginx-gateway命名空間中運行。此限制將在未來的版本中解決。

1. 克隆回購併切換到nginx-kubernetes-gateway目錄：

   git clone https://github.com/nginxinc/nginx-kubernetes-gateway.git
   cd nginx-kubernetes-gateway
   

2. 安裝網關CRD：

   kubectl apply -k "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.5.1"
   

3. 創建 nginx-gateway 名稱空間：

   kubectl apply -f deploy/manifests/namespace.yaml
   

4. 創建njs-modules ConfigMap：

   kubectl create configmap njs-modules --from-file=internal/nginx/modules/src/httpmatches.js -n nginx-gateway
   

5. 創建GatewayClass資源：

   kubectl apply -f deploy/manifests/gatewayclass.yaml
   

6. 部署 NGINX Kubernetes 網關：

   kubectl apply -f deploy/manifests/nginx-gateway.yaml
   

7. 確認 NGINX Kubernetes Gateway 正在nginx-gateway命名空間中運行：

   kubectl get pods -n nginx-gateway
   NAME                             READY   STATUS    RESTARTS   AGE
   nginx-gateway-5d4f4c7db7-xk2kq   2/2     Running   0          112s

驗證 NGINX Kubernetes 

1. 前置作業

1. 按照安裝說明部署 NGINX 網關。

2. 將 NGINX Kubernetes Gateway 的公共 IP 地址保存到 shell 變量中：

   GW_IP=XXX.YYY.ZZZ.III
   

3. 保存 NGINX Kubernetes Gateway 的端口：

   GW_PORT=<port number>
   

2. 部署咖啡館應用

1. 創建咖啡和茶部署和服務：

   kubectl apply -f cafe.yaml
   

2. 檢查 Pod 是否在default命名空間中運行：

   kubectl -n default get pods
   NAME                      READY   STATUS    RESTARTS   AGE
   coffee-6f4b79b975-2sb28   1/1     Running   0          12s
   tea-6fb46d899f-fm7zr      1/1     Running   0          12s
   

3.配置路由

1. 創建Gateway：

   kubectl apply -f gateway.yaml
   

2. 創建HTTPRoute資源：

   kubectl apply -f cafe-routes.yaml
   

4. 測試應用

要訪問該應用程序，我們將使用curl向coffee和tea服務發送請求。

coffee：

curl --resolve cafe.example.com:$GW_PORT:$GW_IP http://cafe.example.com:$GW_PORT/coffee
Server address: 10.12.0.18:80
Server name: coffee-7586895968-r26zn

tea：

curl --resolve cafe.example.com:$GW_PORT:$GW_IP http://cafe.example.com:$GW_PORT/tea
Server address: 10.12.0.19:80
Server name: tea-7cd44fcb4d-xfw2x

參考資料

https://github.com/nginxinc/nginx-kubernetes-gateway/blob/main/docs/installation.md

关于 NGINX Kubernetes Gateway，你需要知道的 5 件事