解決 Cloud Service Mesh 中的流量管理問題

本節說明 Cloud Service Mesh 的常見問題，以及如何解決這些問題。如需其他協助，請參閱「取得支援」。

istiod 記錄中的 API 伺服器連線錯誤

如果看到類似下列內容的錯誤，表示 Istiod 無法與 apiserver 聯絡：

error k8s.io/client-go@v0.18.0/tools/cache/reflector.go:125: Failed to watch *crd.IstioSomeCustomResource`…dial tcp 10.43.240.1:443: connect: connection refused

您可以使用規則運算式字串 /error.*cannot list resource/，在記錄中找出這項錯誤。

這個錯誤通常是暫時性的，如果您使用 kubectl 存取 Proxy 記錄，問題可能已經解決。這項錯誤通常是由於事件導致 API 伺服器暫時無法使用，例如不在高可用性設定中的 API 伺服器重新啟動以進行升級或自動調度資源變更時。

istio-init 容器當機

如果 Pod iptables 規則未套用至 Pod 網路命名空間，就可能發生這個問題。可能原因如下：

  • Istio-cni 安裝作業未完成
  • 工作負載 Pod 權限不足 (缺少 CAP_NET_ADMIN 權限)

如果使用 Istio CNI 外掛程式，請確認您已完整按照操作說明進行。確認 istio-cni-node 容器已準備就緒，並檢查記錄檔。如果問題持續發生，請透過安全殼層 (SSH) 連線至主機節點，並在節點記錄中搜尋 nsenter 指令，查看是否有任何錯誤。

如果您未使用 Istio CNI 外掛程式，請確認工作負載 Pod 具有 CAP_NET_ADMIN 權限，這項權限是由 Sidecar 注入器自動設定。

Pod 啟動後連線遭拒

如果 Pod 啟動並嘗試連線至端點時發生 connection refused，問題可能是應用程式容器在 isto-proxy 容器啟動前就已啟動。在本例中，應用程式容器會將要求傳送至 istio-proxy，但由於 istio-proxy 尚未監聽該通訊埠，因此連線遭到拒絕。

這時可以：

  • 修改應用程式的啟動程式碼，持續向 istio-proxy 健康狀態端點發出要求，直到應用程式收到 200 程式碼為止。istio-proxy健康狀態端點為：

    http://localhost:15020/healthz/ready

  • 在應用程式工作負載中新增重試要求機制。

列出閘道傳回空白

症狀：成功建立 Cloud Service Mesh 閘道後，使用 kubectl get gateway --all-namespaces 列出閘道時，指令會傳回 No resources found。

在 GKE 1.20 以上版本中，GKE Gateway 控制器會自動在叢集中安裝 GKE Gateway.networking.x-k8s.io/v1alpha1 資源，因此可能會發生這個問題。如要解決這個問題，請按照下列步驟操作：

  1. 檢查叢集中是否有數個閘道自訂資源：

    kubectl api-resources | grep gateway

    輸出範例： 

    gateways                          gw           networking.istio.io/v1beta1            true         Gateway
gatewayclasses                    gc           networking.x-k8s.io/v1alpha1           false        GatewayClass
gateways                          gtw          networking.x-k8s.io/v1alpha1           true         Gateway

  2. 如果清單顯示的項目不是閘道，且含有 apiVersion networking.istio.io/v1beta1，請在 kubectl 指令中使用完整資源名稱或可區別的簡稱。舉例來說，請執行 kubectl get gw 或 kubectl get gateways.networking.istio.io，而不是 kubectl get gateway，確保系統會列出 Istio 閘道。

如要進一步瞭解這個問題，請參閱「Kubernetes 閘道和 Istio 閘道」。

Envoy Proxy 在初始化時停止回應

如果偵錯記錄檔指出 Envoy Proxy 在初始化期間停止運作，您可以使用下列指令找出導致程序停止運作的原因：

kubectl -n <ns> -c istio-proxy exec -it POD_NAME -- /usr/local/bin/pilot-agent request POST /init_dump

排解 5xx HTTP 回應錯誤

透過 Istio Ingress Gateway 存取應用程式時，可能會遇到 5xx HTTP 回應錯誤。請按照下列步驟診斷及解決問題。

  1. 找出控制層
  2. 確認潛在的設定錯誤
  3. 驗證 Pod 探索
  4. 分析存取記錄

找出控制層

判斷控制層版本和設定，因為不同版本可能會影響診斷程序。如要驗證受管理控制平面的狀態，請執行下列指令：

gcloud container fleet mesh describe --project PROJECT_ID

ACTIVE 狀態表示受管理控制層正常運作。

確認可能設定錯誤

常見的設定錯誤可能會導致轉送失敗：

  • 命名空間不符：VirtualService 必須與後端 GKE 服務位於相同命名空間。
  • 閘道參照不符：VirtualService 必須明確參照正確的 Gateway。舉例來說，如果 VirtualService 參照 istio-system/istio-ingressgateway，但閘道位於 default 命名空間中，流量就不會正確路由。

驗證 Pod 探索

確認網格已正確探索應用程式 Pod：

istioctl proxy-config endpoints POD_NAME

分析存取記錄

啟用存取記錄，判斷錯誤是源自後端應用程式還是 Proxy。重要欄位包括 RESPONSE_FLAGS、UPSTREAM_LOCAL_ADDRESS 和 RESPONSE_CODE。

如果記錄檔顯示上游錯誤，請從相同命名空間中的 Pod 對 GKE 服務執行直接 curl 測試。如果 curl 要求傳回相同的 5xx 錯誤，表示問題源自後端應用程式本身。

排解 SSL 憑證問題

Istio Ingress Gateway 的 SSL 憑證錯誤可能是憑證過期、通訊協定不符，或是密碼設定有誤所致。

找出 SSL 錯誤

查看 Istio Ingress Gateway Pod 的記錄：

kubectl logs -l app=istio-ingressgateway -n GATEWAY_NAMESPACE

驗證憑證和金鑰

使用 MD5 雜湊確認憑證和私密金鑰有效且相符：

openssl x509 -noout -modulus -in CERTIFICATE.CRT | openssl md5
openssl rsa -noout -modulus -in PRIVATE_KEY | openssl md5

確認憑證未過期，且一般名稱 (CN) 或主體別名 (SAN) 與網域相符。

檢查 TLS 通訊協定和密鑰設定

在 Gateway CRD 中驗證 TLS 版本和加密套件。確認包含憑證和金鑰的 Kubernetes Secret 與 Ingress Gateway 位於相同命名空間，且 credentialName 與 Secret 名稱相符。

排解外部端點間歇性逾時問題

如果要求傳送至解析為多個 IP 位址的外部端點 (例如第三方 NLB)，可能會發生間歇性逾時。

可能原因：ServiceEntry 解析

如果 spec.resolution 設為 DNS，Istio 會使用「嚴格 DNS」，在所有已解析的 IP 位址之間進行負載平衡。部分 NLB 不支援這項功能。

解析度

如要解決這個問題，請將 ServiceEntry 的解析度設為 DNS_ROUND_ROBIN。

排解流量分配不均的問題

如果流量未平均分配到應用程式 Pod，請檢查下列事項：

  • Pod 健康狀態：確保所有應用程式 Pod 在不平衡期間正常運作。
  • 負載平衡演算法：查看 DestinationRule 設定的 loadBalancer 設定 (例如 consistentHash 或 ROUND_ROBIN)。
  • 地區負載平衡：確認是否已啟用 localityLbSetting。注意：TRAFFIC_DIRECTOR 控制層不支援這項功能。

排解服務傳播和配額問題

如果網格未反映新的服務或網路設定，可能是因為機群專案已達到資源配額。

問題

  • 網路設定 (例如 VirtualService 或 DestinationRule) 不會推送至 Sidecar Proxy。
  • 即使已正確定義，新服務在網格中仍會「隱形」。

找出並解決問題的步驟

  1. 檢查資源配額：在機群專案中檢查全域內部流量導向器後端服務配額，確認機群專案是否已達到 BackendService 資源的配額。Cloud Service Mesh 通常會為每個 Kubernetes 服務通訊埠建立一個 BackendService。
  2. 查看規模限制：確認設定符合 Cloud Service Mesh 支援的規模限制。
  3. 提高配額：如果已達到配額上限，請為機群專案中受影響的資源申請提高配額，以恢復正常的服務傳播。

排解 VirtualService 評估問題

如果 VirtualService 的行為不如預期，請注意，系統會依列出的順序評估路徑。如果同一個主機有多個虛擬服務，系統會合併這些服務的路徑。「較舊」虛擬服務的路徑會優先處理，因此在合併清單中，會放在「較新」服務的路徑之前。這項設定會強化「最先比對成功者生效」規則。