Gateway API 用什么方式來管理 Kubernetes 中的流量
在 Kubernetes 中，流量管理可能相當復雜，尤其是當現代應用由多個服務組成時，如前端、API 和后端分布在混合和多云環境中。隨著這些環境的擴展，確保服務之間的安全、高效和可靠通信變得越來越困難。
傳統方法通常涉及結合使用 Ingress 進行路由、NGINX 進行負載均衡和 NetworkPolicies 進行安全保障。雖然有效，但這種分散的設置可能會帶來運營挑戰，例如管理多個配置、確保工具之間的一致性、在動態環境中擴展以及維護統一的安全策略。這些復雜性可能會減慢部署速度，使其更難適應快節奏的微服務環境，而在這些環境中，可擴展性和可靠性至關重要。
Kubernetes Gateway API 通過引入標準化的、Kubernetes 原生框架來管理流量，從而解決了這些挑戰。它旨在擴展和改進 Ingress，支持高級路由、強大的負載均衡、增強的安全性和多租戶；所有這些都原生支持 Kubernetes 聲明式配置。Devtron 進一步簡化了這一過程，提供了一個原生集成新 Kubernetes 網絡技術（如 Gateway API）的 DevOps 平臺。從部署自動化到安全和監控，Devtron 讓您的應用程序在沒有運營復雜性的情況下順利運行。
Kubernetes 中的網絡
當您在 Kubernetes 中部署應用程序時，它們在由多個節點組成的集群中運行。這些節點可能是虛擬機或裸機服務器，Kubernetes 使用 pod 將您的應用程序分布在它們之間。Pod 是 Kubernetes 中最小的可部署單元，它可以根據擴展、復制和資源可用性等因素在節點之間移動。
為了將用戶連接到您的應用程序，Kubernetes 依賴于服務。服務充當運行應用程序的 pod 和網絡之間的橋梁。針對不同用例，有不同類型的服務：
- ClusterIP：默認類型，提供內部 IP，使應用程序只能在集群內訪問。
- NodePort：在每個節點 IP 的靜態端口上暴露服務，允許有限的外部訪問。
- LoadBalancer：分配外部 IP 地址，使服務可以被集群外的用戶訪問。
對于需要外部訪問的應用程序，LoadBalancer 服務是常見選擇。然而，為每個應用程序使用單獨的負載均衡器并不能很好地擴展。隨著服務數量的增長，它變得昂貴、浪費且難以管理。
為了解決這個問題，Kubernetes 引入了 Ingress 的概念。Ingress 充當集中入口點，根據 URL 路徑或主機名等規則將傳入流量路由到正確的服務。例如，到 my-site.com/bills 的流量可以路由到計費服務。這消除了為每個服務配置負載均衡器的需求，使其成為更高效的解決方案。
然而，Ingress 只是一組規則，它需要 Ingress 控制器（如 NGINX 或 Traefik）來處理流量并實現這些規則。雖然 Ingress 簡化了 Kubernetes 中的網絡，但它也有自己的一系列限制。
Kubernetes Ingress 的局限性
現在您已經了解了流量如何通過 LoadBalancers 和 Ingress 流入您的 Kubernetes 應用程序，讓我們深入了解 Ingress 的局限性。
雖然 Ingress 簡化了 Kubernetes 中的應用程序網絡，但它確實有一些限制，使其對現代復雜設置的效果較差：
- 協議限制：標準 Ingress 僅為 HTTP/HTTPS 流量（第 7 層）設計。如果您的應用程序使用其他協議如 TCP 或 UDP（第 4 層），單靠 Ingress 無法處理它們。您需要額外的工具或將它們與 Kubernetes 服務結合使用，以啟用 TCP 或 UDP 協議。
- 缺乏標準化：高級功能如負載均衡和流量路由不是標準 Ingress 規范的一部分。相反，它們依賴于您使用的特定 Ingress 控制器，如 NGINX 或 Traefik。每個控制器都有自己配置這些功能的方式，通常需要注解或自定義設置。這種缺乏標準化可能令人沮喪，尤其是當您管理多個集群或想要切換控制器時。
- 有限的可擴展性：SSL/TLS 終止、管理證書或與 Cert-Manager 等工具集成等功能不是由 Ingress 本身原生處理的。相反，這些依賴于 Ingress 控制器，支持水平各不相同。這可能使確保一致性變得困難，尤其是在多集群或多云環境中。對于高級功能，如無需額外配置或工具即可原生處理 SSL/TLS，可以引入像 Istio 這樣的服務網格。服務網格通過提供內置支持任務如 SSL 終止、流量加密等，擴展了 Kubernetes 的能力。
這些限制使標準 Ingress 對于復雜或大規模應用程序不太理想，尤其是在處理多樣化協議或高級流量控制需求時。認識到這些挑戰，Kubernetes 社區開發了 Gateway API，這是一個更靈活和可擴展的解決方案，用于解決 Ingress 模型中的差距。
什么是 Gateway API
Kubernetes Gateway API 是一個規范，它標準化了 Kubernetes 集群內流量路由的管理方式。它由 Kubernetes SIG-NETWORK 組創建，作為 Ingress API 限制的更靈活和強大的替代方案。Gateway API 使處理入口、負載均衡、服務發現和流量路由變得更容易，并且與 Kubernetes 的原生資源（如 Services 和 Endpoints）良好集成。雖然 Kubernetes 不提供默認實現，但有幾個流行的開源和商業工具，如 Istio 和 Envoy Gateway，支持 Gateway API。
Gateway API由三個主要組件組成：
- GatewayClass：將其視為設置 Gateway 的模板或藍圖。它定義了一組共享相同配置并由遵循該類規范的控制器管理的 Gateway。
- Gateway：這是流量處理發生的地方。Gateway 就像集群的入口點，例如云負載均衡器，根據您的配置將傳入流量引導到適當的目的地。
- HTTPRoute：這是您設置 HTTP 流量路由規則的地方。它幫助將流量從 Gateway 映射到您的后端服務，例如在 Kubernetes Pod 中運行的服務，基于 URL 路徑、頭部或主機等因素。
這些組件共同提供了一種結構化和靈活的方式來管理 Kubernetes 環境中的流量流動和路由。
Gateway API 如何工作
到目前為止，我們已經介紹了 Kubernetes Gateway API 是什么，為什么它很重要，以及它的關鍵組件?，F在，讓我們深入了解它是如何工作的，讓您更清楚地了解其功能。
以下是其每個組件的邏輯分解及其工作原理：
Gateway API流程圖
Gateway 控制器
與 Ingress 控制器類似，Gateway 控制器是管理所有 Gateway 資源的中央組件。它負責確保 Gateway 資源中定義的配置得到正確實施。Gateway 控制器監聽 Gateway、GatewayClass 和 Route 對象的變化，然后相應地更新網絡配置以處理傳入流量。這使 Kubernetes 集群能夠對路由配置的變化做出反應并高效地管理流量。
GatewayClass
GatewayClass 定義了集群中 Gateway 的行為和配置。將其視為 Gateway 資源的模板或藍圖。它指定哪個控制器將管理 Gateway（這可能是開源解決方案如 Istio 或自定義實現）。GatewayClass 還包含 IP 池和資源限制等配置?；A設施提供商負責定義和管理 GatewayClass。
以下是 GatewayClass 的示例代碼片段：
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: example-gatewayclass
spec:
controller: example.com/gateway-controller這定義了一個名為example-gatewayclass的 GatewayClass。它指定了負責管理此 Gateway 的控制器（example.com/gateway-controller）。
Gateway
一旦定義了 GatewayClass，您就可以基于它創建 Gateway 對象。Gateway 對象是基于特定 GatewayClass 創建的。它定義了流量如何進入集群以及哪些監聽器將處理流量（例如 HTTP、HTTPS）。單個 Gateway 可以處理多個應用程序的流量，這些應用程序可以共享同一個 Gateway，同時仍然保持各自的路由規則。
以下是 Gateway 的示例代碼片段：
apiVersion: gateway.networking.k8s.io/v1
kind:Gateway
metadata:
name:example-gateway
spec:
gatewayClassName:example-gatewayclass
listeners:
-name:http
port:80
protocol:HTTP這定義了一個名為example-gateway的 Gateway，它使用之前創建的example-gatewayclass。它在端口 80 上使用 HTTP 協議來處理傳入的流量。
HTTPRoute
在設置好 Gateway 后，您需要定義 HTTPRoute（或其他路由類型，如 TCPRoute）來指定如何將流量轉發到集群中的服務。HTTPRoute 對象定義了路由 HTTP 流量的規則，例如匹配路徑、標頭或其他 HTTP 屬性。HTTPRoute 對象本質上充當了一組指令，告訴 Gateway 如何將傳入流量定向到 Kubernetes 集群中的特定應用程序或服務。
以下是 HTTPRoute 配置的示例：
apiVersion: gateway.networking.k8s.io/v1
kind:HTTPRoute
metadata:
name:example-httproute
spec:
hosts:
-"example.com"
rules:
-matches:
-path:
type:Prefix
value:/app
forwardTo:
-serviceName:app-service
port:80這定義了一個名為example-httproute的 HTTPRoute，它監聽發送到example.com的請求。它將路徑為/app的請求轉發到端口 80 上的app-service。
這些組件協同工作，使 Kubernetes 中的流量路由管理變得更加簡單。它們讓團隊對網絡流量的流向和安全性處理有更多的控制權。該系統的設計使得不同的團隊，如基礎設施提供商、集群運營商和應用程序開發人員，可以順暢地協作，而不會干擾彼此的任務。
Gateway API 與 Kubernetes Ingress 對比
現在我們已經清楚地了解了 Gateway API 的工作原理，讓我們探討一下 Gateway API 和 Kubernetes Ingress 之間的主要區別，這兩者都用于 Kubernetes 中的流量管理。
安裝和使用 Gateway API
到目前為止，Gateway API 的必要性應該已經很明確了。接下來，讓我們看看如何在集群中安裝 Gateway API 并有效地使用它來管理流量。
前提條件
要跟隨本教程，您需要一個具有兩個或更多節點的 Kubernetes 集群。您可以使用minikube創建一個，或者使用以下 Kubernetes 實驗環境之一：
- Killercoda
- Play with Kubernetes
在本教程中，我們將安裝 Kubernetes Gateway API 并使用它來路由電子商務應用的前端和后端之間的流量。到最后，您將了解如何設置 GatewayClass、Gateway 和 HTTPRoute 以實現高效的流量管理。
步驟 1：安裝 Gateway API CRD
首先，在我們的集群中安裝 Gateway API 自定義資源定義（CRD）：
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/latest/download/standard-install.yaml驗證安裝：
kubectl get crds | grep gateway步驟 2：部署網關控制器
Gateway API 本身并不提供內置控制器。您可以使用現有的控制器，如 Istio、Kong 或 Envoy Gateway。例如，要安裝 Istio Gateway 控制器，請運行：
istioctl install --set profile=default
kubectl apply -f https://github.com/istio/istio/releases/latest/download/gateway.yaml步驟 3：定義 GatewayClass
GatewayClass 定義了網關的動作，類似于 IngressClass。
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: my-gateway-class
spec:
controllerName: istio.io/gateway-controller直接應用:
kubectl apply -f gatewayclass.yaml步驟 4：創建網關
網關是處理流量的實際網絡入口點。
apiVersion: gateway.networking.k8s.io/v1
kind:Gateway
metadata:
name:ecommerce-gateway
spec:
gatewayClassName:my-gateway-class
listeners:
-name:http
protocol:HTTP
port:80應用:
kubectl apply -f gateway.yaml步驟 5：定義 HTTP 路由
路由定義了如何將傳入請求轉發到后端服務。
apiVersion: gateway.networking.k8s.io/v1
kind:HTTPRoute
metadata:
name:frontend-to-backend
spec:
parentRefs:
-name:ecommerce-gateway
rules:
-matches:
-path:
type:Prefix
value:"/api"
backendRefs:
-name:backend-service
port:8080應用:
kubectl apply -f httproute.yaml步驟 6：部署前端和后端服務
為了簡化，部署一個基本的前端和后端。
前端服務：
apiVersion: v1
kind:Service
metadata:
name:frontend-service
spec:
selector:
app:frontend
ports:
-protocol:TCP
port:80
targetPort:3000后端服務:
apiVersion: v1
kind:Service
metadata:
name:backend-service
spec:
selector:
app:backend
ports:
-protocol:TCP
port:8080
targetPort:8080應用:
kubectl apply -f frontend-service.yaml
kubectl apply -f backend-service.yaml步驟 7：測試設置
獲取網關的外部 IP：
kubectl get gateway ecommerce-gateway發送請求:
curl http://<GATEWAY-IP>/api如果一切設置正確，請求應該被路由到后端服務。
結論
總而言之，與傳統的 Ingress 相比，Gateway API 提供了一種更靈活、更可擴展的方式來管理 Kubernetes 中的流量。通過引入 GatewayClass、Gateway 和 HTTPRoute 等新資源，它使團隊能夠更好地控制路由、安全性和基礎設施。其面向角色的設計促進了不同團隊之間的協作，在定義網絡策略和處理復雜流量場景方面提供了更大的靈活性。此外，憑借對多種協議的支持和加權路由等高級功能，Gateway API 成為在現代 Kubernetes 環境中處理流量的強大工具。
