解決 Cloud Service Mesh 中的資源限制問題
本節說明常見的 Cloud Service Mesh 問題，以及如何解決這些問題。如需其他協助，請參閱取得支援。
以下任一情況都可能導致 Cloud Service Mesh 資源限制問題：
- 在
istio-system命名空間或任何已啟用自動補充資訊植入功能的命名空間中建立的LimitRange物件。 - 使用者定義的限制設得太低。
- 節點的記憶體或其他資源耗盡。
資源問題的可能症狀：
- Cloud Service Mesh 會重複未收到
istiod的設定，如Envoy proxy NOT ready所示。啟動時出現幾次這個錯誤是正常的，但如果出現更多次，就表示有問題。 - 部分 Pod 或節點發生網路問題，導致無法連線。
istioctl proxy-status在輸出結果中顯示STALE狀態。- 節點記錄中的
OOMKilled訊息。 - 容器的記憶體用量：
kubectl top pod POD_NAME --containers。 - 節點內部 Pod 的記憶體用量：
kubectl top node my-node。 - Envoy 記憶體不足：
kubectl get pods在輸出結果中顯示狀態OOMKilled。
Istio 邊車接收設定的時間過長
系統可能會因為分配給 istiod 的資源不足，或是叢集大小過大，而導致設定傳播速度緩慢。
這項問題有幾種可能的解決方法：
如果監控工具 (Prometheus、Stackdriver 等) 顯示
istiod對某項資源的使用率偏高，請增加該資源的配置，例如增加istiod部署作業的 CPU 或記憶體限制。這是暫時性的解決方法，建議您研究如何減少資源用量。如果您在大型叢集/部署中遇到這個問題，請設定Sidecar 資源，減少推送至每個 Proxy 的設定狀態數量。
如果問題仍未解決，請嘗試水平縮放
istiod。如果所有其他疑難排解步驟都無法解決問題，請回報錯誤，詳細說明您的部署作業和觀察到的問題。請按照這些步驟，盡可能在錯誤報告中加入 CPU/記憶體設定檔，並詳細說明叢集大小、Pod 數量、服務數量等。