解決 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 權限，此權限會由附屬元件插入器自動設定。

Pod 啟動後拒絕連線

當 Pod 啟動並取得 connection refused 嘗試連線至端點時，問題可能是應用程式容器在 isto-proxy 容器啟動前就啟動了。在這種情況下，應用程式容器會將要求傳送至 istio-proxy，但由於 istio-proxy 尚未在連接埠上聆聽，因此連線遭到拒絕。

在這種情況下，您可以：

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

    http://localhost:15020/healthz/ready

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

產品資訊閘道傳回空白

症狀：在成功建立 Cloud Service Mesh Gateway 後，使用 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. 如果清單中顯示的項目除了 Gateways 外，還有其他 apiVersion networking.istio.io/v1beta1，請在 kubectl 指令中使用完整資源名稱或可區分的簡稱。例如，請執行 kubectl get gw 或 kubectl get gateways.networking.istio.io，而非 kubectl get gateway，以確保列出 istio 閘道。

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