上一章節講解了 Gateway API Http 沒有設定證書的方法。本章將延續介紹,將網關掛上 GTS 產出的 Wildcard 通用證書後,跨命名空間的使用方式,並一同演示網關 HTTPRoute 來配置金絲雀部署(Canary Deployment)
上篇文章已經實作了上半部 Default 命名空間下的 HTTPRoute,接下來會實作下半部分 httpd 命名空間。
進入到安全性頁面 > Certificat Manager(憑證管理員),點擊新增憑證
建立 wildcard 憑證 *.demoit.shop
接下來去 Cloud DNS 建立上面的 DNS 授權的 CNAME,等待 5 分鐘,會發現證書已經產生下來了。
建立 certificate map 以參照 certificate map entry 來關聯您的憑證:
$ gcloud certificate-manager maps create wild-card-mapping
建立 certificate map entry 並將其與您的憑證以及 certificate map 關聯起來
$ gcloud certificate-manager maps entries create cert-mapping-entry \
--map="wild-card-mapping" \
--certificates="demo-wild-card" \
--hostname="*.demoit.shop"
將上篇文章建立的 Gateway 物件新增 Annotations networking.gke.io/certmap: wild-card-mapping
,並寫上 listeners.https 443 port
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
name: external-http
annotations:
# 填入上一步驟建立的 certificate map entry 的名稱
networking.gke.io/certmap: wild-card-mapping
spec:
gatewayClassName: gke-l7-global-external-managed
listeners:
- name: http
protocol: HTTP
port: 80
- name: https
protocol: HTTPS
port: 443
在 httpd 命名空間打上 labelsshared-gateway-access: "true"
並創建新的 new-old-nginx Deployment 及 Service
apiVersion: v1
kind: Namespace
metadata:
name: httpd
labels:
shared-gateway-access: "true"
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: old-nginx
namespace: httpd
spec:
replicas: 1
selector:
matchLabels:
run: old-nginx
template:
metadata:
labels:
run: old-nginx
spec:
containers:
- name: v1
image: a51907/v1-canary-deployment:x86
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: old-nginx
namespace: httpd
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
run: old-nginx
sessionAffinity: None
type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: new-nginx
namespace: httpd
spec:
replicas: 1
selector:
matchLabels:
run: new-nginx
template:
metadata:
labels:
run: new-nginx
spec:
containers:
- name: v2
image: a51907/v2-canary-deployment:x86
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: new-nginx
namespace: httpd
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
run: new-nginx
sessionAffinity: None
type: ClusterIP
在 httpd 命名空間下創建新的 HTTPRoute,其中後端路徑為 /canary
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: new-old-nginx-httproute
namespace: httpd
spec:
parentRefs:
- kind: Gateway
name: external-gateway
namespace: gateway
hostnames:
- "gateway.demoit.shop"
rules:
- matches:
- path:
value: /canary/
backendRefs:
- name: old-nginx
port: 80
- matches:
- path:
value: /canary/
headers:
- name: env
value: new
backendRefs:
- name: new-nginx
port: 80
打開 GKE > 閘道、Service與Ingress 頁面查看詳細資料,會發現 https 及 new-old-nginx-httproute 已經顯示出來了
訪問 https://gateway.demoit.shop/canary/
頁面查看證書及內容
使用 Curl 指令測試同一個 Path ,發現帶不同的 Header 會請求到不同的 Pod 中
在 GKE 中,所有 Ingress 資源都可以直接轉換為 Gateway 和 HTTPRoute 資源。單個 Ingress 同時對應著網關(用於前端配置)和 HTTPRoute(用於路由配置)。
以下示例展示了 Ingress 對應的 Gateway 和 HTTPRoute 配置。
Ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
annotations:
kubernetes.io/ingress.class: "gce-internal"
spec:
rules:
- host: "example.com"
http:
paths:
- pathType: Prefix
path: /
backend:
service:
name: site
port:
number: 80
- pathType: Prefix
path: /shop
backend:
service:
name: store
port:
number: 80
Gateway.yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
name: my-gateway
spec:
gatewayClassName: gke-l7-rilb
listeners:
- name: http
protocol: HTTP
port: 80
allowedRoutes:
kinds:
- kind: HTTPRoute
HTTPRoute.yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: my-route
spec:
parentRefs:
- name: my-gateway
hostnames:
- "example.com"
rules:
- matches:
- path:
value: /
backendRefs:
- name: site
port: 80
- matches:
- path:
value: /shop
backendRefs:
- name: store
port: 80
在 GKE 上部署應用程序時,選擇合適的入口控制器至關重要。傳統 Ingress 資源雖然簡單易用,但缺乏高級路由功能和擴展性。相比之下,Gateway API 作為新一代標準,提供了更強大、靈活和安全的流量管理方案。
在探索 Google Kubernetes Engine (GKE) 上 Gateway API 的過程中,深刻體會到它為現代應用程式帶來的強大流量管理能力。Gateway API 不僅簡化了路由配置,其豐富的功能更能滿足各種複雜部署需求,例如流量拆分、金絲雀發布和 A/B 測試等。
儘管 Gateway API 優勢明顯,但 Ingress 仍然是許多簡單應用的有效選擇。最終,最佳選擇取決於您的具體需求和未來擴展計劃。