在上一章中，您已學習到如何使用 Ingress 資源將服務對外暴露。然而，標準 Ingress API 所支援的功能十分有限。 在真實世界的應用中，您必須依賴所選用的 Ingress 實作來提供非標準的擴充功能。作為替代方案，現在引入了一個全新的 API —— Gateway API。
Gateway API 為使用者提供了更廣泛的功能，透過將流量路由至一個或多個閘道器代理 (gateway proxies)，讓 Kubernetes 服務 (Services) 能被外部世界存取。 這些代理不僅支援 HTTP 與 TLS，也支援一般通用的 TCP 與 UDP 服務。因此，雖然 Ingress 屬於 L7 代理，但 Gateway API 能支援向下至 L4 的代理功能。 在本章中，您將會深入了解這個全新的 API。
在開始之前，請建立 kiada 命名空間 (Namespace)，切換至 Chapter13/ 目錄，並透過執行下列指令來套用 SETUP/ 目錄下的所有資源清單 (manifests)：
$ kubectl create ns kiada
$ kubectl config set-context --current --namespace kiada
$ kubectl apply -f SETUP -R
注意 本章的程式碼檔案可在以下網址取得：https://github.com/luksa/kubernetes-in-action-2nd-edition/tree/master/Chapter13
Gateway API 由一組 Kubernetes 資源組成，讓您能夠設定閘道器代理 (gateway proxy)，並使用它將來自叢集外部的流量引導至您的服務。
這些服務不必是 NodePort 或 LoadBalancer 類型，也可以是標準的 ClusterIP 服務，就如同使用 Ingress 時一樣。
既然您已在上一章學習了 Ingress，介紹 Gateway API 最好的方式就是將兩者進行比較。 圖 13.1 顯示了您在兩者中會見到的 Kubernetes 物件種類 (object kinds)，以及它們彼此之間的關聯。
圖 13.1 比較 Ingress 與 Gateway API 資源
若要使用 Ingress API 將一組服務對外暴露，您需要建立一個 Ingress物件。同樣地，在 Gateway API 中，您則是建立一個 Gateway物件。 每個閘道器 (gateway) 都屬於一個特定的 GatewayClass，就如同每個 Ingress物件 都屬於特定的 IngressClass 一樣。 一個叢集可以提供一個或多個這樣的類別，因此您可以為所建立的每個gateway選擇其提供者 (provider)。
到目前為止，這兩個 API 除了物件類型的名稱之外沒有什麼不同。但在將服務連接至 Ingress 或 Gateway 物件時，情況就不一樣了。 在 Gateway API 中，您必須根據想要暴露的服務類型，建立特定類型的 Route物件 來完成這件事。而在 Ingress API 中，您是直接在 Ingress物件 內指定服務。
將流量路由規則獨立成個別物件的一項優點是，Gateway物件 可以保持精簡。 與其在單一龐大的物件中指定所有規則，這些規則會根據路由的性質被分散到多個不同種類的 Route物件 中。 雖然 Ingress 只支援 HTTP，但 Gateway API 也能直接支援 TLS、gRPC、TCP、UDP 流量。
然而，將gateway與route分開來的最大優勢在於，您可以將這些物件的管理權限劃分給不同的使用者角色。每個角色都能被賦予專屬的權限。 舉例來說，gateway通常由叢集管理員(cluster admins)來管理，而route則通常由應用程式開發人員來建立。 在 Ingress API 中，您無法拆分這些職責，所以開發人員必須自行管理gateway，或者必須由叢集管理員代勞。 如果您使用 Gateway API，就能夠妥善地劃分這些職責。
route的最後一項優勢在於，一個 Gateway物件 可以跨命名空間 (namespaces) 共用，如圖 13.2 所示。 一個命名空間中的route可以參照另一個命名空間中的gateway，route也能夠參照其他命名空間中的服務。 這項功能使得 Gateway API 比 Ingress 強大許多，因為您可以使用單一的 Gateway 與單一個公開 IP，來暴露橫跨多個命名空間的服務。
圖 13.2 跨命名空間使用閘道器與 HTTPRoutes
顧名思義，Gateway API 是一種應用程式介面 (API)，也就是定義系統行為的一組規則。這些規則必須由某個東西來實作。 與 Ingress 一樣，k8s 本身並未提供 Gateway API 的實作。取而代之的是，市面上有多種第三方實作可供使用。
您可能知道，一個 API 的多種實作無可避免地會導致這些實作之間在行為和可用功能上產生差異。 我們在上一章就看過這種情況，不同的 Ingress provider 使用不同的註解 (annotations)來設定非標準功能。 負責監督 k8s 網路並制定 Gateway API 的 Kubernetes 網路特別興趣小組 (Network SIG)，非常謹慎地避免重蹈 Ingress API 的覆轍。 為此，他們對該 API 進行了編排，以確保不同實作之間的一致性。為達成此目的，他們將每項功能與以下屬性關聯起來：