排解 GKE 儲存空間問題

本頁面說明如何解決 Google Kubernetes Engine (GKE) 叢集上的儲存空間相關問題。

錯誤 400：無法將 RePD 附加至最佳化 VM

地區永久磁碟無法搭配記憶體最佳化機器或運算最佳化機器使用。

如果不是非得使用地區永久磁碟，建議考慮使用非地區永久磁碟儲存空間類別。如果必須使用地區永久磁碟，請考慮使用污點和容許條件等排程策略，確保需要地區永久磁碟的 Pod 會排程到非最佳化機器的節點集區。

排解磁碟效能問題

開機磁碟的效能非常重要，因為 GKE 節點的開機磁碟不僅用於作業系統，也用於下列項目：

  • Docker 映像檔。
  • 未以磁碟區掛接的容器檔案系統 (即疊加檔案系統)，通常包含 /tmp 等目錄。
  • 磁碟支援的 emptyDir 磁碟區，除非節點使用本機 SSD。

節點上所有磁碟類型相同的磁碟，會共用磁碟效能。舉例來說，如果您有 100 GB 的 pd-standard 開機磁碟和 100 GB 的 pd-standard PersistentVolume，且活動量很大，開機磁碟的效能就會等同於 200 GB 的磁碟。此外，如果 PersistentVolume 上有大量活動，也會影響開機磁碟的效能。

如果節點上出現類似下列內容的訊息，可能是磁碟效能不佳的徵兆：

INFO: task dockerd:2314 blocked for more than 300 seconds.

fs: disk usage and inodes count on following dirs took 13.572074343s

PLEG is not healthy: pleg was last seen active 6m46.842473987s ago; threshold is 3m0s

如要解決這類問題，請參閱下列說明：

由於 fsGroup 設定，掛接磁碟區時停止回應

如果 Pod 設定了 fsGroup，可能會導致 PersistentVolume 無法掛接。通常，掛接作業會自動重試，並自行解決掛接失敗的問題。不過，如果 PersistentVolume 有大量檔案，kubelet 會嘗試變更檔案系統中每個檔案的擁有權，這可能會增加磁碟區掛接延遲。

Unable to attach or mount volumes for pod; skipping pod ... timed out waiting for the condition

如要確認掛接失敗錯誤是否是由 fsGroup 設定所致，可以檢查 Pod 的記錄。如果問題與 fsGroup 設定有關，您會看到下列記錄項目：

Setting volume ownership for /var/lib/kubelet/pods/POD_UUID and fsGroup set. If the volume has a lot of files then setting volume ownership could be slow, see https://github.com/kubernetes/kubernetes/issues/69699

如果 PersistentVolume 未在幾分鐘內掛接，請嘗試下列步驟解決問題：

磁碟作業緩慢導致 Pod 建立失敗

詳情請參閱 containerd 問題 #4604。

受影響的 GKE 節點版本：1.18、1.19、1.20.0 至 1.20.15-gke.2100、1.21.0 至 1.21.9-gke.2000、1.21.10 至 1.21.10-gke.100、1.22.0 至 1.22.6-gke.2000、1.22.7 至 1.22.7-gke.100、1.23.0 至 1.23.3-gke.700、1.23.4 至 1.23.4-gke.100

記錄檔中可能會顯示下列錯誤訊息：k8s_node container-runtime

Error: failed to reserve container name "container-name-abcd-ef12345678-91011_default_12131415-1234-5678-1234-12345789012_0": name "container-name-abcd-ef12345678-91011_default_12131415-1234-5678-1234-12345789012_0" is reserved for "1234567812345678123456781234567812345678123456781234567812345678"

減緩

  1. 如果 Pod 失敗，請考慮在 PodSpec 中使用 restartPolicy:Always 或 restartPolicy:OnFailure。
  2. 提高開機磁碟 IOPS (例如升級磁碟類型或增加磁碟大小)。

修正

這個問題已在 containerd 1.6.0 以上版本修正。包含這項修正的 GKE 版本為 1.20.15-gke.2100 以上、1.21.9-gke.2000 以上、1.21.10-gke.100 以上、1.22.6-gke.2000 以上、1.22.7-gke.100 以上、1.23.3-gke.1700 以上和 1.23.4-gke.100 以上

容器檔案系統未反映磁碟區擴充變更

執行磁碟區擴充作業時，請務必更新 PersistentVolumeClaim。直接變更 PersistentVolume 可能會導致磁碟區無法擴充。這可能會導致下列其中一種情況：

  • 如果直接修改 PersistentVolume 物件，PersistentVolume 和 PersistentVolumeClaim 值都會更新為新值，但檔案系統大小不會反映在容器中，仍會使用舊的磁碟區大小。

  • 如果直接修改 PersistentVolume 物件，然後更新 PersistentVolumeClaim，將 status.capacity 欄位更新為新的大小，可能會導致 PersistentVolume 變更，但 PersistentVolumeClaim 或容器檔案系統不會變更。

如要解決這個問題，請完成下列步驟：

  1. 將修改後的 PersistentVolume 物件恢復原狀。
  2. 編輯 PersistentVolumeClaim 物件，並將 spec.resources.requests.storage 設為高於 PersistentVolume 中使用的值。
  3. 確認 PersistentVolume 是否已調整為新值。

完成這些變更後，kubelet 應會自動調整 PersistentVolume、PersistentVolumeClaim 和容器檔案系統的大小。

確認變更是否反映在 Pod 中。

kubectl exec POD_NAME  -- /bin/bash -c "df -h"

將 POD_NAME 取代為附加至 PersistentVolumeClaim 的 Pod。

所選機型應具備本機 SSD

建立使用本機 SSD 的叢集或節點集區時，可能會發生下列錯誤：

The selected machine type (c3-standard-22-lssd) has a fixed number of local SSD(s): 4. The EphemeralStorageLocalSsdConfig's count field should be left unset or set to 4, but was set to 1.

在錯誤訊息中，您可能會看到 LocalNvmeSsdBlockConfig，而非 EphemeralStorageLocalSsdConfig，具體取決於您指定的內容。

如果指定的本機 SSD 磁碟數量與機器類型隨附的本機 SSD 磁碟數量不符，就會發生這個錯誤。

如要解決這個問題，請指定與所需機器類型相符的本機 SSD 磁碟數量。如果是第三代機型系列，您必須省略本機 SSD count 旗標，系統會自動設定正確的值。

Hyperdisk 儲存空間集區：無法建立叢集或節點集區

在 Hyperdisk 儲存集區中，嘗試將 Hyperdisk Balanced 磁碟佈建為節點的開機或附加磁碟時，可能會遇到 ZONE_RESOURCE_POOL_EXHAUSTED 錯誤或類似的 Compute Engine 資源錯誤。

當您嘗試在資源不足的區域中建立 GKE 叢集或節點集區時，就會發生這種情況，例如：

  • 該可用區可能沒有足夠的 Hyperdisk Balanced 磁碟。
  • 可用區可能沒有足夠容量，無法建立您指定的機器類型節點，例如 c3-standard-4。

如何解決這個問題：

  1. 在同一個區域中選取新的可用區，該區域必須有足夠的容量，可供您選擇的機器類型使用，且提供 Hyperdisk Balanced 儲存空間集區。
  2. 刪除現有儲存空間集區，並在新區域中重新建立。這是因為儲存集區是區域資源。
  3. 在新可用區中建立叢集或節點集區。

後續步驟