解決 Cloud Service Mesh 中的資源限制問題

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

以下任一情況都可能導致 Cloud Service Mesh 資源限制問題：

• 在 istio-system 命名空間或任何已啟用自動補充資訊植入功能的命名空間中建立的 LimitRange 物件。
• 使用者定義的限制設得太低。
• 節點的記憶體或其他資源耗盡。

資源問題的可能症狀：

• Cloud Service Mesh 屢次未收到控制層的設定，如 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。

Sidecar 接收設定的時間過長

系統可能會因為分配給 istiod 的資源不足，或是叢集大小過大，而導致設定傳播速度緩慢。

這項問題有幾種可能的解決方法：

1. 針對叢集內的 Cloud Service Mesh，如果監控工具 (Prometheus、Stackdriver 等) 顯示 istiod 的資源使用率偏高，請增加該資源的配置，例如增加 istiod 部署的 CPU 或記憶體限制。這是暫時性解決方案，建議您研究如何減少資源用量。

2. 如果您在大型叢集或部署中遇到這個問題，請設定Sidecar 資源，減少推送至每個 Proxy 的設定狀態數量。

3. 如果是叢集內的 Cloud Service Mesh，如果問題持續發生，請嘗試水平擴充 istiod。

4. 如果所有其他疑難排解步驟都無法解決問題，請回報錯誤，詳細說明您的部署作業和觀察到的問題。請按照這些步驟，盡可能在錯誤報告中加入 CPU/記憶體設定檔，並詳細說明叢集大小、Pod 數量和服務數量。