すべてのプロダクト
Search

このプロダクト

    Container Service for Kubernetes:ストレージの問題のトラブルシューティング

    ドキュメントセンター

    Container Service for Kubernetes:ストレージの問題のトラブルシューティング

    最終更新日:Mar 26, 2026

    永続ボリューム (PV) のマウントまたは使用時に Pod のステータスが異常な場合、Pod とその PersistentVolumeClaim (PVC) のステータスとイベント、および Container Storage Interface (CSI) コンポーネントのステータスを確認することで、問題を特定して解決できます。このトピックでは、ストレージ関連の問題をトラブルシューティングする方法と、一般的なストレージの問題に関する情報について説明します。

    流程

    1. Pod の異常がストレージの問題によって引き起こされているかどうかの確認

    Pod または PVC イベントを確認して、ストレージの問題により Pod が起動できないことを確認します。

    1. 異常な Pod のイベントを表示します。

      kubectl describe pod <pod-name>

      • イベントがストレージの問題を示している場合、このトピックのトラブルシューティング手順に進みます。たとえば、次のサンプル出力の FailedScheduling イベントには、ボリュームとノードが一致しないためスケジューリングが失敗したことを示す Message があります。

        Events:
  Type     Reason            Age    From               Message
  ----     ------            ----   ----               -------
  Warning  FailedScheduling  4m37s  default-scheduler  0/1 nodes are available: 1 node(s) had volume node affinity conflict. preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling.,

      • サンプル出力の SuccessfulAttachVolume イベントのように、ボリュームが正常にアタッチされたことを示しているにもかかわらず Pod が実行されていない場合 (たとえば、CrashLoopBackOff 状態の場合)、問題はストレージに関連していません。他の問題についてはイベントを確認するか、チケットを送信してサポートを依頼してください。

        Events:
  Type    Reason                  Age   From                     Message
  ----    ------                  ----  ----                     -------
  Normal  Scheduled               97s   default-scheduler        Successfully assigned default/disk-test-0 to cn-shanghai.192.168.5.2
  Normal  SuccessfulAttachVolume  97s   attachdetach-controller  AttachVolume.Attach succeeded for volume "d-uf6b8s2l5ypf48*****"

    2. Pod のストレージ関連イベントが表示されない場合は、すべてのイベントを表示します。

      kubectl get events

      • イベントがストレージの問題を示している場合、このトピックのトラブルシューティング手順に進みます。たとえば、サンプル出力の FailedBinding イベントは、PVC が PV にバインドできなかったことを示しています。

        LAST SEEN   TYPE      REASON                 OBJECT                                                  MESSAGE
2m56s       Normal    FailedBinding          persistentvolumeclaim/data-my-release-mariadb-0         no persistent volumes available for this claim and no storage class is set
41s         Normal    ExternalProvisioning   persistentvolumeclaim/pvc-nas-dynamic-create-subpath8   waiting for a volume to be created, either by external provisioner "nasplugin.csi.alibabacloud.com" or manually created by system administrator
3m31s       Normal    Provisioning           persistentvolumeclaim/pvc-nas-dynamic-create-subpath8   External provisioner is provisioning volume for claim "default/pvc-nas-dynamic-create-subpath8"

      • ストレージ関連イベントがない場合は、他の問題についてイベントを確認するか、チケットを送信してサポートを依頼してください。

    2. ストレージコンポーネントが正常であるかどうかの確認

    説明

    クラスターが現在 FlexVolume コンポーネントを使用している場合、FlexVolume は非推奨であるため、できるだけ早く CSI コンポーネントに移行することを推奨します。詳細については、「FlexVolume から CSI への移行」をご参照ください。

    1. CSI ストレージコンポーネントが正しく動作しているか確認します。

      kubectl get pod -n kube-system |grep csi

      次のサンプル出力が返されます。Pod が `Running` 状態ではない場合、kubectl describe pods <pod-name> -n kube-system を実行して Pod イベントとコンテナが終了した理由を表示します。

      説明

      CSI ストレージコンポーネントには、csi-plugin と csi-provisioner が含まれます。デフォルトでは、csi-provisioner のマネージドバージョンがインストールされています。マネージドコンポーネントは Alibaba Cloud によって管理されます。これらのコンポーネントの Pod はクラスターに表示されません。

      NAME                     READY   STATUS        RESTARTS   AGE
csi-plugin-bpz28         4/4     Running       0          3d
csi-plugin-h2tdg         4/4     Running       0          3d
csi-plugin-qpnm4         4/4     Running       0          3d
csi-plugin-wczgm         4/4     Running       0          3d

    2. CSI ストレージコンポーネントが最新バージョンであるか確認します。

      kubectl get ds csi-plugin -n kube-system -o yaml |grep image

      返された情報の image フィールドでイメージバージョンを確認できます。以下はサンプル出力です。

      image: registry-cn-shanghai-vpc.ack.aliyuncs.com/acs/csi-plugin:v1.33.1-67e8986-aliyun

      ストレージコンポーネントが最新バージョンではない場合、CSI コンポーネントをアップグレードします。ストレージコンポーネントの最新バージョンに関する詳細については、「csi-plugin」をご参照ください。

      説明

      コンソールのアドオン管理 ページに移動して、 csi-plugin および csi-provisioner コンポーネントを探し、バージョンを確認してアップグレードすることもできます。

    3. PV、PVC、および StorageClass の YAML ファイルを確認して、ドライバー構成 (driver または provisioner フィールド) が CSI ストレージコンポーネントを使用するように設定されており、クラスターで使用されているストレージコンポーネントと一致していることを確認します。

    3. PVC ステータスが Bound であるかどうかの確認

    1. PVC ステータスを表示します。

      kubectl get pvc

    2. PVC が `Bound` 状態ではない場合、次のように問題をトラブルシューティングして解決します。

      原因

      • 静的: PVC と PV のセレクターがバインディング条件を満たしていません。たとえば、PVC のセレクター構成が PV の構成と一致しない、StorageClass 名が一致しない、または PV ステータスが `Released` です。

      • 動的: csi-provisioner コンポーネントで問題が発生しました。

      解決策

    4. Pod ステータスが Running であるかどうかの確認

    1. Pod ステータスを表示します。

      kubectl get pod

    2. PVC が `Bound` 状態であるにもかかわらず Pod が `Running` 状態ではない場合、永続ボリュームのタイプに基づいて次のように問題をトラブルシューティングして解決します。

      クラウドディスク永続ボリューム

      重要

      クラウドディスク永続ボリュームを使用する場合、Pod がスケジューリングされる ECS ノードのインスタンスタイプが、指定されたタイプのクラウドディスクのアタッチをサポートしていること、および Pod とクラウドディスクが同じリージョンとゾーンにあることを確認してください。ディスクタイプと ECS インスタンスタイプのマッピングについては、「インスタンスファミリー」をご参照ください。

      原因

      • スケジューリングに利用できる適格なノードがありません。

      • クラウドディスクのアタッチ時に問題が発生しました。

      • ECS インスタンスタイプとクラウドディスクタイプが一致しません。

      解決策

      NAS 永続ボリューム

      重要

      • ノードと NAS ファイルシステムは同じ VPC に存在する必要があります。同じ VPC にない場合、Cloud Enterprise Network (CEN) を使用して接続できます。

      • NAS はゾーン間マウントをサポートしています。

      • 超高速型 NAS ファイルシステムのマウントパスは /share で始まる必要があります。

      原因

      • fsGroups を使用して NAS ファイルシステムをマウントすると、多くのファイルが `chmod` 操作を遅くする可能性があります。

      • セキュリティグループでポート 2049 がブロックされており、NAS ファイルシステムのマウントが妨げられています。

      • NAS ファイルシステムとノードが同じ VPC にありません。

      解決策

      • fsGroups が設定されているか確認します。設定されている場合、それを削除し、Pod を再起動して、ボリュームを再度マウントできます。

      • Pod がスケジューリングされているノードでポート 2049 がブロックされているか確認します。ポートがブロックされている場合、ポート 2049 を開放してからボリュームを再度マウントできます。詳細については、「セキュリティグループルールの追加」をご参照ください。

      • NAS ファイルシステムとノードが同じ VPC にあることを確認します。同じでない場合、CEN を使用して接続します。

      • その他の問題については、kubectl describe pods <pod-name> を実行して Pod イベントを表示します。

      OSS 永続ボリューム

      重要

      • ノードが OSS バケットをマウントする場合、PV には AccessKey 情報が含まれている必要があります。この情報は Secret を使用して提供できます。

      • リージョン間で OSS を使用する場合、バケット URL をパブリックエンドポイントに変更します。同じリージョン内では、内部エンドポイントを使用することを推奨します。

      原因

      • fsGroups を使用して多数のファイルを含む OSS バケットをマウントすると、chmod 操作が遅くなります。

      • クロスリージョンアクセスに内部エンドポイントが使用されており、バケットエンドポイントへの接続が妨げられています。

      解決策

      • fsGroups が設定されているか確認します。設定されている場合、それを削除し、Pod を再起動して、ボリュームを再度マウントできます。

      • 内部エンドポイントを使用してリージョン間でバケットにアクセスしているか確認します。アクセスしている場合、代わりにパブリックエンドポイントを使用します。

      • その他の問題については、kubectl describe pods <pod-name> を実行して Pod イベントを表示します。

    よくある質問

    永続ボリュームの作成またはマウント時に、PVC に「no volume plugin matched」というメッセージが表示される

    症状

    永続ボリュームの作成またはマウント時に、PVC イベントに次のメッセージが表示されます: Unable to attach or mount volumes: unmounted volumes=[xxx], unattached volumes=[xxx]: failed to get Plugin from volumeSpec for volume "xxx" err=no volume plugin matched。

    原因

    YAML テンプレートで指定されたストレージコンポーネントがクラスターで見つかりません。

    解決策

    ストレージコンポーネントがクラスターに存在するか確認します。

    • ストレージコンポーネントがインストールされていない場合、クラスターにインストールできます。詳細については、「コンポーネントの管理」をご参照ください。

    • ストレージコンポーネントがインストールされている場合、PV および PVC の YAML テンプレートと一致し、次の条件が満たされていることを確認します。

      • CSI ストレージコンポーネントは、CSI 関連ドキュメントを使用してデプロイされます。詳細については、「CSI」をご参照ください。

      • FlexVolume ストレージコンポーネントは、FlexVolume 関連ドキュメントを使用してデプロイされます。詳細については、「FlexVolume」をご参照ください。

        重要

        FlexVolume は非推奨であるため、できるだけ早く CSI コンポーネントに移行することを推奨します。詳細については、「FlexVolume から CSI への移行」をご参照ください。

    Pod イベントに「0/x nodes are available: x pod has unbound immediate PersistentVolumeClaims」というメッセージが表示される

    症状

    Pod が起動せず、Pod イベントに次のメッセージが表示されます。

    0/x nodes are available: x pod has unbound immediate PersistentVolumeClaims. preemption: 0/x nodes are available: x Preemption is not helpful for scheduling

    原因

    Pod によって参照されるカスタム StorageClass が作成されておらず、見つかりません。

    解決策

    Pod によって参照される StorageClass が存在するか確認します。存在しない場合、StorageClass を再作成できます。

    PV が Released 状態であり、PVC を再作成してもバインドできない

    症状

    PVC が誤って削除された後、PV は Released 状態になり、PVC を再作成してもバインドできません。

    原因

    PV の reclaimPolicy が Retain の場合、バインドされた PVC が誤って削除されると、PV は Released 状態になります。

    解決策

    PV から pv.spec.claimRef フィールドを削除し、静的ボリューム方式を使用して再バインドできます。これにより、PV は Bound 状態になります。

    PV が Lost 状態であり、PVC を再作成してもバインドできない

    症状

    PVC と PV が作成された後、PV は Lost 状態になり、PVC にバインドできません。

    原因

    PV の claimRef フィールドで参照される PVC 名が存在しません。これにより、PV は Lost 状態になります。

    解決策

    PV から pv.spec.claimRef フィールドを削除し、静的ボリューム方式を使用して再バインドできます。これにより、PV は Bound 状態になります。

    StorageClass の変更は既存のストレージに影響しますか？

    いいえ、影響しません。PVC および PV の YAML ファイルが変更されない場合、StorageClass の変更は既存のストレージに影響しません。たとえば、StorageClass の allowVolumeExpansion フィールドを変更しても、その変更は PVC の capacity を変更した後にのみ有効になります。PVC の YAML ファイルが変更されない場合、この変更は既存の構成に影響しません。