TL;DR
PodがContainerCreatingで止まり、イベントに以下が表示されている場合：
MountVolume.SetUp failed for volume "my-pv" : mount failed: exit status 32
原因はたいてい3つのうちのどれかです。ボリュームがダウンまたは終了中のノードにまだアタッチされている（Multi-Attach）。ノードにファイルシステムユーティリティが不足している（e2fsck、xfs_repairなど）。あるいは前のPodから残留マウントが残っている。まず古いPodが動作していたノードを確認し、そこから順に調べていきましょう。
何かする前にエラー全文を読む
すぐに以下を実行して、実際のエラーチェーンを確認します：
kubectl describe pod <pod-name> -n <namespace>
Eventsセクションまでスクロールしてください。通常、以下のいずれかのパターンが表示されます：
Multi-Attach error for volume ... Volume is already exclusively attached to one nodemount failed: exit status 32— ファイルシステムツールが不足しているか破損しているUnable to attach or mount volumes: unmounted volumes=[my-pv]— PVCが古いノードにバインドされたままOutput: mount: /var/lib/kubelet/pods/.../mount: can't read superblock— ボリュームが破損している
どのパターンに該当するかによって、修正すべき内容が決まります。
原因1：Multi-Attach — ボリュームが別ノードにロックされている
ノードがクラッシュまたはコードンされ、古いPodが正常に終了しなかった場合です。新しいPodが別のノードに配置されますが、AWS EBSやGCE PDは同時に1つのアタッチしか許可しません。Kubernetesは古いノードが完全に消えたことを確認するまで、強制的にボリュームをデタッチしません。
# 現在PVがアタッチされているノードを確認する
kubectl get pv <pv-name> -o jsonpath='{.spec.nodeAffinity}'
# VolumeAttachmentオブジェクトを確認する
kubectl get volumeattachment
# そのクレームを持つ古いPodを探す
kubectl get pods --all-namespaces -o wide | grep <pvc-name>
古いPodがTerminatingで止まっている場合：
# 止まったPodを強制削除する — ノードが確実にダウン/交換済みの場合のみ実行
kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0
VolumeAttachment自体が孤立している場合（ノードがすでに消えている）：
# 古いVolumeAttachmentを一覧表示する
kubectl get volumeattachment
# 孤立したものを削除する
kubectl delete volumeattachment <attachment-name>
削除後、30〜60秒待ちます。新しいPodがマウントを開始するはずです。
原因2：ノードにファイルシステムユーティリティが不足している
mountからのexit status 32は、カーネルが必要なものを持っていないというサインです。ファイルシステム用のモジュールまたはユーザースペースツールがインストールされていません。OSアップグレード後や最小構成のノードイメージ使用時によく発生します。例えば、Ubuntu 22.04の最小インストールではxfsprogsはデフォルトで含まれていません。
# 対象ノードにSSH接続する
ssh <node-ip>
# PVが使用するファイルシステムを確認する — まずkubectlで取得する
kubectl get pv <pv-name> -o jsonpath='{.spec.csi.fsType}'
# ノード上でツールが存在するか確認する
which mkfs.ext4
which mkfs.xfs
which mount.nfs # NFSボリュームの場合
不足しているものをインストールします：
# Debian/Ubuntu
apt-get install -y e2fsprogs xfsprogs nfs-common
# RHEL/CentOS/Amazon Linux
yum install -y e2fsprogs xfsprogs nfs-utils
インストール後、kubeletは自動的にリトライします。1分以内に反映されない場合は、Podを削除して新たなマウントを強制します：
kubectl delete pod <pod-name> -n <namespace>
原因3：残留マウントポイントまたはファイルシステムの破損
以前に失敗したマウントが、新しいマウント試行をブロックするゴーストエントリを残すことがあります。ノードを直接確認してください：
# ボリュームの残留マウントを探す
cat /proc/mounts | grep <pv-name>
# またはPVC UIDで確認する
ls /var/lib/kubelet/pods/ | xargs -I{} ls /var/lib/kubelet/pods/{}/volumes/
残留エントリが見つかった場合はクリーンアップします：
# 残留パスをアンマウントする
umount -l /var/lib/kubelet/pods/<pod-uid>/volumes/<plugin>/<pv-name>
# kubeletを再起動して状態をクリアする
systemctl restart kubelet
ext4またはxfsファイルシステムが破損している場合は、クラウドコンソールからノードのボリュームをデタッチし、適切な修復ツールを実行します：
# ext4の場合
e2fsck -f /dev/<device>
# xfsの場合
xfs_repair /dev/<device>
原因4：PVCアクセスモードの不一致
ReadWriteOnce（RWO）ボリュームを使用しながら、異なるノードに複数のPodレプリカを実行しようとしていませんか？それは動作しません。RWOは1ノード専用です。
kubectl get pvc <pvc-name> -o jsonpath='{.spec.accessModes}'
対応策：
ReadWriteManyをサポートするストレージクラスに切り替える — NFS、AWS EFS、CephFSはこれに対応していますnodeSelectorまたはpodAffinityを使用して、PVCを共有するすべてのPodを同じノードに固定する- RWXが利用できない場合は、Deploymentの
replicas: 1に落とす
原因5：対象ノードでCSIドライバーが動作していない
# 対象ノードでCSIノードプラグインが正常かどうか確認する
kubectl get pods -n kube-system -o wide | grep csi
# そのノードのCSIノードDaemonSetポッドのログを確認する
kubectl logs -n kube-system <csi-node-pod> -c <csi-driver-container>
CSIポッドがCrashLoopBackOffになっているか、そのノードに存在しない場合、他の何をやっても意味がありません — ドライバーが正常になるまでボリュームはマウントできません。まずCSIの問題を修正してから、Podに戻りましょう。
確認
# Podイベントをリアルタイムで監視する
kubectl get events -n <namespace> --watch --field-selector involvedObject.name=<pod-name>
# PodがRunningに遷移するか確認する
kubectl get pod <pod-name> -n <namespace> -w
# コンテナ内でボリュームがマウントされているか確認する
kubectl exec -it <pod-name> -n <namespace> -- df -h
kubectl exec -it <pod-name> -n <namespace> -- ls <mount-path>
PodがRunningになり、df -hで期待したパスにボリュームが表示されれば、マウント問題は解決です。
予防策
terminationGracePeriodSecondsをPodがボリュームを正常にリリースできる十分な値に設定する — データベースワークロードでは60〜120秒が合理的な基準値ですPodDisruptionBudgetsを追加して、ローリング動作を制御し、ノードドレイン中のデタッチ競合状態を防ぐ- ブロックストレージ上のステートフルワークロードには
StatefulSetを使用する —Deploymentよりもボリュームのライフサイクル管理がはるかに安定しています - CSIドライバーを最新の状態に保つ。ドライバーのリリースにはマウントの信頼性向上の修正が頻繁に含まれています