このページでは、Google Kubernetes Engine（GKE）クラスタでストレージ関連の問題を解決する方法について説明します。
さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。エラー 400: RePD を最適化 VM にアタッチできない
リージョン永続ディスクは、メモリ最適化マシンまたはコンピューティング最適化マシンでは使用できません。
リージョン永続ディスクの使用が必須でない場合は、非リージョン永続ディスク ストレージ クラスの使用を検討してください。リージョン永続ディスクの使用が必須である場合は、リージョン永続ディスクを必要とする Pod が最適化マシン以外のノードプールでスケジュールされるように taint と容認を使用するなど、スケジューリング戦略を検討してください。
ディスク パフォーマンスに関する問題のトラブルシューティング
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
このような問題を解決するには、以下を確認してください。
- ストレージ ディスクタイプの比較を参照して、ニーズに合った永続ディスクタイプを選択していることを確認してください。
- この問題は、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 がマウントされない場合は、次の方法をお試しください。
- ボリューム内のファイル数を減らします。
[fsGroup]設定の使用を停止します。- アプリケーションの
fsGroupChangePolicyをOnRootMismatchに変更します。
ディスク オペレーションが遅いため 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"
緩和策
- Pod で障害が発生した場合は、PodSpec で
restartPolicy:AlwaysまたはrestartPolicy:OnFailureを使用することを検討してください。 - ブートディスクの 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 やコンテナ ファイル システムは変更されません。
この問題を解決するには、次の操作を行います。
- 変更した PersistentVolume オブジェクトはそのままにします。
- PersistentVolumeClaim オブジェクトを編集し、
spec.resources.requests.storageを PersistentVolume で使用されている値よりも大きい値に設定します。 - 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 フラグを省略する必要があります。これにより、正しい値が自動的に構成されます。
Hyperdisk ストレージ プール: クラスタまたはノードプールの作成に失敗する
Hyperdisk ストレージ プールで Hyperdisk Balanced ディスクをノードのブートディスクまたはアタッチ済みディスクとしてプロビジョニングしようとすると、ZONE_RESOURCE_POOL_EXHAUSTED エラーや同様の Compute Engine リソースエラーが発生することがあります。
これは、リソースが不足しているゾーンで GKE クラスタまたはノードプールを作成しようとすると発生します。次のような状況が考えられます。
- ゾーンに利用可能な Hyperdisk Balanced ディスクが十分にない。
- 指定したマシンタイプ（
c3-standard-4など）のノードを作成するのに十分な容量がゾーンにない。
この問題を解決するには:
- 同じリージョン内で、選択したマシンタイプに十分な容量があり、Hyperdisk Balanced ストレージ プールが利用可能なゾーンを選択します。
- 既存のストレージ プールを削除し、新しいゾーンで再作成します。これは、ストレージ プールがゾーンリソースであるためです。
- 新しいゾーンにクラスタまたはノードプールを作成します。