GKE のストレージのトラブルシューティング

このページでは、Google Kubernetes Engine（GKE）クラスタにデプロイされたボリュームの問題を解決する方法について説明します。

エラー 400: RePD を最適化 VM にアタッチできません

リージョン永続ディスクは、メモリ最適化マシンまたはコンピューティング最適化マシンでは使用できません。

リージョン永続ディスクの使用が必須でない場合は、非リージョン永続ディスク ストレージ クラスの使用を検討してください。リージョン永続ディスクの使用が必須である場合は、リージョン PD を必要とする Pod が最適化マシン以外のノードプールでスケジュールされるように taint と容認を使用するなど、スケジューリング戦略を検討してください。

ディスク パフォーマンスに関する問題のトラブルシューティング

GKE ノードのブートディスクはオペレーティング システムだけでなく、次の用途にも使用されるため、ブートディスクのパフォーマンスは重要です。

  • docker images
  • ボリュームとしてマウントされていないもの用のコンテナ ファイル システム（つまり、オーバーレイ ファイル システム）であり、多くの場合、/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

このような問題を解決するには、以下を確認してください。

  • ストレージ ディスクタイプの比較を参照して、ニーズに合った永続ディスクタイプを選択していることを確認してください。
  • この問題は、200 GB 未満のサイズの標準永続ディスクを使用するノードでよく発生します。特に本番環境で使用されているクラスタの場合は、ディスクのサイズを増やすか、SSD に切り替えることを検討してください。
  • ノードプールでエフェメラル ストレージのローカル SSD を有効にすることを検討してください。これは、emptyDir ボリュームを頻繁に使用するコンテナがある場合に特に効果的です。

fsGroup 設定が原因でボリュームのマウントが応答しなくなる

PersistentVolume のマウントが失敗する原因となる問題の一つとして、fsGroup 設定が構成されている Pod があります。通常、マウントは自動的に再試行され、マウントの失敗は自動で解決されます。ただし、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 オブジェクトが直接変更され、その後、status.capacity フィールドが新しいサイズに更新される PersistentVolumeClaim の更新が行われると、PersistentVolume が変更されますが、PersistentVolumeClaim やコンテナ ファイル システムは変更されません。

緩和策

  1. 変更した PersistentVolume オブジェクトはそのままにします。
  2. PersistentVolumeClaim オブジェクトを編集し、spec.resources.requests.storage を PersistentVolume で使用されている値よりも大きい値に設定します。
  3. PersistentVolume が新しい値にサイズ変更されるかどうかを確認します。

この変更後、PersistentVolume、PersistentVolumeClaim、コンテナ ファイル システムは、kubelet によって自動的にサイズ変更されます。

  • 変更が 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.

指定した内容によっては、エラー メッセージに EphemeralStorageLocalSsdConfig ではなく LocalNvmeSsdBlockConfig と表示されることがあります。

このエラーは、指定されたローカル SSD ディスクの数が、マシンタイプに含まれるローカル SSD ディスクの数と一致していない場合に発生します。

緩和策

この問題を解決するには、ローカル SSD ディスクの数として必要なマシンタイプと一致する数を指定します。第 3 世代のマシンシリーズでは、ローカル SSD count フラグを省略する必要があります。これにより、正しい値が自動的に構成されます。