解決 Cloud Service Mesh 中的附加元件 Proxy/webhook 問題

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

Cloud Service Mesh 包含兩個 webhook：

  • 驗證 webhook 可確保已套用的 Istio 設定有效。
  • 變異 webhook 會在新的 Pod 上設定自動附加元件注入。

其中一個 webhook 的設定問題可能會導致新 Pod 啟動失敗，或 kubectl apply 產生錯誤訊息。

補充物注入問題

如果您已佈建 Managed Cloud Service Mesh，請與支援團隊聯絡。

如果您看到下列任何情況，表示補充容器注入功能無法正常運作：

  • 未排程 sidecar 的 Pod
  • 使用 kubectl get pods 時，應注入 sidecar 的 Pod 永遠不會顯示，但 kubectl get replicaset 的對應副本集會存在。

請按照下列步驟排解側載注入問題。

  1. 確認命名空間或 Pod 具有正確的插入標籤。

    如果您執行單一修訂版本的 Istio (預設)，請確認您的命名空間或 Pod 規格具有 istio-injection=enabled 標籤。

    如果您執行的是多個修訂版本的 Istio (用於零停機遷移、多個控制平面等)，請確認您的命名空間或 Pod 規格具有適當的 istio.io/rev=REVISION 標籤，其中 REVISION 是 istiod 上的 Cloud Service Mesh 修訂版本號碼，對應您所選的 Cloud Service Mesh 版本。如要進一步瞭解修訂版本標籤，請參閱「插入附屬 Proxy」。

  2. 確認 istio sidecar 注入 webhook 是否存在，且具有 CA 套件。

    補充資訊注入器 webhook (用於自動補充資訊注入) 需要 CA 套件，才能與 API 伺服器和 istiod 建立安全連線。這個 CA 組合會由 istiod 修補至設定中，但有時可能會遭到覆寫 (例如，如果您重新套用 webhook 設定)。

    您可以使用下列指令驗證 CA 套件的存在情形。這項指令包含 istio-sidecar-injector-asm-1236-11，這是專屬於這個版本的 Cloud Service Mesh。如果不同，請務必使用實際修訂版本。

    kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector-asm-1236-11 -o=jsonpath='{.webhooks[0].clientConfig.caBundle}'

    如果輸出內容不為空白，表示已設定 CA 組合。如果 CA 套件遺失，請重新啟動 istiod，讓它重新掃描 webhook，並重新安裝 CA 套件。

  3. 檢查是否有附加元件插入失敗的情況。

    如果您已啟用插入功能，但未看到 Pod 排程，請檢查下一個較高層級的抽象層級狀態。舉例來說，如果您正在執行部署作業，但沒有任何 Pod 排程，請使用下列指令檢查對應的複本集的狀態：

    kubectl -n my-namespace describe replicaset your-deployment-name

    如果有副本集，請檢查說明底部的事件記錄，確認是否有錯誤。如果錯誤與附加元件插入作業有關，請查看 istiod 記錄，瞭解導致錯誤的原因。

  4. 如果問題仍未解決，問題可能出在下列任一情況：

    • 傳遞至插入器的設定有誤
    • 防火牆設定問題
    • Istio 程式碼本身的問題

    如需其他診斷步驟，請參閱「排解 Istio 問題」。

Envoy Proxy 不會接收來自 istiod 的設定

有幾個問題可能會導致 Proxy 無法從 istiod 接收設定。

  1. 如果發生問題 (例如 RBAC 問題導致無法讀取設定資源)，istiod 就不會將設定推送至 Envoy 代理程式。

  2. 探索地址有誤 (出現「no healthy upstream」錯誤)

  3. 提供給 sidecar Injector 的探索位址有誤。如果您看到記錄提及 gRPC config stream closed, no healthy upstream，請確認網格 ProxyConfig 中的探索地址是否正確，且指向您的 istiod 服務。

  4. 無效的設定會推送至 Proxy。在這種情況下，設定會成功推送至 Proxy，但設定無效。您會看到類似以下的重複訊息：

    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 1 rejected

    在這個範例中，cds 是叢集探索服務 (會回報從 istiod 推送的 1 項更新)，而 lds 是事件監聽器探索服務 (會回報從 istiod 拒絕的 1 項更新)。您通常會看到較早的錯誤訊息，說明拒絕的原因，這類訊息通常會以有關使節點配置或類似項目的警告開頭。

    如要修正這個問題，請調查設定遭拒的原因。其中一個常見原因是 EnvoyFilter 資源有問題。如果沒有明顯的原因，請提交錯誤報告，並附上 Proxy 的設定傾印。

無法建立 Pod

如果您發現 Pod 無法順利建立，請使用下列指令尋找可能提供根本問題線索的錯誤訊息：

kubectl describe replicaset YOUR_REPLICA_SET

常見的 webhook 錯誤訊息

kubectl apply 指令輸出的錯誤訊息可提供錯誤的根本原因。請參閱下表，瞭解常見錯誤訊息、原因和可能的解決方法。

錯誤訊息 原因 解決方法
net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) 這可能是網路連線問題。 請確認防火牆規則可透過通訊埠 15017 連線至 `istiod`。
no endpoints available for service 'istiod' 如果 `istiod` Pod 無法使用或尚未就緒，就可能發生這種情況。 檢查 `istiod` Pod，確認它們是否正在執行且就緒。
Service "istiod" not found 如果不存在 `istiod` 服務，就可能發生這種情況。 確認 Istio 安裝作業是否成功且正確無誤。
x509: certificate signed by unknown authority 這可能是 webhook 憑證問題。 請確認 caBundle 已正確設定在 webhook 上。
Failed to update validatingwebhookconfiguration istio-validator-asm-[version-n]-istio-system (failurePolicy=Fail, resourceVersion=[version]): Operation cannot be fulfilled on validatingwebhookconfigurations.admissionregistration.k8s.io "istio-validator-asm-[version-n]-istio-system": the object has been modified; please apply your changes to the latest version and try again. 舊版 Istio 或已解除安裝的 Cloud Service Mesh 中的驗證 webhook 可能會干擾升級或安裝作業。 檢查叢集中是否仍有所有 Webhook，並移除參照已不再安裝的版本的 Webhook。
Error from server (InternalError): Internal error occurred: failed calling webhook "rev.namespace.sidecar-injector.istio.io": Post "https://istiod-asm-1122-0.istio-system.svc:443/inject?timeout=10s": context deadline exceeded 對於私人叢集，必須開啟 15017 通訊埠。這則錯誤訊息表示可能未開啟連接埠 15017。 請確認您的防火牆規則可透過 15017 通訊埠連線至 Istiod。詳情請參閱「在私人叢集上開啟通訊埠」。