排解無 Proxy gRPC 部署問題

本文件提供的資訊可協助您解決使用 Cloud Service Mesh 部署無 Proxy gRPC 服務時的設定問題。如要瞭解如何使用用戶端狀態探索服務 (CSDS) API 來協助調查 Cloud Service Mesh 的問題，請參閱「瞭解 Cloud Service Mesh 用戶端狀態」。

排解 gRPC 應用程式中的 RPC 失敗問題

在 gRPC 應用程式中，有兩種常見的方法可用於排解遠端程序呼叫 (RPC) 失敗問題：

  1. 查看 RPC 失敗時傳回的狀態。通常，狀態會包含足夠的資訊，協助您瞭解 RPC 失敗的原因。

  2. 啟用 gRPC 執行階段的記錄功能。有時候，您需要查看 gRPC 執行階段記錄，才能瞭解可能不會傳回至 RPC 傳回狀態的失敗情形。舉例來說，如果 RPC 失敗，且狀態表示已超過期限，記錄可協助您瞭解導致超出期限的潛在失敗原因。

    不同語言的 gRPC 實作方式，在 gRPC 執行階段啟用記錄的方式也不同：

    • Java 中的 gRPC：gRPC 會使用 java.util.logging 進行記錄。將 io.grpc.level 設為 FINE 等級，即可在 gRPC 執行階段啟用足夠的詳細記錄功能。在 Java 中啟用記錄功能的常用方式，是從檔案載入記錄設定，並使用指令列標記將檔案位置提供給 JVM。例如：

      # Create a file called logging.properties with the following contents:
handlers=java.util.logging.ConsoleHandler
io.grpc.level=FINE
io.grpc.xds.level=FINEST
java.util.logging.ConsoleHandler.level=ALL
java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter

# Pass the location of the file to JVM by using this command-line flag:
-Djava.util.logging.config.file=logging.properties

      如要啟用特定 xDS 模組的記錄功能，請將 io.grpc.xds.level 設為 FINE。如要查看更詳細的記錄，請將層級設為 FINER 或 FINEST。

    • Go 中的 gRPC：設定環境變數即可啟用記錄功能。

      GRPC_GO_LOG_VERBOSITY_LEVEL=99 GRPC_GO_LOG_SEVERITY_LEVEL=info

    • C++ 中的 gRPC：如要在 C++ 中啟用 gRPC 記錄功能，請參閱「gRPC 疑難排解」中的操作說明。如要啟用特定於 xDS 模組的記錄功能，請為 xds_client、xds_resolver、cds_lb、eds_lb、priority_lb、weighted_target_lb 和 lrs_lb 使用 GRPC_TRACE 環境變數，啟用下列追蹤記錄器。

    • Node.js 中的 gRPC：如要在 Node.js 中啟用 gRPC 記錄功能，請參閱「gRPC-JS 疑難排解」中的操作說明。如要啟用特定於 xDS 模組的記錄功能，請為 xds_client、xds_resolver、cds_balancer、eds_balancer、priority 和 weighted_target 使用 GRPC_TRACE 環境變數，啟用下列追蹤記錄器。

視 RPC 狀態或執行階段記錄中的錯誤而定，您的問題可能屬於下列任一類別。

無法連線至 Cloud Service Mesh

如要排解連線問題，請嘗試下列操作：

  • 確認啟動檔案中的 server_uri 值為 trafficdirector.googleapis.com:443。
  • 確認已定義環境變數 GRPC_XDS_BOOTSTRAP，且指向啟動檔案。
  • 建立 gRPC 管道時，請務必在 URI 中使用 xds 配置。
  • 請確認您已授予必要的 IAM 權限，以便在專案中建立運算執行個體和修改網路。
  • 請務必啟用服務帳戶以存取 Traffic Director API。在專案的 Google Cloud 主控台「API 與服務」下方，查看 Traffic Director API 是否有錯誤。
  • 確認服務帳戶具備正確的權限。在 VM 或 Pod 中執行的 gRPC 應用程式會使用 Compute Engine VM 主機或 Google Kubernetes Engine (GKE) 節點執行個體的服務帳戶。

  • 確認 Compute Engine VM 或 GKE 叢集的 API 存取權範圍已設為允許對 Compute Engine API 的完整存取權。如要這麼做，請在建立 VM 或叢集時指定下列項目：

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

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

無法解析 URI 中指定的主機名稱

您可能會在記錄中看到類似以下的錯誤訊息：

[Channel<1>: (xds:///my-service:12400)] Failed to resolve name. status=Status{code=UNAVAILABLE, description=NameResolver returned no usable address. addrs=[], attrs={}

如要排解主機名稱解析問題，請嘗試下列操作：

  • 請確認您使用的是支援的 gRPC 版本和語言。
  • 請確認在 URI 中用於建立 gRPC 管道的通訊埠，與設定中用於轉送規則的通訊埠值相符。如果 URI 中未指定通訊埠，系統會使用值 80 來比對轉送規則。
  • 請確認在 URI 中用於建立 gRPC 管道的網域名稱和通訊埠，與設定中使用的網址對應中的主機規則完全相符。
  • 請確認您並未在多個網址對應中設定相同的主機規則。
  • 請確認沒有使用萬用字元。系統會忽略含有 * 萬用字元字元的主機規則。

服務無法使用，因此 RPC 失敗

如要排解服務無法使用時的 RPC 失敗問題，請嘗試下列操作：

  • 您可以在 Google Cloud 主控台中查看 Cloud Service Mesh 的整體狀態，以及後端服務的狀態：

    • 在「Associated routing rule maps」欄中，確認正確的網址對應會參照後端服務。按一下資料欄，檢查主機比對規則中指定的後端服務是否正確。
    • 在「Backends」欄中，確認與後端服務相關聯的後端是否正常運作。
    • 如果後端健康狀態不良，請按一下對應的後端服務，並確認已設定正確的健康狀態檢查。健康狀態檢查通常會因防火牆規則不正確或缺少，或是 VM 和防火牆規則中指定的標記不相符而失敗。詳情請參閱「建立健康狀態檢查」。

  • 如要讓 gRPC 健康狀態檢查正常運作，gRPC 後端必須實作 gRPC 健康狀態檢查通訊協定。如果未實作此通訊協定，請改用 TCP 健康狀態檢查。請勿在 gRPC 服務中使用 HTTP、HTTPS 或 HTTP/2 健康狀態檢查。

  • 使用執行個體群組時，請確認執行個體群組中指定的已命名通訊埠與健康狀態檢查中使用的通訊埠相符。使用網路端點群組 (NEG) 時，請確認 GKE 服務規格具有正確的 NEG 註解，且健康狀態檢查已設定為使用 NEG 服務通訊埠。

  • 確認端點通訊協定已設為 GRPC。

RPC 失敗，因為負載平衡政策不受支援

您可能會在記錄中看到下列其中一則錯誤訊息：

error parsing "CDS" response: resource "cloud-internal-istio:cloud_mp_248715":
unexpected lbPolicy RING_HASH in response

error={"description":"errors parsing CDS response",
"file":"external/com_github_grpc_grpc/src/core/ext/xds/xds_api.cc", "file_line":3304,
"referenced_errors":[{"description":"cloud-internal-istio:cloud_mp_248715: LB policy is not supported."

WARNING: RPC failed: Status{code=INTERNAL, description=Panic! This is a bug!, cause=java.lang.NullPointerException: provider
at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:910)
at io.grpc.internal.ServiceConfigUtil$PolicySelection.<init>(ServiceConfigUtil.java:418)
at io.grpc.xds.CdsLoadBalancer2$CdsLbState.handleClusterDiscovered(CdsLoadBalancer2.java:190)

這是因為所使用的用戶端的特定語言和版本不支援 RING_HASH。如要修正這個問題，請更新後端服務設定，只使用支援的負載平衡政策，或是將用戶端升級至支援的版本。如需支援的用戶端版本，請參閱 gRPC 中的 xDS 功能。

安全性設定未如預期產生

如果您正在設定服務安全性，但安全性設定未如預期產生，請檢查部署中的端點政策。

Cloud Service Mesh 不支援以下情況：有兩個以上的端點政策資源與端點相符，例如兩個具有相同標籤和連接埠的政策，或是兩個以上具有不同標籤的政策，且這些政策與端點的標籤相符。如要進一步瞭解如何將端點政策與端點的標籤進行比對，請參閱 EndpointPolicy.EndpointMatcher.MetadataLabelMatcher 的 API。在這種情況下，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 設定是否最近有異動。

後續步驟