使用手動 Envoy 插入來設定 Google Kubernetes Engine Pod

本指南說明如何設定 Google Kubernetes Engine 或 Kubernetes Pod 主機，以及 Cloud Service Mesh 要求的負載平衡元件。

按照本指南中的操作說明進行之前，請先完成「準備透過 Envoy 和無 Proxy 工作負載設定服務轉送 API」一文所述的必要工作。

您可以使用 Compute Engine 負載平衡 SDK 或 REST API 設定 Cloud Service Mesh。請參閱負載平衡 API 和 gcloud 參考資料。

設定 Cloud Service Mesh 適用的 GKE/Kubernetes 叢集

本節說明啟用 GKE/Kubernetes 叢集的必要步驟，以便與 Cloud Service Mesh 搭配使用。

建立 GKE 叢集

GKE 叢集必須符合下列要求：

  • 必須啟用網路端點群組支援功能。如需更多資訊和範例，請參閱「獨立網路端點群組」。獨立 NEG 功能現已正式推出，適用於 Cloud Service Mesh。
  • 叢集節點執行個體服務帳戶必須具有存取 Cloud Service Mesh API 的權限。
  • 容器必須具有存取 Cloud Service Mesh API 的權限，並受 OAuth 驗證保護。詳情請參閱主機設定。

下列範例示範如何在 us-central1-a 區域建立名為 traffic-director-cluster 的 GKE 叢集。

控制台

如要使用 Google Cloud 控制台建立叢集，請執行下列步驟：

  1. 前往 Google Cloud 控制台的 Kubernetes Engine 選單。

    前往 Google Kubernetes Engine 選單

  2. 點選「建立叢集」。

  3. 填寫下列欄位：

    • 名稱：輸入 traffic-director-cluster。
    • 位置類型： Zonal。
    • 區域： us-central1-a。

  4. 在導覽窗格的「節點集區」下方，按一下「default-pool」。

  5. 「大小」欄位表示要在叢集中建立的節點數量。您必須要有可用於節點及其資源 (例如防火牆路徑) 的資源配額。

  6. 在導覽窗格的「default-pool」下方，按一下「Nodes」。

  7. 「Machine type」(機型) 欄位會指出執行個體所用的 Compute Engine 機型。每種機型的計費方式不同。如需機型的定價資訊，請參閱 Compute Engine 定價頁面。

  8. 在導覽窗格的「default-pool」下方，按一下「Security」(安全性)。

  9. 在「存取權範圍」下方，按一下「允許所有 Cloud API 的完整存取權」。

  10. 視需要自訂叢集。

  11. 點選「建立」。

在 Google Cloud 主控台中建立叢集之後，您必須設定 kubectl 以與叢集互動。如要瞭解詳情，請參閱「產生 kubeconfig 項目」。

gcloud

gcloud container clusters create traffic-director-cluster \
  --zone us-central1-a \
  --scopes=https://www.googleapis.com/auth/cloud-platform \
  --enable-ip-alias

取得所需的 GKE 叢集權限

若為 GKE，請發出下列指令以切換至剛建立的叢集(2)。這會將 kubectl 指向正確的叢集。

gcloud container clusters get-credentials traffic-director-cluster \
    --zone us-central1-a

設定 GKE/Kubernetes 服務

本節說明如何準備 Kubernetes 部署規格，以搭配 Cloud Service Mesh 使用。此程序包含設定 NEG 服務，以及在需要存取 Cloud Service Mesh 管理服務的 Pod 中插入補充 Proxy。

設定防火牆規則

如要確認後端 Pod 是否正在執行，您必須設定防火牆規則，允許健康狀態檢查工具的 IP 位址範圍。

控制台

  1. 前往 Google Cloud 控制台的「Firewall policies」(防火牆政策) 頁面。
    前往「Firewall policies」(防火牆政策) 頁面
  2. 按一下「建立防火牆規則」。
  3. 在「Create a firewall rule」(建立防火牆規則) 頁面上，提供以下資訊：
    • 「Name」(名稱)：提供規則的名稱。本範例使用的是 fw-allow-health-checks。
    • 「Network」(網路)：選擇虛擬私有雲網路。
    • 「Priority」(優先順序)：輸入代表優先順序的數字。數字越小，優先順序越高。請確保該防火牆規則的優先順序，高於其他可能會拒絕輸入流量的規則。
    • 「Direction of traffic」(流量方向)：選擇 [ingress] (輸入)。
    • 「Action on match」(相符時執行的動作)：選擇 [allow] (允許)。
    • 「目標」：選擇「網路中的所有執行個體」。
    • 「來源篩選器」：選擇正確的 IP 範圍類型。
    • Source IP ranges (來源 IP 範圍)：35.191.0.0/16,130.211.0.0/22
    • 目的地篩選器：選取 IP 類型。
    • 「Protocols and ports」(通訊協定和通訊埠)：按一下「Specified ports and protocols」(指定的通訊埠和通訊協定)，然後勾選 tcp。TCP 是適用於所有健康狀態檢查通訊協定的基本通訊協定。
    • 點選「建立」。

gcloud

  1. 使用下列 gcloud 指令建立名為 fw-allow-health-checks 的防火牆規則；該規則會允許傳入的連線抵達您網路中有 allow-health-checks 標記的執行個體。請將 NETWORK_NAME 替換成您網路的名稱。

    gcloud compute firewall-rules create fw-allow-health-checks \
    --network NETWORK_NAME \
    --action ALLOW \
    --direction INGRESS \
    --source-ranges 35.191.0.0/16,130.211.0.0/22 \
    --rules tcp

詳情請參閱「設定健康狀態檢查的防火牆規則」。

設定 NEG 適用的 GKE / Kubernetes 服務

GKE 服務必須透過網路端點群組 (NEG) 公開，您才能將其設定為 Cloud Service Mesh 後端服務的後端。將 NEG 註解新增至 Kubernetes 服務規格，並選擇名稱 (取代下方範例中的 NEG-NAME)，方便日後尋找。將 NEG 附加至 Cloud Service Mesh 後端服務時，您需要這個名稱。如要進一步瞭解如何註解 NEG，請參閱「命名 NEG」。

...
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "NEG-NAME"}}}'
spec:
  ports:
  - port: 80
    name: service-test
    protocol: TCP
    targetPort: 8000

每個服務都會建立包含 Pod IP 位址和通訊埠的獨立 NEG。如需更多資訊和範例，請參閱獨立網路端點群組。

如需用於示範，您可以部署範例服務，其會透過通訊埠 80 上的 HTTP 提供本身的主機名稱：

wget -q -O - \
https://storage.googleapis.com/traffic-director/demo/trafficdirector_service_sample.yaml \
| kubectl apply -f -

確認已建立新服務主機名稱且應用程式 Pod 運作中：

kubectl get svc

這會傳回：

NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service-test     ClusterIP   10.71.9.71   none          80/TCP    41m
[..skip..]


kubectl get pods

這會傳回：

NAME                        READY     STATUS    RESTARTS   AGE
app1-6db459dcb9-zvfg2       1/1       Running   0          6m
[..skip..]

儲存 NEG 名稱

從上方範例找出建立的 NEG 並記錄下該 NEG 名稱。

控制台

如要查看網路端點群組清單，請前往 Google Cloud 控制台的「Network Endpoint Groups」(網路端點群組) 頁面。
前往「網路端點群組」頁面

gcloud

gcloud compute network-endpoint-groups list

這會傳回以下內容：

NAME                 LOCATION          ENDPOINT_TYPE      SIZE
NEG-NAME           us-central1-a     GCE_VM_IP_PORT      1

在 NEG_NAME 變數中儲存 NEG 名稱，例如：

NEG_NAME=$(gcloud compute network-endpoint-groups list \
| grep service-test | awk '{print $1}')

設定 Cloud Service Mesh 的負載平衡元件 Google Cloud

本節的操作說明可確保 GKE 服務可透過 Cloud Service Mesh 負載平衡的服務 VIP 存取，並使用與其他 Google Cloud Load Balancing 產品類似的負載平衡設定。

您必須設定下列元件：

下列 Cloud Service Mesh 設定範例會做出下列假設：

  1. NEG 和其他所有的資源都在 us-central1-a 區域中以自動模式建立在 default 網路。
  2. 叢集的 NEG 名稱儲存在 ${NEG_NAME} 變數。

建立健康狀態檢查

建立健康狀態檢查。

控制台

  1. 前往 Google Cloud 控制台的「健康狀態檢查」頁面。
    前往「Health checks」(健康狀態檢查) 頁面
  2. 按一下 [Create Health Check] (建立健康狀態檢查)。
  3. 輸入 td-gke-health-check 做為名稱。
  4. 選取 [HTTP] 做為通訊協定。
  5. 點選「建立」。

gcloud

gcloud compute health-checks create http td-gke-health-check \
  --use-serving-port

建立後端服務

使用「INTERNAL_SELF_MANAGED」INTERNAL_SELF_MANAGED負載平衡機制建立全球後端服務。在 Google Cloud 控制台中，負載平衡機制為間接設定。將健康狀態檢查新增到後端服務。

控制台

  1. 前往 Google Cloud 控制台的「Cloud Service Mesh」頁面。

    前往 Cloud Service Mesh 頁面

  2. 在「Services」(服務) 分頁中，按一下 [Create Service] (建立服務)。

  3. 按一下「繼續」。

  4. 輸入 td-gke-service 做為服務名稱。

  5. 在「Backend type」(後端類型) 下方，選取 [Network endpoint groups] (網路端點群組)。

  6. 選取您建立的網路端點群組。

  7. 將「Maximum RPS」(每秒要求數上限) 設為 5。

  8. 按一下 [完成]。

  9. 在「健康狀態檢查」下方，選取 td-gke-health-check，也就是您建立的健康狀態檢查。

  10. 按一下「繼續」。

gcloud

  1. 建立後端服務，並將健康狀態檢查與後端服務建立關聯。

    gcloud compute backend-services create td-gke-service \
 --global \
 --health-checks td-gke-health-check \
 --load-balancing-scheme INTERNAL_SELF_MANAGED

  2. 將後端 NEG 新增到後端服務。

    gcloud compute backend-services add-backend td-gke-service \
 --global \
 --network-endpoint-group ${NEG_NAME} \
 --network-endpoint-group-zone us-central1-a \
 --balancing-mode RATE \
 --max-rate-per-endpoint 5

建立轉送規則對應

請按照這些操作說明，為 Cloud Service Mesh 設定建立路由規則、轉送規則和內部 IP 位址。

傳送至內部 IP 位址的流量會由 Envoy Proxy 攔截，並根據主機和路徑規則傳送至相關的服務。

轉送規則會建立為通用轉送規則，且 load-balancing-scheme 會設為 INTERNAL_SELF_MANAGED。

您可以將轉送規則的地址設為 0.0.0.0。如果這麼做，系統會根據網址對應中設定的 HTTP 主機名稱和路徑資訊，而非主機名稱實際解析的 IP 位址，來轉送流量。在這種情況下，服務的網址 (主機名稱加上網址路徑) 必須在服務網格設定中保持不重複，也就是說，您無法讓兩個不同的服務使用相同的主機名稱和路徑組合，即使這兩個服務的後端組合不同也一樣。

或者，您也可以根據服務的實際目的地 VIP 啟用轉送功能。如果將服務的 VIP 設定為轉送規則的 address 參數，系統只會根據網址對應中指定的 HTTP 參數，轉送目的地為這個 IP 位址的要求。

控制台

在主控台中，目標 Proxy 會搭配使用轉送規則。 建立轉送規則時，系統會 Google Cloud 自動建立目標 HTTP Proxy，並將其附加至網址對應。

轉送規則包含「轉寄規則」與「主機和路徑規則」(又稱為網址對應)。

  1. 前往 Google Cloud 控制台的「Cloud Service Mesh」頁面。

    前往 Cloud Service Mesh 頁面

  2. 按一下「轉送規則對應」

  3. 按一下「建立轉送規則」。

  4. 輸入 td-gke-url-map 做為網址對應的名稱。

  5. 按一下「新增轉送規則」。

  6. 針對轉送規則名稱，請輸入 td-gke-forwarding-rule。

  7. 選取網路。

  8. 選取「內部 IP」。

  9. 按一下 [儲存]。

  10. 視需要新增自訂主機與路徑規則，或將路徑規則保留為預設值。

  11. 將主機設為 service-test。

  12. 按一下 [儲存]。

gcloud

  1. 建立使用後端服務的網址對應。

    gcloud compute url-maps create td-gke-url-map \
   --default-service td-gke-service

  2. 建立網址對應路徑比對器和主機規則，根據主機名稱和路徑轉送服務流量。這個範例使用 service-test 做為服務名稱，以及符合這個主機 (/*) 所有路徑要求的預設路徑比對器。service-test 也是上述範例設定中使用的 Kubernetes 服務設定名稱。

    gcloud compute url-maps add-path-matcher td-gke-url-map \
   --default-service td-gke-service \
   --path-matcher-name td-gke-path-matcher

    gcloud compute url-maps add-host-rule td-gke-url-map \
   --hosts service-test \
   --path-matcher-name td-gke-path-matcher

  3. 建立目標 HTTP Proxy。

    gcloud compute target-http-proxies create td-gke-proxy \
   --url-map td-gke-url-map

  4. 建立轉送規則。

    gcloud compute forwarding-rules create td-gke-forwarding-rule \
  --global \
  --load-balancing-scheme=INTERNAL_SELF_MANAGED \
  --address=0.0.0.0 \
  --target-http-proxy=td-gke-proxy \
  --ports 80 --network default

此時，Cloud Service Mesh 已設定為指定網址對應中的服務進行負載平衡，其為網路端點群組後端間的轉送規則所指定的 VIP。

視微服務在網路上的分布情形而定，您可能需要在網址對應中新增更多轉送規則，或更多主機和路徑規則。

部署範例用戶端進行測試，驗證設定

本節說明如何從用戶端應用程式連線至 Cloud Service Mesh 後端。

如要示範功能，您可以執行 Busybox 部署範例 Pod。Pod 可以存取 service-test，這是上一節建立的資源，會接收 Cloud Service Mesh 負載平衡的流量。

將 Sidecar Proxy 插入 GKE / Kubernetes Pod

如要存取 Cloud Service Mesh 管理的服務，Pod 必須安裝與 xDS API 相容的 Sidecar Proxy。

在本範例中，您會部署 Busybox 用戶端，並使用參考規格將 Istio Proxy 補充容器和 init 容器新增至部署作業。

如果您使用舊版 API，請將 PROJECT_NUMBER 和 NETWORK_NAME 變數替換為專案編號和網路名稱：

wget -q -O - https://storage.googleapis.com/traffic-director/demo/trafficdirector_client_sample_xdsv3.yaml
sed -i "s/PROJECT_NUMBER/PROJECT_NUMBER/g" trafficdirector_client_sample_xdsv3.yaml
sed -i "s/NETWORK_NAME/NETWORK_NAME/g" trafficdirector_client_sample_xdsv3.yaml
kubectl apply -f trafficdirector_client_sample_xdsv3.yaml

如果您使用目前為搶先版的全新服務路徑 API，請將 PROJECT_NUMBER 和 MESH_NAME 變數替換為專案編號和 Mesh 名稱：

wget -q -O - https://storage.googleapis.com/traffic-director/demo/trafficdirector_client_new_api_sample_xdsv3.yaml
sed -i "s/PROJECT_NUMBER/PROJECT_NUMBER/g" trafficdirector_client_new_api_sample_xdsv3.yaml
sed -i "s/MESH_NAME/MESH_NAME/g" trafficdirector_client_new_api_sample_xdsv3.yaml
kubectl apply -f trafficdirector_client_new_api_sample_xdsv3.yaml

Busybox Pod 有兩個執行容器。第一個容器是以 Busybox 映像檔為基礎的用戶端，第二個容器則是插入為 Sidecar 的 Envoy Proxy。如要取得 Pod 的詳細資訊，請執行下列指令：

kubectl describe pods -l run=client

連線至後端服務

設定完成後，在 Pod 上具有插入 Sidecar Proxy 的應用程式，即可存取 Cloud Service Mesh 服務所管理的服務。如要驗證設定，您可以在其中一個容器上存取殼層。

如果您使用了本指南中所提供的範本設定，可以執行下列驗證指令，確認服務 Pod 會傳回主機名稱。

# Get name of the Pod  with busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to execute that tests connectivity to the service service-test.
TEST_CMD="wget -q -O - service-test; echo"

# Execute the test command on the Pod .
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

瞭解 Sidecar Proxy 如何攔截流量

請注意，在本範例中，Busybox 用戶端向後端服務提出要求時，每個要求都會由 Sidecar Proxy 轉送。

這個示範應用程式使用 Envoy Proxy。因此，用戶端會在伺服器回應的標頭中看到「server: envoy」。

如要確認這一點，請使用下列指令：

# Get the name of the Pod  with Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to send a request to service-test and output server response headers.
TEST_CMD="wget -S --spider service-test; echo"

# Execute the test command on the Pod .
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

在本範例中，您使用 VIP 位址 0.0.0.0 建立轉送規則。也就是說，Cloud Service Mesh 只會根據 Host 標頭將要求轉送至後端。在這種情況下，只要要求主機標頭符合網址對應 service-test 中定義的主機，目的地 IP 位址可以是任何位址。

如要確認，請執行下列測試指令：

# Get name of the Pod  with Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to send a request to service-test setting the Host header and using a random IP address.
TEST_CMD="wget -q --header 'Host: service-test' -O - 1.2.3.4; echo"

# Execute the test command on the Pod .
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

後續步驟