すべてのプロダクト
Search

このプロダクト

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

    ドキュメントセンター

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

    最終更新日:Nov 09, 2025

    ストレージボリュームのマウントおよび使用中に Pod のステータス異常が発生した場合、Pod と PVC のステータスとイベント、および CSI ストレージコンポーネントを確認して原因を特定し、問題を解決することでトラブルシューティングできます。このトピックでは、ストレージの問題の診断手順と一般的なストレージの問題について説明します。

    流程

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

    Pod または PVC イベントを確認して、ストレージの問題で Pod が起動できないかどうかを確認します。

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

      kubectl describe pod <pod-name>

      • イベントにストレージの問題を示すイベントがある場合 (たとえば、スケジューリングがボリュームとノードの不一致のために失敗したことを示す Message を伴うサンプルの FailedScheduling)、さらなるトラブルシューティングについては、次のセクションをご参照ください。

        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

      • ストレージの問題を示すイベントがある場合 (たとえば、PVC が PV にバインドできなかったことを示すサンプルの FailedBinding)、さらなるトラブルシューティングについては、次のセクションをご参照ください。

        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-plugin と csi-provisioner をアップグレードしてください。ストレージコンポーネントの最新バージョンについては、「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 を使用して接続します。

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

      • Extreme NAS のマウントディレクトリは /share で始まる必要があります。

      原因

      • NAS のマウント時に fsGroups が使用され、ファイルが多いため、chmod が遅くなります。

      • ポート 2049 がセキュリティグループルールでブロックされています。

      • NAS ファイルシステムとノードが異なる VPC にデプロイされています。

      解決策

      • fsGroups が構成されているかどうかを確認します。構成されている場合は、それらを削除し、Pod を再起動して、再度マウントを試みます。

      • Pod をホストするノードのポート 2049 がブロックされているかどうかを確認します。ブロックされている場合は、ポートのブロックを解除して再試行します。詳細については、「セキュリティグループルールを追加する」をご参照ください。

      • NAS ファイルシステムとノードが異なる VPC にデプロイされている場合は、Cloud Enterprise Network を使用して接続します。

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

      OSS ボリューム

      重要

      • OSS をノードにマウントする場合、PV に AccessKey 情報を入力する必要があります。これは Secret メソッドを介して使用できます。

      • リージョンをまたいで OSS を使用する場合は、バケット URL をパブリックアドレスに変更する必要があります。同じリージョンの場合は、内部アドレスを使用することをお勧めします。

      原因

      • OSS のマウント時に fsGroups が使用され、ファイルが多いため、chmod が遅くなります。

      • OSS バケットとノードが異なるリージョンで作成され、OSS バケットの内部エンドポイントが使用されています。その結果、ノードはバケットエンドポイントに接続できません。

      解決策

      • fsGroups が構成されているかどうかを確認します。構成されている場合は、それらを削除し、Pod を再起動して、再度マウントを試みます。

      • OSS バケットとノードが異なるリージョンで作成され、内部エンドポイントが使用されているかどうかを確認します。使用されている場合は、パブリックエンドポイントに変更します。

      • その他の問題については、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 テンプレートと一致するかどうか、および YAML テンプレートが次の要件を満たしているかどうかを確認します。

      • CSI プラグインは、必要に応じて手順に従ってデプロイされます。詳細については、「ストレージ CSI」をご参照ください。

      • 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

    原因

    カスタム StorageClass が存在しないため、Pod によって参照されているカスタム StorageClass が見つかりません。

    解決策

    現在の Pod によって参照されている StorageClass が存在するかどうかを確認する必要があります。存在しない場合は、StorageClass を再作成する必要があります。

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

    問題

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

    原因

    PVC の 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 ファイルが変更されない場合、このフィールドは既存の構成に影響しません。