本頁說明如何在 Google Kubernetes Engine (GKE) VPC 原生叢集中,建立由區域性GCE_VM_IP_PORT
網路端點群組 (NEG) 支援的 Kubernetes 服務。
如要瞭解容器原生負載平衡的優點、需求和限制,請參閱「容器原生負載平衡」一文。
總覽
NEG 代表一組端點。GKE 支援 GCE_VM_IP_PORT
類型的獨立 NEG。GCE_VM_IP_PORT
NEG 支援使用 VM 的主要內部 IP 位址,或別名 IP 範圍的 IP 位址做為端點。
在使用獨立 NEG 的 GKE 虛擬私有雲原生叢集環境中,每個端點都是 Pod IP 位址和目標通訊埠。Pod IP 位址來自節點的 Pod 別名 IP 範圍,而該範圍來自叢集的 Pod 子網路次要 IP 位址範圍。
GKE 提供 NEG 控制器,可管理 GCE_VM_IP_PORT
NEG 的成員資格。您可以將建立的 NEG 新增為後端,用於在 GKE API 以外設定的負載平衡器後端服務。
下圖說明 Kubernetes API 物件如何對應至 Compute Engine 物件。
搭配 NEG 的 Ingress
將 NEG 與 GKE Ingress 搭配使用時,Ingress 控制器會協助建立負載平衡器的所有層面。包括建立虛擬 IP 位址、轉送規則、健康狀態檢查、防火牆規則等。
建議使用 Ingress 搭配容器原生負載平衡,因為 Ingress 具有許多功能,可簡化 NEG 管理作業。如果 Ingress 管理的 NEG 無法滿足您的用途,可以選擇使用獨立 NEG。
獨立的 NEG
如果部署 NEG 時,負載平衡器是由 Ingress 以外的任何項目佈建,就會被視為獨立 NEG。獨立 NEG 會透過 NEG 控制器部署及管理,但轉送規則、健康狀態檢查和其他負載平衡物件則會手動部署。
獨立 NEG 不會與啟用 Ingress 的容器原生負載平衡功能發生衝突。
下圖顯示在各情境中,負載平衡物件的部署方式有何差異:
防止 NEG 外洩
使用獨立 NEG 時,您必須負責管理 NEG 的生命週期,以及構成負載平衡器的資源。您可能會透過下列方式洩漏 NEG:
- 如果 NEG 仍由後端服務參照,刪除 GKE 服務時,系統不會進行垃圾收集。從後端服務取消參照 NEG,以便刪除 NEG。
刪除叢集時,在下列情況下,系統不會刪除獨立 NEG:
- 後端服務仍參照 NEG。
- 叢集刪除程序會在控制器刪除 NEG 前,先關閉 NEG 控制器。
為避免 NEG 外洩,請先從後端服務取消參照 NEG,然後刪除所有 NEG,再刪除叢集。
如果刪除叢集或服務後有 NEG 洩漏,可以使用 Google Cloud CLI 刪除 NEG。
獨立 NEG 的用途
獨立 NEG 有幾項重要用途。獨立 NEG 相當靈活。 這與 Ingress (搭配或不搭配 NEG 使用) 不同,後者定義了一組特定的負載平衡物件,這些物件經過精心挑選,方便使用者直接使用。
獨立 NEG 的用途包括:
容器和 VM 的異質服務
NEG 可以同時包含 VM 和容器 IP 位址。也就是說,單一虛擬 IP 位址可指向由 Kubernetes 和非 Kubernetes 工作負載組成的後端。您也可以使用這項功能,將現有工作負載遷移至 GKE 叢集。
獨立 NEG 可以指向 VM IP,因此您可以手動設定負載平衡器,指向由 VM 和容器組成的後端,以用於相同的服務 VIP。
自訂 Ingress 控制器
您可以透過自訂 Ingress 控制器 (或不使用 Ingress 控制器),設定以獨立 NEG 為目標的負載平衡器。
搭配 GKE 使用 Cloud Service Mesh
您可以搭配使用 Cloud Service Mesh 與 GKE。 Cloud Service Mesh 會使用獨立 NEG,為代管服務網格提供容器原生負載平衡。
搭配 GKE 使用外部 Proxy 網路負載平衡器
您可以使用獨立 NEG,透過 外部 Proxy 網路負載平衡器直接對容器進行負載平衡,Kubernetes/GKE 原生不支援這項功能。
Pod 完備性
就緒閘道是 Kubernetes 的擴充性功能,可將額外的意見回饋或信號注入 PodStatus,讓 Pod 轉換為就緒狀態。NEG 控制器會管理自訂就緒閘道,確保從 Compute Engine 負載平衡器到 Pod 的完整網路路徑正常運作。如要瞭解 GKE 中的 Pod 完備性門檻,請參閱容器原生負載平衡。
使用 NEG 的 Ingress 會代表負載平衡器部署及管理 Compute Engine 健康狀態檢查。不過,獨立 NEG 不會假設 Compute Engine 健康狀態檢查,因為這類檢查預計會分開部署及管理。您應一併設定 Compute Engine 健康狀態檢查和負載平衡器,避免流量傳送至尚未準備就緒的後端。如果沒有與 NEG 相關聯的健康狀態檢查狀態 (通常是因為未設定健康狀態檢查),當 NEG 控制器在 NEG 中規劃對應的端點時,就會將 Pod 的完備性門檻值標示為 True。
需求條件
您的叢集必須為虛擬私人雲端原生的。詳情請參閱建立虛擬私有雲原生叢集。
叢集必須啟用 HttpLoadBalancing
外掛程式。
GKE 叢集預設會啟用 HttpLoadBalancing
外掛程式。
事前準備
開始之前,請確認你已完成下列工作:
- 啟用 Google Kubernetes Engine API。 啟用 Google Kubernetes Engine API
- 如要使用 Google Cloud CLI 執行這項工作,請安裝並初始化 gcloud CLI。如果您先前已安裝 gcloud CLI,請執行
gcloud components update
,取得最新版本。
使用獨立 NEG
下列操作說明將示範如何在 GKE 上,搭配外部 HTTP 負載平衡器使用獨立 NEG。
您必須建立下列物件:
- 「Deployment」,可建立及管理 Pod。
- 建立 NEG 的 Service。
- 使用 Compute Engine API 建立的負載平衡器。這與搭配 Ingress 使用 NEG 不同,在後者中,Ingress 會為您建立及設定負載平衡器。使用獨立 NEG 時,您必須負責將 NEG 和後端服務建立關聯,才能將 Pod 連線至負載平衡器。負載平衡器由數個元件組成,如下圖所示:
建立 VPC 原生叢集
Autopilot 叢集預設為虛擬私有雲原生類型,因此您可以直接跳到「部署工作負載」一節。
如果是標準叢集,請在區域 us-central1-a
中建立虛擬私有雲原生叢集:
gcloud container clusters create neg-demo-cluster \
--create-subnetwork="" \
--network=default \
--location=us-central1-a
可建立部署作業
下列範例資訊清單會指定 Deployment,執行容器化 HTTP 伺服器的三個執行個體。HTTP 伺服器會以應用程式伺服器的主機名稱 (伺服器執行所在的 Pod 名稱) 回應要求。
建議使用會使用 Pod 完備性反饋的工作負載。
使用 Pod 完備性反饋
apiVersion: apps/v1 kind: Deployment metadata: labels: run: neg-demo-app # Label for the Deployment name: neg-demo-app # Name of Deployment spec: replicas: 3 selector: matchLabels: run: neg-demo-app template: # Pod template metadata: labels: run: neg-demo-app # Labels Pods from this Deployment spec: # Pod specification; each Pod created by this Deployment has this specification containers: - image: registry.k8s.io/serve_hostname:v1.4 # Application to run in Deployment's Pods name: hostname
使用硬式編碼延遲
apiVersion: apps/v1 kind: Deployment metadata: labels: run: neg-demo-app # Label for the Deployment name: neg-demo-app # Name of Deployment spec: minReadySeconds: 60 # Number of seconds to wait after a Pod is created and its status is Ready replicas: 3 selector: matchLabels: run: neg-demo-app template: # Pod template metadata: labels: run: neg-demo-app # Labels Pods from this Deployment spec: # Pod specification; each Pod created by this Deployment has this specification containers: - image: registry.k8s.io/serve_hostname:v1.4 # Application to run in Deployment's Pods name: hostname
請將這份資訊清單儲存為 neg-demo-app.yaml
,然後執行下列指令來建立 Deployment:
kubectl apply -f neg-demo-app.yaml
建立 Service
下列資訊清單指定了 Service,其中:
- 任何具有
run: neg-demo-app
標籤的 Pod 都是這項 Service 的成員。 - Service 有一個通訊埠為 80 的 ServicePort 欄位。
cloud.google.com/neg
註解指定通訊埠 80 將與 NEG 建立關聯。選用的name
欄位會指定 NEG 的名稱為NEG_NAME
。如果省略name
欄位,系統會自動產生專屬名稱。詳情請參閱「命名 NEG」。- 每個成員 Pod 都必須有一個正在監聽 TCP 通訊埠 9376 的容器。
apiVersion: v1
kind: Service
metadata:
name: neg-demo-svc
annotations:
cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "NEG_NAME"}}}'
spec:
type: ClusterIP
selector:
run: neg-demo-app # Selects Pods labelled run: neg-demo-app
ports:
- port: 80
protocol: TCP
targetPort: 9376
將 NEG_NAME
替換為 NEG 的名稱。NEG 名稱在所屬區域中不得重複。
請將此份資訊清單儲存為 neg-demo-svc.yaml
,然後執行下列指令來建立 Service:
kubectl apply -f neg-demo-svc.yaml
建立服務後幾分鐘內,系統就會建立 NEG。
服務類型
雖然這個範例使用 ClusterIP
服務,但所有五種服務類型都支援獨立 NEG。建議使用預設類型 ClusterIP
。
命名 NEG
在 GKE 1.18.18-gke.1200 以上版本中,您可以指定 NEG 的自訂名稱,也可以讓 GKE 自動產生名稱。舊版 GKE 只支援自動產生的 NEG 名稱。
GKE 會在叢集使用的每個區域中建立一個 NEG。所有 NEG 都使用相同的名稱。
指定名稱
指定自訂 NEG 名稱可簡化設定負載平衡器的程序,因為您事先知道 NEG 的名稱和區域。自訂 NEG 名稱必須符合下列規定:
區域叢集的名稱在叢集區域中不得重複,地區叢集的名稱在地區中不得重複。
不得與任何現有 NEG 的名稱相符,且該 NEG 並非由 GKE NEG 控制器建立。
不得包含底線。
在 Service 的 cloud.google.com/neg
註解中使用 name
欄位,指定 NEG 名稱:
cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "NEG_NAME"}}}'
將 NEG_NAME
替換為 NEG 的名稱。NEG 名稱在所屬區域中不得重複。
使用自動產生的名稱
系統自動產生的 NEG 名稱保證不會重複。如要使用自動產生的名稱,請省略 name
欄位:
cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'
自動產生的名稱格式如下:
k8s1-CLUSTER_UID-NAMESPACE-SERVICE-PORT-RANDOM_HASH
將通訊埠對應至多個 NEG
服務可以監聽多個通訊埠。根據定義,NEG 只有單一 IP 位址和通訊埠。也就是說,如果您指定具有多個通訊埠的服務,系統會為每個通訊埠建立 NEG。
cloud.google.com/neg
註解的格式為:
cloud.google.com/neg: '{
"exposed_ports":{
"SERVICE_PORT_1":{},
"SERVICE_PORT_2":{},
"SERVICE_PORT_3":{},
...
}
}'
在本例中,SERVICE_PORT_N
的每個執行個體都是不同的通訊埠號碼,參照 Service 的現有服務通訊埠。針對列出的每個服務通訊埠,NEG 控制器會在叢集占用的每個區域中建立一個 NEG。
擷取 NEG 狀態
使用下列指令擷取叢集服務的狀態:
kubectl get service neg-demo-svc -o yaml
輸出結果會與下列內容相似:
cloud.google.com/neg-status: '{
"network-endpoint-groups":{
"SERVICE_PORT_1": "NEG_NAME_1",
"SERVICE_PORT_2": "NEG_NAME_2",
...
},
"zones":["ZONE_1", "ZONE_2", ...]
}
在這個輸出內容中,network-endpoint-groups
對應中的每個元素都是服務通訊埠 (例如 SERVICE_PORT_1
),以及對應的受管理 NEG 名稱 (例如 NEG_NAME_1
)。zones
清單包含每個有 NEG 的區域 (例如 ZONE_1
)。
輸出結果會與下列內容相似:
apiVersion: v1
kind: Service
metadata:
annotations:
cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'
cloud.google.com/neg-status: '{"network_endpoint_groups":{"80":"k8s1-cca197ad-default-neg-demo-app-80-4db81e02"},"zones":["ZONE_1", "ZONE_2"]}'
labels:
run: neg-demo-app
name: neg-demo-app
namespace: default
selfLink: /api/v1/namespaces/default/services/neg-demo-app
...
spec:
clusterIP: 10.0.14.252
ports:
- port: 80
protocol: TCP
targetPort: 9376
selector:
run: neg-demo-app
sessionAffinity: None
status:
loadBalancer: {}
在這個範例中,註解顯示服務通訊埠 80 會公開至名為 k8s1-cca197ad-default-neg-demo-app-80-4db81e02
的 NEG。
驗證 NEG 建立作業
建立服務後,系統會在幾分鐘內建立 NEG。如果 Pod 符合 Service 資訊清單中指定的標籤,則建立 NEG 時,其中會包含 Pod 的 IP。
有兩種方法可以確認 NEG 已建立且設定正確。在 GKE 1.18.6-gke.6400 以上版本中,自訂資源 ServiceNetworkEndpointGroup
會儲存 Service 控制器建立的 NEG 狀態資訊。在舊版中,您必須直接檢查 NEG。
ServiceNetworkEndpointGroup
資源
取得所有 ServiceNetworkEndpointGroup
資源,列出叢集中的 NEG:
kubectl get svcneg
檢查 ServiceNetworkEndpointGroup
資源的狀態,即可觀察 NEG 的狀態:
kubectl get svcneg NEG_NAME -o yaml
將 NEG_NAME
替換為要檢查的個別 NEG 名稱。
這項指令的輸出內容包含狀態區段,其中可能含有錯誤訊息。部分錯誤會以服務事件的形式回報。您可以查詢 Service 物件,進一步瞭解詳細資料:
kubectl describe service SERVICE_NAME
將 SERVICE_NAME
改為相關服務的名稱。
如要確認 NEG 控制器是否已成功同步處理 NEG,請檢查 ServiceNetworkEndpointGroup
資源的狀態欄位,確認是否有 type:Synced
條件。最近一次同步處理的時間位於 status.lastSyncTime
欄位。
ServiceNetworkEndpointGroup
資源僅適用於 GKE 1.18 以上版本。
直接檢查 NEG
列出專案中的 NEG,並檢查是否有與您建立的服務相符的 NEG,藉此確認 NEG 是否存在。 Google CloudNEG 的名稱格式如下:
k8s1-CLUSTER_UID-NAMESPACE-SERVICE-PORT-RANDOM_HASH
使用下列指令列出 NEG:
gcloud compute network-endpoint-groups list
輸出結果會與下列內容相似:
NAME LOCATION ENDPOINT_TYPE SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f ZONE_NAME GCE_VM_IP_PORT 3
這項輸出內容顯示 NEG 的 SIZE
為 3,表示有三個端點,分別對應於 Deployment 中的三個 Pod。
使用下列指令找出個別端點:
gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME
將 NEG_NAME
替換為要顯示個別端點的 NEG 名稱。
輸出內容會顯示三個端點,每個端點都有 Pod 的 IP 位址和通訊埠:
INSTANCE IP_ADDRESS PORT
gke-cluster-3-default-pool-4cc71a15-qlpf 10.12.1.43 9376
gke-cluster-3-default-pool-4cc71a15-qlpf 10.12.1.44 9376
gke-cluster-3-default-pool-4cc71a15-w9nk 10.12.2.26 9376
將外部應用程式負載平衡器附加至獨立 NEG
您可以使用 Compute Engine API,將 NEG 做為外部應用程式負載平衡器的後端。
建立防火牆規則。負載平衡器需要存取叢集端點,才能執行健康狀態檢查。這項指令會建立防火牆規則,允許存取:
gcloud compute firewall-rules create fw-allow-health-check-and-proxy \ --network=NETWORK_NAME \ --action=allow \ --direction=ingress \ --target-tags=GKE_NODE_NETWORK_TAGS \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --rules=tcp:9376
更改下列內容:
NETWORK_NAME
:叢集執行的網路。GKE_NODE_NETWORK_TAGS
:GKE 節點上的網路標記。
如果您未為節點建立自訂網路標記,GKE 會自動為您產生標記。如要查詢這些產生的標記,請執行下列指令:
gcloud compute instances describe INSTANCE_NAME
將
INSTANCE_NAME
替換為執行 GKE 節點的主機 Compute Engine VM 執行個體名稱。舉例來說,前一個章節的輸出內容會顯示 GKE 節點的執行個體名稱 (位於INSTANCE
欄中)。如果是標準叢集,您也可以執行
gcloud compute instances list
,列出專案中的所有執行個體。為負載平衡器建立全域虛擬 IP 位址:
gcloud compute addresses create hostname-server-vip \ --ip-version=IPV4 \ --global
建立健康狀態檢查。負載平衡器會使用這項資訊,偵測 NEG 內個別端點的即時狀態。
gcloud compute health-checks create http http-basic-check \ --use-serving-port
建立後端服務,指定這是全域外部應用程式負載平衡器:
gcloud compute backend-services create my-bes \ --protocol HTTP \ --health-checks http-basic-check \ --global
為負載平衡器建立網址對應和目標 Proxy。這個範例非常簡單,因為本指南使用的
serve_hostname
應用程式只有一個端點,且不含網址。gcloud compute url-maps create web-map \ --default-service my-bes
gcloud compute target-http-proxies create http-lb-proxy \ --url-map web-map
建立轉送規則。 這會建立負載平衡器。
gcloud compute forwarding-rules create http-forwarding-rule \ --address=HOSTNAME_SERVER_VIP \ --global \ --target-http-proxy=http-lb-proxy \ --ports=80
將
HOSTNAME_SERVER_VIP
替換為要用於負載平衡器的 IP 位址。如果省略--address
,GKE 會自動指派臨時 IP 位址。您也可以保留新的靜態外部 IP 位址。
Checkpoint
您目前已建立下列資源:
- 外部虛擬 IP 位址
- 轉送規則
- 防火牆規則
- 目標 HTTP Proxy
- Compute Engine 健康狀態檢查的網址對應
- 後端服務
- Compute Engine 健康狀態檢查
下圖顯示這些資源之間的關係:
這些資源合起來就是負載平衡器。在下一個步驟中,您將後端新增至負載平衡器。
這裡顯示獨立 NEG 的優點之一,就是負載平衡器和後端的生命週期完全獨立。應用程式、服務或 GKE 叢集刪除後,負載平衡器仍可繼續運作。您可以在負載平衡器中新增及移除新的 NEG 或多個 NEG,不必變更任何前端負載平衡器物件。
將後端新增至負載平衡器
使用 gcloud compute backend-services
add-backend
將 NEG 連線至負載平衡器,方法是將 NEG 新增為 my-bes
後端服務的後端:
gcloud compute backend-services add-backend my-bes \
--global \
--network-endpoint-group=NEG_NAME \
--network-endpoint-group-zone=NEG_ZONE \
--balancing-mode RATE --max-rate-per-endpoint 5
更改下列內容:
NEG_NAME
:網路端點群組的名稱。名稱是您在建立 NEG 時指定的名稱,或是系統自動產生的名稱。如果沒有為 NEG 指定名稱,請按照下列操作說明找出自動產生的名稱。NEG_ZONE
:網路端點群組所在的可用區。請參閱下列操作說明,瞭解如何找到這個值。
使用下列指令取得 NEG 的名稱和位置:
gcloud compute network-endpoint-groups list
輸出結果會與下列內容相似:
NAME LOCATION ENDPOINT_TYPE SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f ZONE_NAME GCE_VM_IP_PORT 3
在這個輸出範例中,NEG 的名稱為 k8s1-70aa83a6-default-my-service-80-c9710a6f
。
您可以將多個 NEG 新增至同一個後端服務。全域後端服務 (例如 my-bes
) 可以有不同區域的 NEG 後端,而區域後端服務必須有單一區域的後端。
驗證負載平衡器是否正常運作
有兩種方法可驗證您設定的負載平衡器是否正常運作:
- 確認健康狀態檢查設定正確無誤,且回報狀態為正常。
- 存取應用程式並驗證其回應。
驗證健康狀態檢查
確認後端服務與健康狀態檢查和網路端點群組相關聯,且個別端點健康狀態良好。
使用下列指令,確認後端服務與健康狀態檢查和網路端點群組有關聯:
gcloud compute backend-services describe my-bes --global
輸出結果會與下列內容相似:
backends:
- balancingMode: RATE
capacityScaler: 1.0
group: ... /networkEndpointGroups/k8s1-70aa83a6-default-my-service-80-c9710a6f
...
healthChecks:
- ... /healthChecks/http-basic-check
...
name: my-bes
...
接著,請檢查個別端點的健康狀態:
gcloud compute backend-services get-health my-bes --global
輸出內容的 status:
區段會與下列內容類似:
status:
healthStatus:
- healthState: HEALTHY
instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
ipAddress: 10.12.1.43
port: 50000
- healthState: HEALTHY
instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
ipAddress: 10.12.1.44
port: 50000
- healthState: HEALTHY
instance: ... gke-cluster-3-default-pool-4cc71a15-w9nk
ipAddress: 10.12.2.26
port: 50000
存取應用程式
透過負載平衡器的 IP 位址存取應用程式,確認一切運作正常。
首先,請取得負載平衡器的虛擬 IP 位址:
gcloud compute addresses describe hostname-server-vip --global | grep "address:"
輸出結果會包含 IP 位址。接著,將要求傳送至該 IP 位址 (本例中為 34.98.102.37
):
curl 34.98.102.37
serve_hostname
應用程式的回應應為 neg-demo-app
。
將內部應用程式負載平衡器附加至獨立 NEG
您可以透過 NEG,為在獨立 GKE Pod 中執行的服務設定內部應用程式負載平衡器。
設定僅限 Proxy 的子網路
僅限 Proxy 的子網路適用於負載平衡器所在區域中的所有區域性內部應用程式負載平衡器。
主控台
如果您使用的是 Google Cloud 控制台,可以等之後再建立僅限 Proxy 的子網路。
gcloud
使用 gcloud compute networks subnets create 指令,建立僅限 Proxy 的子網路。
gcloud compute networks subnets create proxy-only-subnet \
--purpose=REGIONAL_MANAGED_PROXY \
--role=ACTIVE \
--region=COMPUTE_REGION \
--network=lb-network \
--range=10.129.0.0/23
將 COMPUTE_REGION
替換為子網路的 Compute Engine。
API
使用 subnetworks.insert
方法建立僅限 Proxy 的子網路。
POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/COMPUTE_REGION/subnetworks
{
"name": "proxy-only-subnet",
"ipCidrRange": "10.129.0.0/23",
"network": "projects/PROJECT_ID/global/networks/lb-network",
"region": "projects/PROJECT_ID/regions/COMPUTE_REGION",
"purpose": "REGIONAL_MANAGED_PROXY",
"role": "ACTIVE"
}
更改下列內容:
PROJECT_ID
:您的專案 ID。COMPUTE_REGION
:子網路的 Compute Engine。
設定防火牆規則
這個範例使用以下防火牆規則:
fw-allow-ssh
:輸入規則,適用於要進行負載平衡的執行個體,可在 TCP 通訊埠 22 上允許來自任何位址的連入 SSH 連線。您可以為這項規則選擇較嚴格的來源 IP 範圍。舉例來說,您可以僅指定要從中啟動 SSH 工作階段的系統 IP 範圍。這個範例會使用目標標記allow-ssh
來辨識套用防火牆規則的 VM。fw-allow-health-check
:輸入規則,適用於要進行負載平衡的執行個體,可允許來自 Google Cloud健康狀態檢查系統 (位於130.211.0.0/22
和35.191.0.0/16
) 的所有 TCP 流量。這個範例會使用目標標記load-balanced-backend
來辨識應套用此規則的執行個體。fw-allow-proxies
:輸入規則,適用於要進行負載平衡的執行個體,可在9376
通訊埠上允許來自內部 HTTP(S) 負載平衡器代管 Proxy 的 TCP 流量。這個範例會使用目標標記load-balanced-backend
來辨識應套用此規則的執行個體。
如果沒有這些防火牆規則,預設拒絕輸入規則將會封鎖傳入至後端執行個體的流量。
主控台
前往 Google Cloud 控制台的「Firewall policies」(防火牆政策) 頁面。
按一下「建立防火牆規則」
,建立允許連入 SSH 連線的規則:- Name (名稱):
fw-allow-ssh
- Network (網路):
lb-network
- 「Direction of traffic」(流量方向):[ingress] (輸入)
- 「Action on match」(相符時執行的動作):[allow] (允許)
- 「Target」(目標):指定的目標標記
- 「Target tags」(目標標記):
allow-ssh
- Source filter (來源篩選器):
IPv4 ranges
- Source IPv4 ranges (來源 IPv4 範圍):
0.0.0.0/0
- 通訊協定和通訊埠:
- 選取「指定的通訊協定和通訊埠」。
- 選取
tcp
核取方塊,並指定通訊埠22
。
- Name (名稱):
點選「建立」。
再次按一下「Create firewall rule」(建立防火牆規則)
,以建立允許Google Cloud 健康狀態檢查的規則:- Name (名稱):
fw-allow-health-check
- Network (網路):
lb-network
- 「Direction of traffic」(流量方向):[ingress] (輸入)
- 「Action on match」(相符時執行的動作):[allow] (允許)
- 「Target」(目標):指定的目標標記
- 「Target tags」(目標標記):
load-balanced-backend
- Source filter (來源篩選器):
IPv4 ranges
- Source IPv4 ranges (來源 IPv4 範圍):
130.211.0.0/22
和35.191.0.0/16
- 通訊協定和通訊埠:
- 選取「指定的通訊協定和通訊埠」
- 選取
tcp
核取方塊,並指定通訊埠80
。 最佳做法是將這項規則限制為僅適用於與健康狀態檢查所用通訊協定和通訊埠相符的項目。如果您將通訊協定和通訊埠指定為tcp:80
, Google Cloud 可以使用 HTTP,透過通訊埠 80 來與您的 VM 聯絡,但卻無法使用 HTTPS 透過通訊埠 443 聯絡這些 VM。
- Name (名稱):
點選「建立」。
再次按一下「建立防火牆規則」
,建立允許負載平衡器 Proxy 伺服器連結後端的規則:- Name (名稱):
fw-allow-proxies
- Network (網路):
lb-network
- 「Direction of traffic」(流量方向):[ingress] (輸入)
- 「Action on match」(相符時執行的動作):[allow] (允許)
- 「Target」(目標):指定的目標標記
- 「Target tags」(目標標記):
load-balanced-backend
- Source filter (來源篩選器):
IPv4 ranges
- Source IPv4 ranges (來源 IPv4 範圍):
10.129.0.0/23
- 通訊協定和通訊埠:
- 選取「指定的通訊協定和通訊埠」。
- 選取
tcp
核取方塊,並指定通訊埠9376
。
- Name (名稱):
點選「建立」。
gcloud
建立
fw-allow-ssh
防火牆規則,允許與具有allow-ssh
網路標記的 VM 建立 SSH 連線。若省略source-ranges
,Google Cloud 會將規則解讀為任何來源。gcloud compute firewall-rules create fw-allow-ssh \ --network=lb-network \ --action=allow \ --direction=ingress \ --target-tags=allow-ssh \ --rules=tcp:22
建立
fw-allow-health-check
規則,允許 Google Cloud健康狀態檢查。這個範例可允許來自健康狀態檢查探測器的所有 TCP 流量,但您可以根據自己的需求設定一組較少的通訊埠。gcloud compute firewall-rules create fw-allow-health-check \ --network=lb-network \ --action=allow \ --direction=ingress \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=load-balanced-backend \ --rules=tcp
建立
fw-allow-proxies
規則,允許內部 HTTP(S) 負載平衡器的 Proxy 連線至後端。gcloud compute firewall-rules create fw-allow-proxies \ --network=lb-network \ --action=allow \ --direction=ingress \ --source-ranges=10.129.0.0/23 \ --target-tags=load-balanced-backend \ --rules=tcp:9376
API
對 firewalls.insert
方法發出 POST
要求,建立 fw-allow-ssh
防火牆規則。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls
{
"name": "fw-allow-ssh",
"network": "projects/PROJECT_ID/global/networks/lb-network",
"sourceRanges": [
"0.0.0.0/0"
],
"targetTags": [
"allow-ssh"
],
"allowed": [
{
"IPProtocol": "tcp",
"ports": [
"22"
]
}
],
"direction": "INGRESS"
}
將 PROJECT_ID
替換為您的專案 ID。
對 firewalls.insert
方法發出 POST
要求,建立 fw-allow-health-check
防火牆規則。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls
{
"name": "fw-allow-health-check",
"network": "projects/PROJECT_ID/global/networks/lb-network",
"sourceRanges": [
"130.211.0.0/22",
"35.191.0.0/16"
],
"targetTags": [
"load-balanced-backend"
],
"allowed": [
{
"IPProtocol": "tcp"
}
],
"direction": "INGRESS"
}
建立 fw-allow-proxies
防火牆規則,允許在 Proxy 子網路內傳輸 TCP 流量。方法為 firewalls.insert
。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls
{
"name": "fw-allow-proxies",
"network": "projects/PROJECT_ID/global/networks/lb-network",
"sourceRanges": [
"10.129.0.0/23"
],
"targetTags": [
"load-balanced-backend"
],
"allowed": [
{
"IPProtocol": "tcp",
"ports": [
"9376"
]
}
],
"direction": "INGRESS"
}
將 PROJECT_ID
替換為您的專案 ID。
設定負載平衡器
轉送規則的 IP 位址請使用後端子網路。如果您嘗試使用僅限 Proxy 的子網路,轉送規則建立作業就會失敗。
主控台
選擇負載平衡器類型
- 前往 Google Cloud 控制台的「Create a load balancer」(建立負載平衡器) 頁面。 前往「Create a load balancer」(建立負載平衡器)
- 在「HTTP(S) 負載平衡」下方,按一下「開始設定」。
- 選擇 [Only between my VMs] (僅在我的 VM 之間),這項設定代表使用內部的負載平衡器。
- 按一下「繼續」。
準備負載平衡器
- 在負載平衡器的「Name」(名稱) 中輸入
l7-ilb-gke-map
。 - 在「Region」(區域) 部分,選取您建立子網路的區域。
- 在「Network」(網路) 中選取
lb-network
。
保留僅限 Proxy 子網路
保留僅限 Proxy 的子網路:
- 按一下 [Reserve a Subnet] (保留子網路)。
- 在「Name」中輸入
proxy-only-subnet
。 - 在「IP address range」(IP 位址範圍) 中,輸入
10.129.0.0/23
。 - 按一下「新增」。
設定後端服務
- 按一下 [Backend configuration] (後端設定)。
- 在「Create or select backend services」(建立或選取後端服務) 選單中,選取 [Create a backend service] (建立後端服務)。
- 將後端服務的「Name」(名稱) 設為
l7-ilb-gke-backend-service
。 - 在「Backend type」(後端類型) 下方,選取「Network endpoint groups」(網路端點群組)。
- 在「Backends」(後端) 部分的「New backend」(新後端) 資訊卡中:
- 將「Network endpoint group」(網路端點群組) 設為 GKE 所建立的 NEG。如要取得 NEG 名稱,請參閱「驗證 NEG 建立作業」。
- 在「Maximum RPS」(每秒要求數上限) 中,指定每個端點的最高速率:
5
RPS。如有需要,Google Cloud 將超出這個上限。 - 按一下 [完成]。
- 在「健康狀態檢查」下拉式清單中,選取「建立健康狀態檢查」,然後指定下列參數:
- Name (名稱):
l7-ilb-gke-basic-check
- 「通訊協定」:HTTP
- 通訊埠規格:服務通訊埠
- 按一下 [Save and Continue] (儲存並繼續)。
- Name (名稱):
- 按一下 [Create] (建立)。
設定網址對應
- 按一下「轉送規則」。確認「l7-ilb-gke-backend-service」l7-ilb-gke-backend-service是任何不相符主機和路徑的唯一後端服務。
設定前端
按一下「前端設定」,然後執行下列步驟:
HTTP:
- 按一下「前端設定」。
- 按一下 [Add frontend IP and port] (新增前端 IP 和通訊埠)。
- 將「Name」(名稱) 設為「l7-ilb-gke-forwarding-rule」l7-ilb-gke-forwarding-rule。
- 將「Protocol」(通訊協定) 設為「HTTP」。
- 將「Subnetwork」(子網路) 設為「backend-subnet」。
- 在「Internal IP」(內部 IP) 下方,選取「預約靜態內部 IP 位址」。
- 在顯示的面板中提供下列詳細資料:
- Name (名稱):
l7-ilb-gke-ip
- 在「Static IP address」(靜態 IP 位址) 區段中,選取「Let me choose」(自行選擇)。
- 在「Custom IP address」(自訂 IP 位址) 區段中,輸入
10.1.2.199
。 - 按一下「保留」。
- Name (名稱):
- 將「Port」(通訊埠) 設為
80
。 - 按一下 [完成]。
HTTPS:
如果您在用戶端與負載平衡器間使用的是 HTTPS,則需要有一個或多個 SSL 憑證資源才能設定 Proxy。如要瞭解如何建立 SSL 憑證資源,請參閱「SSL 憑證」。內部 HTTP(S) 負載平衡器不支援 Google 管理的憑證。
- 按一下「前端設定」。
- 按一下 [Add frontend IP and port] (新增前端 IP 和通訊埠)。
- 在「Name」(名稱) 欄位中輸入
l7-ilb-gke-forwarding-rule
。 - 在「Protocol」(通訊協定) 欄位中,選取「
HTTPS (includes HTTP/2)
」。 - 將「Subnet」(子網路) 設為「backend-subnet」。
- 在「Internal IP」(內部 IP) 下方,選取「預約靜態內部 IP 位址」。
- 在顯示的面板中提供下列詳細資料:
- Name (名稱):
l7-ilb-gke-ip
- 在「Static IP address」(靜態 IP 位址) 區段中,選取「Let me choose」(自行選擇)。
- 在「Custom IP address」(自訂 IP 位址) 區段中,輸入
10.1.2.199
。 - 按一下「保留」。
- Name (名稱):
- 確認「Port」(通訊埠) 已設為
443
,以允許 HTTPS 流量。 - 按一下「憑證」下拉式清單。
- 如果您已擁有自行管理的 SSL 憑證資源,且想要做為主要 SSL 憑證使用,請在下拉式選單中選取所需資源。
- 否則,請選取「建立新憑證」。
- 填寫
l7-ilb-cert
的「名稱」。 - 將 PEM 格式的檔案上傳至相對應的欄位:
- 公用金鑰憑證
- 憑證鏈結
- 私密金鑰
- 點選「建立」。
- 填寫
- 如要新增主要 SSL 憑證資源以外的憑證資源,請按照下列指示操作:
- 按一下「新增憑證」。
- 從「Certificates」(憑證) 清單中選取所需憑證,或是按一下「Create a new certificate」(建立新憑證) 並按照指示操作。
- 按一下 [完成]。
完成設定程序
點選「建立」。
gcloud
使用 gcloud compute health-checks create http 指令定義 HTTP 健康狀態檢查。
gcloud compute health-checks create http l7-ilb-gke-basic-check \ --region=COMPUTE_REGION \ --use-serving-port
使用 gcloud compute backend-services create 指令定義後端服務。
gcloud compute backend-services create l7-ilb-gke-backend-service \ --load-balancing-scheme=INTERNAL_MANAGED \ --protocol=HTTP \ --health-checks=l7-ilb-gke-basic-check \ --health-checks-region=COMPUTE_REGION \ --region=COMPUTE_REGION
設定
DEPLOYMENT_NAME
變數:export DEPLOYMENT_NAME=NEG_NAME
將
NEG_NAME
替換為 NEG 的名稱。使用 gcloud compute backend-services add-backend 指令,將 NEG 後端新增至後端服務。
gcloud compute backend-services add-backend l7-ilb-gke-backend-service \ --network-endpoint-group=$DEPLOYMENT_NAME \ --network-endpoint-group-zone=COMPUTE_ZONE-b \ --region=COMPUTE_REGION \ --balancing-mode=RATE \ --max-rate-per-endpoint=5
使用 gcloud compute url-maps create 指令建立網址對應。
gcloud compute url-maps create l7-ilb-gke-map \ --default-service=l7-ilb-gke-backend-service \ --region=COMPUTE_REGION
建立目標 Proxy。
HTTP:
使用 gcloud compute target-http-proxies create 指令。
gcloud compute target-http-proxies create l7-ilb-gke-proxy \ --url-map=l7-ilb-gke-map \ --url-map-region=COMPUTE_REGION \ --region=COMPUTE_REGION
HTTPS:
如要瞭解如何建立 SSL 憑證資源,請參閱「SSL 憑證」。內部 HTTP(S) 負載平衡器不支援 Google 管理的憑證。
將檔案路徑指派給變數名稱。
export LB_CERT=PATH_TO_PEM_FORMATTED_FILE
export LB_PRIVATE_KEY=PATH_TO_PEM_FORMATTED_FILE
使用 gcloud compute ssl-certificates create 指令建立地區 SSL 憑證。
gcloud compute ssl-certificates create
gcloud compute ssl-certificates create l7-ilb-cert \ --certificate=$LB_CERT \ --private-key=$LB_PRIVATE_KEY \ --region=COMPUTE_REGION
使用 gcloud compute target-https-proxies create 指令,透過地區 SSL 憑證建立目標 Proxy。
gcloud compute target-https-proxies create l7-ilb-gke-proxy \ --url-map=l7-ilb-gke-map \ --region=COMPUTE_REGION \ --ssl-certificates=l7-ilb-cert
建立轉寄規則。
如果是自訂網路,您必須參照轉送規則中的子網路。請注意,這是 VM 子網路,而不是 Proxy 子網路。
HTTP:
使用 gcloud compute forwarding-rules create 指令,並搭配正確的標記。
gcloud compute forwarding-rules create l7-ilb-gke-forwarding-rule \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=backend-subnet \ --address=10.1.2.199 \ --ports=80 \ --region=COMPUTE_REGION \ --target-http-proxy=l7-ilb-gke-proxy \ --target-http-proxy-region=COMPUTE_REGION
HTTPS:
使用 gcloud compute forwarding-rules create 指令,並搭配正確的旗標。
gcloud compute forwarding-rules create l7-ilb-gke-forwarding-rule \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=backend-subnet \ --address=10.1.2.199 \ --ports=443 \ --region=COMPUTE_REGION \ --target-https-proxy=l7-ilb-gke-proxy \ --target-https-proxy-region=COMPUTE_REGION
API
對 regionHealthChecks.insert
方法發出 POST
要求,建立健康狀態檢查。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/healthChecks
{
"name": "l7-ilb-gke-basic-check",
"type": "HTTP",
"httpHealthCheck": {
"portSpecification": "USE_SERVING_PORT"
}
}
將 PROJECT_ID
替換為專案 ID。
對 regionBackendServices.insert
方法發出 POST
要求,建立區域後端服務。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/backendServices
{
"name": "l7-ilb-gke-backend-service",
"backends": [
{
"group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/COMPUTE_ZONE/networkEndpointGroups/NEG_NAME",
"balancingMode": "RATE",
"maxRatePerEndpoint": 5
}
],
"healthChecks": [
"projects/PROJECT_ID/regions/COMPUTE_REGION/healthChecks/l7-ilb-gke-basic-check"
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}
更改下列內容:
PROJECT_ID
:專案 ID。NEG_NAME
:NEG 的名稱。
對 regionUrlMaps.insert
方法發出 POST
要求,建立網址對應。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/urlMaps
{
"name": "l7-ilb-gke-map",
"defaultService": "projects/PROJECT_ID/regions/COMPUTE_REGION/backendServices/l7-ilb-gke-backend-service"
}
將 PROJECT_ID
替換為專案 ID。
對 regionTargetHttpProxies.insert
方法發出 POST
要求,建立目標 HTTP Proxy。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/targetHttpProxy
{
"name": "l7-ilb-gke-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-gke-map",
"region": "COMPUTE_REGION"
}
將 PROJECT_ID
替換為專案 ID。
對 forwardingRules.insert
方法發出 POST
要求,建立轉送規則。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/forwardingRules
{
"name": "l7-ilb-gke-forwarding-rule",
"IPAddress": "10.1.2.199",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/regions/COMPUTE_REGION/targetHttpProxies/l7-ilb-gke-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/COMPUTE_REGION/subnetworks/backend-subnet",
"network": "projects/PROJECT_ID/global/networks/lb-network",
"networkTier": "PREMIUM",
}
將 PROJECT_ID
替換為專案 ID。
測試
在區域中建立 VM 執行個體來測試連線:
gcloud compute instances create l7-ilb-client \
--image-family=debian-9 \
--image-project=debian-cloud \
--zone=COMPUTE_ZONE \
--network=lb-network \
--subnet=backend-subnet \
--tags=l7-ilb-client,allow-ssh
登入用戶端執行個體,確認後端的 HTTP(S) 服務可透過內部應用程式負載平衡器的轉送規則 IP 位址連線,且流量可在 NEG 中的各個端點之間達到負載平衡。
使用 SSH 連線至每個用戶端執行個體:
gcloud compute ssh l7-ilb-client \
--zone=COMPUTE_ZONE-b
驗證 IP 是否提供主機名稱:
curl 10.1.2.199
如要測試 HTTPS,請執行下列指令:
curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443
-k
標記會導致 curl
略過憑證驗證。
執行 100 個要求,並確認它們可達到負載平衡。
HTTP:
{
RESULTS=
for i in {1..100}
do
RESULTS="$RESULTS:$(curl --silent 10.1.2.199)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.199: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}
HTTPS:
{
RESULTS=
for i in {1..100}
do
RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443
)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.199: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}
將外部 Proxy 網路負載平衡器附加至獨立 NEG
您可以使用獨立 NEG,透過外部 Proxy 網路負載平衡器直接對容器進行負載平衡,Kubernetes 或 GKE 原生不支援這項功能。Proxy 網路負載平衡器僅適用於 TCP 流量,無論是否使用 SSL 皆可。如果是 HTTP(S) 流量,建議改用應用程式負載平衡器。
建立防火牆規則,允許健康狀態檢查。
負載平衡器必須存取叢集端點,才能執行健康狀態檢查。下列指令會建立防火牆規則,允許存取:
gcloud compute firewall-rules create allow-tcp-lb-and-health \ --network=NETWORK_NAME \ --target-tags=GKE_NODE_NETWORK_TAGS \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --allow tcp:9376
更改下列內容:
NETWORK_NAME
:叢集執行的網路。GKE_NODE_NETWORK_TAGS
:GKE 節點上的網路標記。
如果您未為節點建立自訂網路標記,GKE 會自動為您產生標記。如要查詢這些產生的標記,請執行下列指令:
gcloud compute instances describe INSTANCE_NAME
將
INSTANCE_NAME
替換為執行 GKE 節點的主機 Compute Engine VM 執行個體名稱。舉例來說,「直接檢查 NEG」一節中的輸出內容,會顯示 GKE 節點的INSTANCE
欄位中的執行個體名稱。如果是標準叢集,您也可以執行
gcloud compute instances list
,列出專案中的所有執行個體。如果是 Autopilot 叢集,請指定叢集服務帳戶,而非網路標記。
將
--target-tags=GKE_NODE_NETWORK_TAGS
旗標替換為--target-service-accounts=SERVICE_ACCOUNT_EMAIL
。建議您為叢集使用自訂的僅具備必要權限服務帳戶。為負載平衡器建立全域虛擬 IP 位址:
gcloud compute addresses create tcp-lb-static-ipv4 \ --ip-version=IPV4 \ --global
定義後端端點的健康狀態檢查。
負載平衡器會使用健康狀態檢查,偵測 NEG 內個別端點的即時狀態。
gcloud compute health-checks create tcp my-tcp-health-check \ --use-serving-port
建立具有工作階段相依性的後端服務。
這個後端服務會指定這是具有
CLIENT_IP
工作階段親和性的外部 Proxy 網路負載平衡器:gcloud compute backend-services create my-tcp-lb \ --load-balancing-scheme EXTERNAL_MANAGED \ --global-health-checks \ --global \ --protocol TCP \ --health-checks my-tcp-health-check \ --timeout 5m \ --session-affinity=CLIENT_IP
為負載平衡器建立目標 TCP Proxy。
如要啟用 Proxy 標頭,請將其設為
PROXY_V1
(而非NONE
)。gcloud beta compute target-tcp-proxies create my-tcp-lb-target-proxy \ --backend-service my-tcp-lb \ --proxy-header NONE
建立轉送規則,以便轉送流量。
這項轉送規則會建立負載平衡器。
gcloud compute forwarding-rules create my-tcp-lb-ipv4-forwarding-rule \ --load-balancing-scheme EXTERNAL_MANAGED \ --global \ --target-tcp-proxy my-tcp-lb-target-proxy \ --address tcp-lb-static-ipv4 \ --ports 80
確認負載平衡器資源建立作業
您已建立下列資源:
- 外部虛擬 IP 位址
- 轉送規則
- 防火牆規則
- 目標 Proxy
- 後端服務
- Compute Engine 健康狀態檢查
外部虛擬 IP 位址會連線至轉送規則,將防火牆規則允許的流量導向目標 Proxy。目標 Proxy 接著會與後端服務通訊,後者會定期接受健康狀態檢查。這些資源之間的關係如下圖所示:
這些資源合起來就是負載平衡器。在下一個步驟中,您將後端新增至負載平衡器。
這裡展示的獨立 NEG 優點之一,就是負載平衡器和後端的生命週期完全獨立。應用程式、服務或 GKE 叢集刪除後,負載平衡器仍可繼續運作。您可以在負載平衡器中新增及移除新的 NEG 或多個 NEG,不必變更任何前端負載平衡器物件。
將獨立 NEG 新增至負載平衡器,以做為後端使用
使用 gcloud compute backend-services
add-backend
將 NEG 連接至負載平衡器,方法是將 NEG 新增為 my-tcp-lb
後端服務的後端:
gcloud compute backend-services add-backend my-tcp-lb \
--global \
--network-endpoint-group=NEG_NAME \
--network-endpoint-group-zone=NEG_ZONE \
--balancing-mode CONNECTION \
--max-connections 100
更改下列內容:
NEG_NAME
:網路端點群組的名稱。名稱是您在建立 NEG 時指定的名稱,或是系統自動產生的名稱。如果沒有為 NEG 指定名稱,請按照下列操作說明找出自動產生的名稱。NEG_ZONE
:網路端點群組所在的可用區。請參閱下列操作說明,瞭解如何找到這個值。
如要取得 NEG 的名稱和位置,請使用下列指令:
gcloud compute network-endpoint-groups list
輸出結果會與下列內容相似:
NAME: k8s1-65a95e90-default-neg-demo-svc-80-663a85e4
LOCATION: us-central1-a
ENDPOINT_TYPE: GCE_VM_IP_PORT
SIZE: 3
在本範例輸出中,NEG 名稱為 kk8s1-65a95e90-default-neg-demo-svc-80-663a85e4
,區域為 us-central1-a
。
您可以將多個 NEG 新增至同一個後端服務。全域後端服務 (例如 my-tcp-lb
) 可以有不同區域的 NEG 後端,而區域後端服務必須有單一區域的後端。
驗證負載平衡器設定和連線
有兩種方法可驗證您設定的負載平衡器是否正常運作:
- 確認健康狀態檢查設定正確無誤,且回報為正常。
- 存取應用程式並驗證其回應。
驗證健康狀態檢查
確認後端服務與健康狀態檢查和網路端點群組相關聯,且個別端點健康狀態良好。
如要確認後端服務與健康狀態檢查和網路端點群組有關聯,請使用下列指令:
gcloud compute backend-services describe my-tcp-lb --global
輸出結果會與下列內容相似:
backends:
- balancingMode: CONNECTION
group: ... /networkEndpointGroups/k8s1-65a95e90-default-neg-demo-svc-80-663a85e4
maxConnections: 100
...
healthChecks:
- ... /healthChecks/my-tcp-health-check
...
name: my-tcp-lb
...
接著,請檢查個別端點的健康狀態:
gcloud compute backend-services get-health my-tcp-lb --global
輸出內容的 status:
區段會與下列內容類似:
status:
healthStatus:
- healthState: HEALTHY
instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
ipAddress: 10.12.1.43
port: 50000
- healthState: HEALTHY
instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
ipAddress: 10.12.1.44
port: 50000
- healthState: HEALTHY
instance: ... gke-cluster-3-default-pool-4cc71a15-w9nk
ipAddress: 10.12.2.26
port: 50000
確認應用程式連線
如要確認負載平衡器運作正常,請透過負載平衡器的外部 IP 位址存取應用程式。
取得負載平衡器的外部 IP 位址:
如要擷取為負載平衡器保留的外部 IP 位址,請使用下列指令:
gcloud compute addresses describe tcp-lb-static-ipv4 --global | grep "address:"
這個指令會輸出 IP 位址。
傳送要求至 IP 位址:
使用
curl
指令將要求傳送至外部 IP 位址。curl EXTERNAL_IP_ADDRESS
將
EXTERNAL_IP_ADDRESS
替換為在上個步驟中取得的 IP 位址:serve_hostname
應用程式的回應開頭應為neg-demo-app
。
實作異質服務 (VM 和容器)
負載平衡器可做為混合式 Kubernetes 和非 Kubernetes 工作負載的前端。這可能是從 VM 遷移至容器的過程,也可能是可從共用負載平衡器獲益的永久架構。如要達成這個目標,請建立以不同類型後端 (包括獨立 NEG) 為目標的負載平衡器。
同一後端服務中的 VM 和容器
本範例說明如何建立指向現有 VM 的 NEG,該 VM 正在執行工作負載,以及如何將這個 NEG 新增為現有 backendService
的另一個後端。這樣一來,單一負載平衡器就能在 VM 和 GKE 容器之間平衡負載。
這個範例會擴充上一個範例,使用外部 HTTP 負載平衡器。
由於所有端點都是依據相同的 backendService
分組,因此 VM 和容器端點會視為同一項服務。也就是說,主機或路徑比對會根據網址對應規則,將所有後端視為相同。
當您使用 NEG 做為後端服務的後端時,該後端服務中的其他所有後端也必須是 NEG。您無法在同一個後端服務中,同時使用執行個體群組和 NEG 做為後端。此外,容器和 VM 無法以端點的形式存在於同一個 NEG 中,因此必須一律使用不同的 NEG 進行設定。
使用下列指令將 VM 部署至 Compute Engine:
gcloud compute instances create vm1 \ --zone=COMPUTE_ZONE \ --network=NETWORK \ --subnet=SUBNET \ --image-project=cos-cloud \ --image-family=cos-stable --tags=vm-neg-tag
更改下列內容:
COMPUTE_ZONE
:可用區名稱。NETWORK
:網路名稱。SUBNET
:與網路相關聯的子網路名稱。
將應用程式部署至 VM:
gcloud compute ssh vm1 \ --zone=COMPUTE_ZONE \ --command="docker run -d --rm --network=host registry.k8s.io/serve_hostname:v1.4 && sudo iptables -P INPUT ACCEPT"
這個指令會將先前範例中使用的相同範例應用程式部署至 VM。為求簡單,應用程式會以 Docker 容器形式執行,但這並非必要。您必須使用
iptables
指令,才能允許防火牆存取正在執行的容器。確認應用程式正在通訊埠 9376 上提供服務,並回報應用程式在 vm1 上執行:
gcloud compute ssh vm1 \ --zone=COMPUTE_ZONE \ --command="curl -s localhost:9376"
伺服器應會傳回
vm1
。建立要搭配 VM 端點使用的 NEG。容器和 VM 都可以是 NEG 端點,但單一 NEG 無法同時擁有 VM 和容器端點。
gcloud compute network-endpoint-groups create vm-neg \ --subnet=SUBNET \ --zone=COMPUTE_ZONE
將 VM 端點連結至 NEG:
gcloud compute network-endpoint-groups update vm-neg \ --zone=COMPUTE_ZONE \ --add-endpoint="instance=vm1,ip=VM_PRIMARY_IP,port=9376"
將
VM_PRIMARY_IP
替換為 VM 的主要 IP 位址。確認 NEG 具有 VM 端點:
gcloud compute network-endpoint-groups list-network-endpoints vm-neg \ --zone COMPUTE_ZONE
使用新增容器後端時所用的相同指令,將 NEG 附加至後端服務:
gcloud compute backend-services add-backend my-bes --global \ --network-endpoint-group vm-neg \ --network-endpoint-group-zone COMPUTE_ZONE \ --balancing-mode RATE --max-rate-per-endpoint 10
開放防火牆,允許 VM 執行健康狀態檢查:
gcloud compute firewall-rules create fw-allow-health-check-to-vm1 \ --network=NETWORK \ --action=allow \ --direction=ingress \ --target-tags=vm-neg-tag \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --rules=tcp:9376
傳送測試流量,驗證負載平衡器是否將流量轉送至新的 VM1 後端和現有容器後端:
for i in `seq 1 100`; do curl ${VIP};echo; done
您應該會看到來自容器 (
neg-demo-app
) 和 VM (vm1
) 端點的回應。
不同後端服務的 VM 和容器
本例顯示如何建立指向現有 VM 的 NEG,該 VM 正在執行工作負載,以及如何將這個 NEG 新增為新 backendService
的後端。如果容器和 VM 是不同的服務,但需要共用相同的 L7 負載平衡器 (例如服務共用相同的 IP 位址或網域名稱),這項功能就非常實用。
這個範例延伸了上一個範例,該範例在同一個後端服務中,同時有 VM 後端和容器後端。這個範例會重複使用該 VM。
由於容器和 VM 端點會分組到不同的後端服務,因此會視為不同的服務。也就是說,網址對應會比對後端,並根據主機名稱將流量導向 VM 或容器。
下圖顯示單一虛擬 IP 位址如何對應至兩個主機名稱,而這兩個主機名稱又分別對應至以容器為基礎的後端服務和以 VM 為基礎的後端服務。
下圖顯示上一節所述的架構:
為 VM 建立新的後端服務:
gcloud compute backend-services create my-vm-bes \ --protocol HTTP \ --health-checks http-basic-check \ --global
將 VM 的 NEG (
vm-neg
) 附加至後端服務:gcloud compute backend-services add-backend my-vm-bes \ --global \ --network-endpoint-group vm-neg \ --network-endpoint-group-zone COMPUTE_ZONE \ --balancing-mode RATE --max-rate-per-endpoint 10
在網址對應中新增主機規則,將
container.example.com
主機的要求導向容器後端服務:gcloud compute url-maps add-path-matcher web-map \ --path-matcher-name=container-path --default-service=my-bes \ --new-hosts=container.example.com --global
在網址對應中新增另一個主機規則,將
vm.example.com
主機的要求導向至 VM 後端服務:gcloud compute url-maps add-path-matcher web-map \ --path-matcher-name=vm-path --default-service=my-vm-bes \ --new-hosts=vm.example.com --global
驗證負載平衡器是否根據要求的路徑,將流量傳送至 VM 後端:
curl -H "HOST:vm.example.com" VIRTUAL_IP
將
VIRTUAL_IP
替換為虛擬 IP 位址。
獨立 NEG 的限制
- 系統會透過 Kubernetes 事件向使用者顯示註解驗證錯誤。
- NEG 的限制也適用於獨立 NEG。
- 獨立 NEG 無法搭配舊版網路使用。
- 獨立 NEG 只能與相容的網路服務搭配使用,包括 Cloud Service Mesh 和相容的負載平衡器類型。
定價
如要瞭解負載平衡器的定價,請參閱定價頁面的負載平衡部分。使用 NEG 不須支付額外費用。
疑難排解
本節提供獨立 NEG 常見問題的疑難排解步驟。
未設定獨立 NEG
症狀:未建立 NEG。
可能的解決方法:
- 檢查與服務相關的事件,並找出錯誤訊息。
- 確認獨立 NEG 註解是格式正確的 JSON,且公開的通訊埠與服務規格中的現有通訊埠相符。
- 確認 NEG 狀態註解,並查看預期服務埠是否具有對應的 NEG。
- 使用
gcloud compute network-endpoint-groups list
指令,確認 NEG 已在預期區域中建立。 - 如果使用 GKE 1.18 以上版本,請檢查 Service 的
svcneg
資源是否存在。如有,請檢查Initialized
條件是否有任何錯誤資訊。 - 如果您使用自訂 NEG 名稱,請確保每個 NEG 名稱在所屬區域中都是專屬的。
流量無法連上端點
徵狀:502 錯誤或連線遭拒。
可能的解決方法:
- 設定服務並將端點連結到 NEG 後,若端點對健康狀態檢查有反應,流量一般即可連上新的端點。
- 如果流量在這段時間後仍無法連上端點,導致 HTTP(S) 出現 502 錯誤代碼或 TCP/SSL 負載平衡器出現連線遭拒,請檢查下列項目:
- 確認防火牆規則允許收到的 TCP 流量達到下列範圍的端點:
130.211.0.0/22
和35.191.0.0/16
。 - 使用 Google Cloud CLI 或呼叫
getHealth
API (位於backendService
上) 或 NEG 上的 listEndpoints API,並將 showHealth 參數設為SHOW
,確認端點是否正常運作。
- 確認防火牆規則允許收到的 TCP 流量達到下列範圍的端點:
停止發布
症狀:更新的 Deployment 延遲推出,且最新備用資源的數量與所選備用資源的數量不符。
可能的解決方法:
Deployment 的健康狀態檢查失敗。容器映像檔可能不正確,或是健康狀態檢查可能設定錯誤。Pod 的滾動式替換作業會等候新啟動的 Pod 傳送其 Pod 完備性門檻。只有當 Pod 在回應負載平衡器健康狀態檢查時,才會發生這種情況。如果 Pod 沒有回應,或是健康狀態檢查設定有誤,就無法達到完備性門檻,導致無法繼續發布。
如果您使用的是 kubectl 1.13 以上版本,則可以使用以下指令檢查 Pod 完備性門檻的狀態:
kubectl get my-Pod -o wide
檢查 READINESS GATES 欄。
kubectl 1.12 以下版本沒有這個資料欄。標記為處於 READY 狀態的 Pod,可能會有完備性門檻失敗的問題。如要驗證這一點,請使用下列指令:
kubectl get my-pod -o yaml
系統會在輸出結果中列出完備性門檻和其狀態。
確認 Deployment 的 Pod 規格中的容器映像檔運作正常,且能回應健康狀態檢查。
請確認健康狀態檢查設定正確無誤。
NEG 不會進行垃圾收集
症狀:應該刪除的 NEG 仍存在。
可能的解決方法:
- 如果後端服務參照 NEG,系統就不會進行垃圾收集。詳情請參閱「防止 NEG 外洩」。
- 如果使用 1.18 以上版本,可以透過服務 NEG 程序檢查
ServiceNetworkEndpointGroup
資源中的事件。 - 確認服務是否仍需要 NEG。檢查與 NEG 相對應的服務資源,並確認是否有服務註解。
svcneg
NEG 未與服務同步
症狀:預期的 (Pod IP) 端點不存在於 NEG 中、NEG 未同步處理,或發生 Failed to sync NEG_NAME (will not retry):
neg name NEG_NAME is already in use, found a custom named neg with an empty
description
錯誤
可能的解決方法:
如果您使用 GKE 1.18 以上版本,請檢查 svcneg
資源,瞭解相關資訊:
- 檢查
status.lastSyncTime
值,確認 NEG 最近是否已同步。 - 檢查「
Synced
」條件,瞭解最近一次同步處理時發生的任何錯誤。
如果您使用 GKE 1.19.9 以上版本,請檢查是否有 NEG 的名稱和區域,與 GKE NEG 控制器需要建立的 NEG 名稱和區域相符。舉例來說,您可能已在叢集的區域 (或其中一個叢集區域) 中,使用 gcloud CLI 或 Google Cloud 控制台,建立 NEG 控制器需要使用的 NEG 名稱。在這種情況下,您必須先刪除現有 NEG,NEG 控制器才能同步處理端點。獨立 NEG 的建立和成員資格,都是由 NEG 控制器管理。