使用 Kubernetes(後簡稱 K8s)架設網站時,通常會建立一個 Ingress 作為網站的入口,不過在 Ingress 停止更新後,新功能會被統整在一個叫做「 Gateway API 」的服務中,現在就一起來了解他的 5 大內建功能、比較和相關功能的操作步驟教學吧!
Gateway API 介紹:
Gateway API 是什麼
Gateway API 是基於 Ingress 的概念,做為 K8s 架設網站入口時的一個新選擇,用於定義和配置網路路由,提供更強大靈活的配置。
Gateway API 的 5 大內建功能
Gateway API 提供多種內建功能,讓使用者用簡單的步驟取代以往繁瑣的設定方法,以下為 Gateway API 最值得關注的 5 大內建功能:
- TCP routing:可以透過不同 Port 將流量導向至不同 Service。
- HTTP Header Modifiers:可以修改來自於Client的HTTP Reuqest 及Response Header。
- HTTP traffic splitting:支援流量分配,可定義流量以權重方式,達到Canary 及Blue/green 部署。
- Cross-Namespace routing:透過 Gateway 可以讓多個 Namespace 的服務共用一個入口。
- HTTP path redirects and rewrites:可以輕鬆達到 HTTP Redirects HTTPS、Path Redirects、Rewrite等功能。
Gateway API 與 API Gateway 的差異
大家常常會把 Gateway API 和 API Gateway 搞混 ,雖然他們的名稱看起來很像,但其實在定義和用法上卻不太相同,這邊就幫大家簡單說明兩者之間的不同:
- API Gateway:可以用於整合 API 及提供統一入口,以及作為協助 API 承擔流量的服務、也可以作為不同微服務的 Proxy 使用。
- Gateway API:主要用於 K8s 的網路使用,可以使用流量管理、流量分配、請求轉換等功能。
Gateway API 與 Ingress 比較
那你可能也會好奇 Gateway API 與 Ingress 到底差在哪?
Gateway API 的出現解決了 Ingress 的一些限制和不一致性,我們可以透過以下表格快速了解它們之間的差異!
Gateway API 實作-Canary Deployment 步驟教學:
上文有提到 Gateway API 可以透過 HTTP traffic splitting 來快速達到 Canary Deployment的部署。
這邊先簡單介紹一下 Canary Deployment,Canary Deployment 可以拿來為新版本做分流測試,讓少數使用者先試用新服務;若系統測試正常後再將正式環境更版為新版,這樣的方法可以避免新版完善前直接影響到所有使用者所帶來的風險。
以下就來示範 Canary Deployment 在 Gateway API 中的實作設定步驟!
環境建置
步驟一:建立一個 Cluster
( Demo 環境:GKE >版本:1.28.8-gke.1095000)
建立一個 K8s 的 Cluster 這邊以 GKE 為例。
步驟二:開啟 Gateway API
在 GKE 建立時記得開啟 Cluster-Networking 下的 Gateway API;若為事先建立好的可以直接點選 Enable 即可啟用。
截圖自:Google Kubernetes Engine 產品頁
©2024 Google
服務設定
步驟三:建立兩個不同版本的 Deployment
使用第一版的 Image 撰寫一份 Deployment yaml 檔。
apiVersion: apps/v1
kind: Deployment
metadata:
name: wi-deployment
labels:
app: web
spec:
replicas: 2
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- image: [ IMAGE 1 ]
imagePullPolicy: IfNotPresent
name: web
ports:
- containerPort: 8080
protocol: TCP
使用第二版 Image 撰寫一份 Deployment yaml 檔。
apiVersion: apps/v1
kind: Deployment
metadata:
name: wi-deployment2
labels:
app: web2
spec:
replicas: 2
selector:
matchLabels:
app: web2
template:
metadata:
labels:
app: web2
spec:
containers:
- image: [ IMAGE 2 ]
imagePullPolicy: IfNotPresent
name: web2
ports:
- containerPort: 8080
protocol: TCP
步驟四:建立對應兩個 Deployment 的 Service
apiVersion: v1
kind: Service
metadata:
name : wi-service
spec:
type: ClusterIP
selector:
app: web
ports:
- protocol: TCP
port: 8080
targetPort: 8080
建立一個 Service 並接至第二版 Deployment yaml 檔。
apiVersion: v1
kind: Service
metadata:
name : wi-service2
spec:
type: ClusterIP
selector:
app: web2
ports:
- protocol: TCP
port: 8080
targetPort: 8080
步驟五:建立 Gateway
撰寫一個 Gateway 並設置 Listeners
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
name: wi-gateway
spec:
gatewayClassName: gke-l7-global-external-managed
listeners:
- name: gatewaylb
port: 8080
protocol: HTTP
allowedRoutes:
kinds:
- kind: HTTPRoute
namespaces:
from: All
步驟六:建立 HTTPRoute 設定分流
撰寫一個 HTTP Route 並指定權重將流量分配至兩個 Service。
(筆者這邊是設定 10:90 可以更明顯觀察差異)
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: wi-route
spec:
parentRefs:
- name: wi-gateway
rules:
- backendRefs:
- name: wi-service
port: 8080
weight: 10
- name: wi-service2
port: 8080
weight: 90
功能檢查與實現
步驟七:觀察 Gateway Detail
可以看到剛剛透過 yaml 建立的 Gateway 成功在 GKE-Gateways、Services&Ingress Console 上顯示,並連接到我們指定的 Router。
同樣可以在 GKE-Gateways、Services&Ingress Console 中看到 Route 被成功建立並接至 Gateway 及我們指定的兩個 Service。
截圖自:Google Kubernetes Engine 產品頁
©2024 Google
步驟九:檢查 Load Balancing 設定
接著可以觀察到 GKE 幫我們自動建立了一個 Network services-LB 並連接兩個後端
截圖自:Google Load balancing 產品頁
©2024 Google
剛剛透過 yaml 建立的 Service 成功被套用到 Load Balancing 的 Backend 上。
截圖自:Google Load balancing 產品頁
©2024 Google
步驟十:觀察流量
透過 siege 指令進行流量測試,快速從蒐集到的 Log 可以觀察到流量確實依照設定的 10:90 成功分配至不同的 Service。
截圖自:Google Logging 產品頁
©2024 Google
結論
如果您目前是使用 Ingress 來架設 K8s 的入口網站,非常推薦可以嘗試改用 Gateway API 看看,Gateway API 不只承襲了 Ingress 原先的優點,還近一步將其功能強化,相信你只要試過一次就回不去了。
看完這次對 Gateway API 的介紹和相關功能的實作教學後是不是對 Gateway API 其他用途更有興趣了呢!如果對 Gateway API 服務上還有任何想了解的內容,歡迎聯絡 Cloud Ace 獲得更進一步的資訊。
▋延伸閱讀: