共用方式為

叢集升級至 Kubernetes 1.25 之後，Pod 中會發生記憶體飽和

本文討論如何修正因記憶體飽和或記憶體不足（OOM）錯誤而停止運作的 Pod，這些錯誤會在您將 Microsoft Azure Kubernetes Service （AKS） 叢集升級至 Kubernetes 1.25 之後發生。x.

徵兆

發生下列一或多個問題：

  • 節點上的記憶體壓力

  • 相較於升級前應用程式的記憶體使用量增加，應用程式的記憶體使用量增加

  • 節點上的CPU節流

  • Pod 失敗，因為 OOM 錯誤

在下列環境中執行的應用程式可能會發生效能降低：

注意

發生效能降低的環境清單不是完整的清單。 可能有其他環境遇到記憶體飽和或 OOM 問題。

解決方案

注意

如果您只遇到記憶體使用量增加的情況，並且沒有 Symptoms （癥狀 ） 部分中提到的其他癥狀，則無需執行任何作。

從 Kubernetes 1.25 版開始， cgroup 2 版 API 已達到正式運作 （GA）。 AKS 現在使用 Ubuntu Linux 22.04 版。 根據預設，22.04 版會使用 cgroup 2 版 API。 若要確定 cgroup 第 2 版 API 可用於其他環境中，以避免記憶體飽和問題，請遵循下列指引：

  • 如果您執行 Java 應用程式，請升級至支援 cgroup 第 2 版的 Java 版本，並遵循將 Java 應用程式容器化中的指引。 您可能能夠在已回移修正的特定版本中更新基底映像。 使用原生支援 cgroup 第 2 版的版本或架構。 對於 Azure 客戶，Microsoft正式支援 Eclipse Temurin 二進位檔 （Java 8） 和 Microsoft OpenJDK 二進位檔的建置 （Java 11+）。

  • 同樣地，如果您使用 .NET，請升級至 .NET 5.0 版或更新版本。

  • 如果您在 Pod 上看到更高的驅逐率，請 對 Pod 使用更高的限制和請求。

  • cgroup v2 使用與 v1 不同的 API cgroup 。 如果有任何應用程式直接存取 cgroup 檔案系統，請將其更新為支援 cgroup v2 的更新版本。 例如：

    • 第三方監視和安全性代理程式：

      某些監視和安全性代理程式取決於 cgroup 文件系統。 將這些代理程式更新為支援 cgroup v2 的版本。

    • Java 應用程式：

      使用完全支援 cgroup v2 的版本：

      • OpenJDK/HotSpot： jdk8u372、 11.0.16、 15和更新版本。
      • IBM Semeru Runtimes： 8.0.382.0、 11.0.20.0、 17.0.8.0和更新版本。
      • IBM Java： 8.0.8.6 和更新版本。

    • uber-go/automaxprocs：
      如果您使用 uber-go/automaxprocs 套件，請確定版本為 v1.5.1 或更新版本。

  • 另一個暫時性解決方案是使用 DaemonSet 還原 cgroup 節點上的版本。 如需詳細資訊，請參閱 還原為 cgroup v1 DaemonSet。

    這很重要

    • 謹慎使用 DaemonSet。 在應用於生產環境之前，請在較低的環境中對其進行測試，以確保相容性並避免中斷。
    • 根據預設，DaemonSet 會套用至叢集中的所有節點，並重新啟動它們以實作 cgroup 變更。
    • 若要控制 DaemonSet 的套用方式，請將 設定 nodeSelector 為以特定節點為目標。

地位

Microsoft 正在與 Kubernetes 社區合作解決此問題。 在 Azure/AKS 問題 #3443 中跟蹤進度。

作為解決方案的一部分，計劃是根據修復的結果調整驅逐閾值或更新 資源預留。

參考文獻

協力廠商資訊免責聲明

本文提及的協力廠商產品是由與 Microsoft 無關的獨立廠商所製造。 Microsoft 不以默示或其他方式，提供與這些產品的效能或可靠性有關的擔保。

協力廠商連絡資訊免責聲明

Microsoft 提供協力廠商連絡資訊，以協助您尋找有關此主題的其他資訊。 此連絡資訊可能會變更而不另行通知。 Microsoft 不保證協力廠商連絡資訊的準確性。

與我們連絡，以取得說明

如果您有問題或需要相關協助，請建立支援要求，或詢問 Azure community 支援。 您也可以向 Azure 意見反應社群提交產品意見反應。