排解 Envoy 部署問題

本指南提供的資訊可協助您解決使用 Google API 執行 Cloud Service Mesh 時，Envoy 用戶端的設定問題。如要瞭解如何使用用戶端狀態探索服務 (CSDS) API 來調查 Cloud Service Mesh 的問題，請參閱「瞭解 Cloud Service Mesh 用戶端狀態」。

判斷 VM 上安裝的 Envoy 版本

請按照這些操作說明，確認在虛擬機器 (VM) 執行個體上執行的是哪個版本的 Envoy。

如要驗證或檢查 Envoy 版本，請執行下列任一操作：

在路徑 gce-service-proxy/proxy-version 下檢查 VM 的訪客屬性：

  gcloud compute --project cloud-vm-mesh-monitoring instances get-guest-attributes INSTANCE_NAME 

      --zone ZONEc --query-path=gce-service-proxy/proxy-version


NAMESPACE          KEY            VALUE
  gce-service-proxy  proxy-version  dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL
  

在 Google Cloud 控制台的「VM instance details」(VM 執行個體詳細資料) 頁面中，使用以下查詢檢查 Cloud Logging 執行個體記錄：

  resource.type="gce_instance"
  resource.labels.instance_id="3633122484352464042"
  jsonPayload.message:"Envoy version"
  

您會收到類似以下的回應：

  {
    "insertId": "9zy0btf94961a",
    "jsonPayload": {
      "message": "Envoy Version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
      "localTimestamp": "2021-01-12T11:39:14.3991Z"
    },
    "resource": {
      "type": "gce_instance",
      "labels": {
        "zone": "asia-southeast1-b",
        "instance_id": "3633122484352464042",
        "project_id": "cloud-vm-mesh-monitoring"
      }
    },
    "timestamp": "2021-01-12T11:39:14.399200504Z",
    "severity": "INFO",
    "logName": "projects/cloud-vm-mesh-monitoring/logs/service-proxy-agent",
    "receiveTimestamp": "2021-01-12T11:39:15.407023427Z"
  }
  

使用 SSH 連線至 VM，並檢查二進位檔版本：

  YOUR_USER_NAME@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~$ /usr/local/bin/envoy --version


/usr/local/bin/envoy  version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL
  

使用 SSH 以 root 身分連線至 VM 和管理介面：

  root@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~# curl localhost:15000/server_info
  {
   "version": "dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
   "state": "LIVE",
   "hot_restart_version": "disabled",
   ...
  }
  

Envoy 記錄位置

如要排解某些問題，您必須檢查 Envoy 代理程式記錄。

您可以使用 SSH 連線至 VM 執行個體，取得記錄檔案。路徑可能如下所示。

  /var/log/envoy/envoy.err.log
  

Proxy 無法連線至 Cloud Service Mesh

如果 Proxy 無法連線至 Cloud Service Mesh，請執行以下操作：

• 檢查 Envoy Proxy 記錄，找出是否有任何連線至 trafficdirector.googleapis.com 的錯誤發生。

• 如果您設定 netfilter (使用 iptables) 將所有流量重新導向至 Envoy Proxy，請確認重新導向作業中已將 Proxy 執行者的使用者 (UID) 排除。否則，這樣會導致流量持續循環流回該 Proxy。

• 請確認您已為專案啟用 Cloud Service Mesh API。在專案的「API 和服務」下方，查看 Cloud Service Mesh API 的錯誤。

• 建立 VM 時，請指定下列項目，確認 VM 的 API 存取權範圍已設為允許對Google Cloud API 的完整存取權：

  --scopes=https://www.googleapis.com/auth/cloud-platform
  

• 確認服務帳戶具備正確的權限。詳情請參閱「啟用服務帳戶以存取 Traffic Director API」。

• 確認您可以從 VM 存取 trafficdirector.googleapis.com:443。如果這項存取權發生問題，可能的原因可能是防火牆阻止透過 TCP 通訊埠 443 存取 trafficdirector.googleapis.com，或是 trafficdirector.googleapis.com 主機名稱的 DNS 解析問題。

• 如果您正在使用補充 Proxy 的 Envoy，請確認 Envoy 版本在 1.24.9 或以上版本。

無法連線至採用 Cloud Service Mesh 設定的服務

如果無法存取已設定 Cloud Service Mesh 的服務，請確認附加 Proxy 是否正在執行，且能連線至 Cloud Service Mesh。

如果您使用 Envoy 做為補充 Proxy，請執行下列指令確認：

1. 在指令列中確認 Envoy 程序是否正在執行：

   ps aux | grep envoy
   

2. 檢查 Envoy 的執行階段設定，確認 Cloud Service Mesh 已設定動態資源。如要查看設定，請執行下列指令：

   curl http://localhost:15000/config_dump
   

3. 確認副車 Proxy 的流量攔截功能已正確設定。如要使用 iptables 進行重新導向設定，請執行 iptables 指令，然後 grep 輸出內容，確認規則是否存在：

   sudo iptables -t nat -S | grep ISTIO
   

   以下是 iptables 攔截虛擬 IP 位址 (VIP) 10.0.0.1/32 的輸出範例，並將其轉送至在通訊埠 15001 上以 UID 1006 執行的 Envoy 代理程式：

   -N ISTIO_IN_REDIRECT
   -N ISTIO_OUTPUT
   -N ISTIO_REDIRECT
   -A OUTPUT -p tcp -j ISTIO_OUTPUT
   -A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15001
   -A ISTIO_OUTPUT -m owner --uid-owner 1006 -j RETURN
   -A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
   -A ISTIO_OUTPUT -d 10.0.0.1/32 -j ISTIO_REDIRECT
   -A ISTIO_OUTPUT -j RETURN
   

如果 VM 執行個體是透過 Google Cloud 主控台建立，部分 IPv6 相關模組就無法在重新啟動前安裝或使用。這會導致 iptables 因為缺少依附元件而失敗。在這種情況下，請重新啟動 VM 並重新執行設定程序，這樣應可解決問題。預期中，您使用 Google Cloud CLI 建立的 Compute Engine VM 不會發生此問題。

設定 Envoy 存取記錄功能後，服務就無法連線

如果您使用 TRAFFICDIRECTOR_ACCESS_LOG_PATH 來設定 Envoy 存取記錄，如「為 Cloud Service Mesh 設定 Envoy 啟動程序屬性」一文所述，請確認執行 Envoy 代理程式的系統使用者具有寫入指定存取記錄位置的權限。

如果未提供必要權限，則無法在 Proxy 上編寫事件監聽器，您可以透過在 Envoy Proxy 記錄中檢查以下錯誤訊息來偵測：

gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected:
Error adding/updating listener(s) TRAFFICDIRECTOR_INTERCEPTION_PORT:
unable to open file '/var/log/envoy.log': Permission denied

如要解決這個問題，請變更所選檔案的權限，讓 Envoy 使用者可以寫入存取記錄。

Envoy 記錄中的錯誤訊息表示設定有問題

本節適用於使用負載平衡 API 的部署作業。

如果您在 Cloud Service Mesh 設定上遇到問題，Envoy 記錄中可能會顯示下列任一錯誤訊息：

• warning envoy config    StreamAggregatedResources gRPC config stream closed:
  5, Cloud Service Mesh configuration was not found for network "VPC_NAME" in
  project "PROJECT_NUMBER".

• warning envoy upstream  StreamLoadStats gRPC config stream closed:
  5, Cloud Service Mesh configuration was not found for network "VPC_NAME" in
  project "PROJECT_NUMBER".

• warning envoy config    StreamAggregatedResources gRPC config stream closed:
  5, Requested entity was not found.

• warning envoy upstream  StreamLoadStats gRPC config stream closed:
  5, Requested entity was not found.

• Cloud Service Mesh configuration was not found.

最後一個錯誤訊息 (Traffic Director configuration was not found) 通常表示 Envoy 正在向 Cloud Service Mesh 要求設定，但找不到相符的設定。當 Envoy 連線至 Cloud Service Mesh 時，會顯示 VPC 網路名稱 (例如 my-network)。Cloud Service Mesh 接著會尋找具有 INTERNAL_SELF_MANAGED 負載平衡配置，並參照相同 VPC 網路名稱的轉送規則。

如要修正這項錯誤，請執行下列操作：

1. 請確認網路中含有負載平衡配置 INTERNAL_SELF_MANAGED 的轉送規則。記下轉送規則的 VPC 網路名稱。

2. 如果您使用 Cloud Service Mesh 搭配Compute Engine 上的自動 Envoy 部署，請確認提供給 --service-proxy:network 標記的值與轉送規則的 VPC 網路名稱相符。

3. 如果您使用 Cloud Service Mesh 搭配 Compute Engine 上的手動 Envoy 部署，請檢查 Envoy 啟動檔中的以下項目：

   1. 請確認 TRAFFICDIRECTOR_NETWORK_NAME 變數的值與轉送規則的 VPC 網路名稱相符。
   2. 請確認專案編號已設在 TRAFFICDIRECTOR_GCP_PROJECT_NUMBER 變數中。

4. 如果您在 GKE 上部署並使用自動注入器，請按照「為 GKE Pod 設定 Cloud Service Mesh，並自動注入 Envoy」一文的說明，確認專案編號和 VPC 網路名稱已正確設定。

Compute Engine 疑難排解

本節提供 Compute Engine 適用的 Envoy 部署疑難排解操作說明。

Envoy 和 VM 引導程序以及後續的生命週期管理作業可能會因多種原因失敗，包括暫時性連線問題、不正常的存放區、引導指令碼和 VM 上代理程式中的錯誤，以及使用者未預期的動作。

疑難排解的通訊管道

Google Cloud 提供通訊管道，協助您瞭解引導程序流程，以及 VM 上元件的目前狀態。

虛擬序列埠輸出記錄

VM 的作業系統、BIOS 和其他系統層級實體通常會將輸出內容寫入序列埠。這項輸出內容可用於排解系統當機、啟動失敗、開機問題和關機問題。

Compute Engine 引導代理程式會將所有執行的動作記錄到序列埠 1。這包括系統事件，從基本套件安裝開始，透過從執行個體的中繼資料伺服器取得資料、iptables 設定和 Envoy 安裝狀態。

在 VM 上的代理程式會記錄 Envoy 程序健康狀態、新發現的 Cloud Service Mesh 服務，以及任何其他可能在調查 VM 問題時有用的資訊。

Cloud Monitoring 記錄

序列埠輸出內容中的資料也會記錄至監控功能，該功能會使用 Golang 程式庫，並將記錄匯出至個別記錄檔，以減少雜訊。由於這個記錄是執行個體層級的記錄，您可能會在同一個頁面上看到服務 Proxy 記錄和其他執行個體記錄。

VM 訪客屬性

訪客屬性是一種特定類型的自訂中繼資料，可供應用程式在執行個體上執行時寫入。執行個體上的任何應用程式或使用者都可以讀取這些訪客屬性中繼資料值，以及將資料寫入其中。

Compute Engine Envoy 啟動指令碼和 VM 上代理程式會公開屬性，其中包含啟動程序和 Envoy 目前狀態的相關資訊。所有訪客屬性都會在 gce-service-proxy 命名空間中公開：

gcloud compute instances get-guest-attributes INSTANCE_NAME  \
    --query-path=gce-service-proxy/ \
    --zone=ZONE

如果發現任何問題，建議您檢查 bootstrap-status 和 bootstrap-last-failure 屬性的值。FINISHED 以外的任何 bootstrap-status 值都表示尚未設定 Envoy 環境。bookstrap-last-failure 的值可能會指出問題所在。

無法透過使用服務 Proxy 啟用執行個體範本建立的 VM 存取 Cloud Service Mesh 服務

如要修正這個問題，請按照下列步驟操作：

1. VM 上服務 Proxy 元件的安裝作業可能尚未完成或失敗。使用下列指令判斷是否已正確安裝所有元件：

   gcloud compute instances get-guest-attributes INSTANCE_NAME \
       --query-path=gce-service-proxy/ \
       --zone=ZONE
   

   bootstrap-status 訪客屬性設為下列其中一個：

   • [none] 表示尚未開始安裝。VM 可能仍在啟動中。請過幾分鐘後再檢查狀態。
   • IN PROGRESS 表示服務 Proxy 元件的安裝和設定尚未完成。重複執行狀態檢查，查看程序是否有任何更新。
   • FAILED 表示元件的安裝或設定失敗。請查詢 gce-service-proxy/bootstrap-last-failure1 屬性，檢查錯誤訊息。
   • FINISHED 表示安裝和設定程序已完成，且未出現任何錯誤。請按照下列操作說明，確認流量攔截和 Envoy 代理伺服器的設定是否正確無誤。

2. 未正確設定 VM 上的流量攔截功能，以便支援以 Cloud Service Mesh 為基礎的服務。登入 VM 並檢查 iptables 設定：

   gcloud compute ssh INSTANCE_NAME \
       --zone=ZONE \
       sudo iptables -L -t nat
   

   檢查鏈結 SERVICE_PROXY_SERVICE_CIDRS 是否有 SERVICE_PROXY_REDIRECT 項目，例如：

   Chain SERVICE_PROXY_SERVICE_CIDRS (1 references)
   target                   prot opt source         destination ...
   SERVICE_PROXY_REDIRECT   all  --  anywhere       10.7.240.0/20
   

   每項服務的 destination 欄中都應有相符的 IP 位址或 CIDR。如果沒有虛擬 IP 位址 (VIP) 的項目，表示從 Cloud Service Mesh 填入 Envoy 代理程式設定時發生問題，或 VM 上代理程式失敗。

3. Envoy 代理程式尚未收到來自 Cloud Service Mesh 的設定。登入 VM 以檢查 Envoy Proxy 設定：

   gcloud compute ssh INSTANCE_NAME \
       --zone=ZONE \
       sudo curl localhost:15000/config_dump
   

   檢查從 Cloud Service Mesh 收到的事件監聽器設定。例如：

   "dynamic_active_listeners": [
     ...
     "filter_chains": [{
       "filter_chain_match": {
         "prefix_ranges": [{
           "address_prefix": "10.7.240.20",
           "prefix_len": 32
         }],
         "destination_port": 80
       },
     ...
       "route_config_name": "URL_MAP/PROJECT_NUMBER.td-routing-rule-1"
     ...
   ]
   

   address_prefix 是 Cloud Service Mesh 服務的虛擬 IP 位址 (VIP)。這個網址對應會指向名為 td-routing-rule-1 的網址對應。檢查要連結的服務是否已包含在事件監聽器設定中。

4. VM 上未執行代理程式。當您建立新的 Cloud Service Mesh 服務時，VM 上代理程式會自動設定流量攔截。如果代理未執行，所有傳入新服務的流量會直接傳送至 VIP，繞過 Envoy 代理，並逾時。

   1. 請執行下列指令，驗證 VM 上代理程式的狀態：

      gcloud compute instances get-guest-attributes INSTANCE_NAME \
         --query-path=gce-service-proxy/ \
         --zone=ZONE
      

   2. 檢查 VM 上代理程式的屬性。agent-heartbeat 屬性值包含服務專員上次執行動作或檢查的時間。如果這個值超過五分鐘，就表示代理程式已停止運作，您應使用下列指令重新建立 VM：

      gcloud compute instance-groups managed recreate-instance
      

   3. agent-last-failure 屬性會公開在代理程式中發生的最後一個錯誤。這可能是暫時性問題，在服務專員下次檢查時就會解決 (例如，如果錯誤是 Cannot reach the Cloud Service Mesh API server)，也可能是永久性錯誤。請稍候幾分鐘，然後重新檢查錯誤。

已將入站流量攔截設為工作負載通訊埠，但您無法從 VM 外部連線至該通訊埠

如要修正這個問題，請按照下列步驟操作：

1. VM 上服務 Proxy 元件的安裝作業可能尚未完成或失敗。使用下列指令判斷是否已正確安裝所有元件：

   gcloud compute instances get-guest-attributes INSTANCE_NAME \
       --query-path=gce-service-proxy/ \
       --zone=ZONE
   

   bootstrap-status 訪客屬性設為下列其中一個：

   • [none] 表示尚未開始安裝。VM 可能仍在啟動中。請過幾分鐘後再檢查狀態。
   • IN PROGRESS 表示服務 Proxy 元件的安裝和設定尚未完成。重複執行狀態檢查，查看程序是否有任何更新。
   • FAILED 表示元件的安裝或設定失敗。請查詢 gce-service-proxy/bootstrap-last-failure1 屬性，檢查錯誤訊息。
   • FINISHED 表示安裝和設定程序已完成，且未出現任何錯誤。請按照下列操作說明，確認流量攔截和 Envoy 代理伺服器的設定是否正確無誤。

2. 未正確設定 VM 的傳入流量攔截功能。登入 VM 並檢查 iptables 設定：

   gcloud compute ssh INSTANCE_NAME \
       --zone=ZONE \
       sudo iptables -L -t nat
   

   檢查鏈結 SERVICE_PROXY_INBOUND 是否有 SERVICE_PROXY_IN_REDIRECT 項目，例如：

   Chain SERVICE_PROXY_INBOUND (1 references)
   target                      prot opt source       destination ...
   SERVICE_PROXY_IN_REDIRECT   tcp  --  anywhere     anywhere  tcp dpt:mysql
   

   service-proxy:serving-ports 中定義的每個通訊埠，在 destination 欄中都應有對應的通訊埠。如果沒有通訊埠的項目，所有傳入流量都會直接傳送至這個通訊埠，並略過 Envoy 代理伺服器。

   確認沒有其他規則會捨棄這個連接埠的流量，或是捨棄所有連接埠 (除了特定連接埠) 的流量。

3. Envoy Proxy 尚未收到 Cloud Service Mesh 的內送通訊埠設定。登入 VM 以檢查 Envoy Proxy 設定：

   gcloud compute ssh INSTANCE_NAME \
       --zone=ZONE \
       sudo curl localhost:15000/config_dump
   

   請找出從 Cloud Service Mesh 收到的傳入事件監聽器設定：

   "dynamic_active_listeners": [
     ...
     "filter_chains": [{
       "filter_chain_match": {
         "prefix_ranges": [{
           "address_prefix": "10.0.0.1",
           "prefix_len": 32
         }],
         "destination_port": 80
       },
     ...
       "route_config_name": "inbound|default_inbound_config-80"
     ...
   ]
   

   以 inbound 開頭的 route_config_name 表示為攔截傳入流量而建立的特殊服務。檢查要連線的通訊埠是否已包含在 destination_port 底下的事件監聽器設定中。

連線使用伺服器優先通訊協定時的問題

有些應用程式 (例如 MySQL) 會使用伺服器傳送第一個封包的通訊協定。也就是說，在初始連線時，伺服器會傳送第一個位元組。Cloud Service Mesh 不支援這些通訊協定和應用程式。

排解服務網格健康狀態問題

本指南提供資訊，協助您解決 Cloud Service Mesh 設定問題。

大多數端點發生異常時的 Cloud Service Mesh 行為

為提高可靠性，當 99% 的端點處於不健康狀態時，Cloud Service Mesh 會將資料層設定為忽略端點的健康狀態。相反地，由於服務端可能仍可運作，因此資料層會在所有端點之間平衡流量。

健康狀態不良的後端導致流量分配不佳

Cloud Service Mesh 會使用附加至後端服務的 HealthCheck 資源中的資訊，評估後端的健康狀態。Cloud Service Mesh 會使用這項健康狀態，將流量轉送至最近的健康後端。如果部分後端處於不健康狀態，系統可能會繼續處理流量，但分配方式可能不盡理想。舉例來說，流量可能會流向仍有健康後端的區域，但該區域距離用戶端較遠，因此會造成延遲。如要找出並監控後端的健康狀態，請嘗試執行下列步驟：

• 在 Google Cloud 控制台中檢查後端服務的健康狀態。
  前往 Cloud Service Mesh 服務
• 請確認已啟用 HealthCheck 資源的記錄功能。
• 如果健康狀態檢查最近開始失敗，請檢查 Cloud Audit Logs，判斷 HealthCheck 設定是否最近有異動。

後續步驟

• 如要解決部署無 Proxy gRPC 服務時的設定問題，請參閱解決使用無 Proxy gRPC 的部署問題。
• 如需有關使用 Cloud Service Mesh 的其他支援資訊，請參閱取得支援。