排解 Envoy 部署問題

本指南提供相關資訊，協助您在透過 Google API 執行 Cloud Service Mesh 時，解決 Envoy 用戶端的設定問題。如要瞭解如何使用 Client Status Discovery Service (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 執行個體詳細資料」記錄頁面中，使用下列查詢檢查 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 連線至 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 Proxy 記錄。

您可以使用 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 的 API 存取權範圍已設為允許所有Google Cloud API，方法是在建立 VM 時指定下列項目：

    --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 解析問題。

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

無法連線至透過 Cloud Service Mesh 設定的服務

如果無法連線至採用 Cloud Service Mesh 設定的服務，請確認 Sidecar Proxy 正在執行，且能夠連線至 Cloud Service Mesh。

如果您使用 Envoy 做為 Sidecar Proxy，可以執行下列指令來確認：

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

    ps aux | grep envoy

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

    curl http://localhost:15000/config_dump

  3. 確認 Sidecar Proxy 的流量攔截設定正確無誤。 如要使用 iptables 設定重新導向，請執行 iptables 指令，然後 grep 輸出內容，確保規則存在：

    sudo iptables -t nat -S | grep ISTIO

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

    -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 存取記錄功能後，服務停止運作

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

如未提供必要權限，系統就不會在 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 時，會提供虛擬私有雲網路名稱 (例如 my-network)。Cloud Service Mesh 接著會尋找具有 INTERNAL_SELF_MANAGED 負載平衡配置，並參照相同虛擬私有雲網路名稱的轉送規則。

如要修正這項錯誤，請按照下列步驟操作：

  1. 確認網路中是否有負載平衡機制為 INTERNAL_SELF_MANAGED 的轉送規則。記下轉送規則的 VPC 網路名稱。

  2. 如果您使用 Cloud Service Mesh，並在 Compute Engine 上自動部署 Envoy，請確認提供給 --service-proxy:network 旗標的值與轉送規則的虛擬私有雲網路名稱相符。

  3. 如果您使用 Cloud Service Mesh，並在 Compute Engine 上手動部署 Envoy，請檢查 Envoy 啟動程序檔案是否包含下列項目：

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

  4. 如果您在 GKE 上部署，且使用自動注入器，請務必按照 [這篇文章](https://cloud.google.com/service-mesh/docs/i/service-mesh/legacy/29/legacy/load-balancing-apis/set-up-gke-pods-auto#configuring_the_sidecar_injector)的指示，正確設定專案編號和虛擬私有雲網路名稱。

排解 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 記錄

序列埠輸出內容中顯示的資料也會記錄到 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 的值。bootstrap-status 值不是 FINISHED 時，表示 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 Proxy 設定時發生問題，或是 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 Proxy。

    確認沒有其他規則會捨棄這個通訊埠的流量，或捨棄除了特定通訊埠以外的所有通訊埠流量。

  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"
  ...
]

    route_config_name (以 inbound 開頭) 表示專為攔截連入流量而建立的特殊服務。檢查您要連線的通訊埠是否已納入 destination_port 底下的接聽程式設定。

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

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

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

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

大多數端點狀況不佳時，Cloud Service Mesh 的行為

為提升穩定性，當 99% 的端點狀況不佳時，Cloud Service Mesh 會設定資料層，忽略端點的健康狀態。因此，資料層會在所有端點之間平衡流量，因為服務連接埠可能仍可運作。

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

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

後續步驟