すべてのプロダクト
Search
ドキュメントセンター

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

最終更新日:Apr 18, 2025

このトピックでは、ストレージの診断手順とストレージ例外のトラブルシューティング方法について説明します。

診断手順

Procedure

  1. ポッドイベントをクエリして、ストレージの問題が原因でポッドの起動に失敗したかどうかを確認します。

    kubectl describe pods <pod-name>

    ポッドが次の状態の場合、ボリュームはポッドにマウントされています。この場合、CrashLoopBackOff などの他の問題が原因で、ポッドの起動に失敗します。問題を解決するには、チケットを送信 します。pod

  2. Container Storage Interface (CSI) プラグインが正常に動作するかどうかを確認します。

    kubectl get pod -n kube-system |grep csi

    期待される出力:

    NAME                       READY   STATUS             RESTARTS   AGE
    csi-plugin-***             4/4     Running            0          23d
    csi-provisioner-***        7/7     Running            0          14d
    説明

    ポッドのステータスが Running でない場合は、kubectl describe pods <pod-name> -n kube-system コマンドを実行して、コンテナの終了原因を確認し、ポッドイベントを表示します。

  3. CSI プラグインのバージョンが最新であるかどうかを確認します。

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

    期待される出力:

    image: registry.cn-****.aliyuncs.com/acs/csi-plugin:v*****-aliyun

    最新の CSI バージョンについては、「csi-plugin」および「Csi-provisioner」をご参照ください。クラスタで以前の CSI バージョンを使用している場合は、「プラグインを最新バージョンにアップグレードする」をご参照ください。

    ボリュームプラグインのアップグレード失敗のトラブルシューティング方法については、「コンポーネントのアップグレード失敗のトラブルシューティング」をご参照ください。

  4. ポッドの pending 問題のトラブルシューティングを行います。

  5. 永続ボリューム要求 (PVC) のステータスが Bound ではない問題のトラブルシューティングを行います。

  6. 問題が解決しない場合は、チケットを送信 します。

コンポーネントのアップグレード失敗のトラブルシューティング

csi-provisioner コンポーネントと csi-plugin コンポーネントのアップグレードに失敗した場合は、次の手順を実行して問題をトラブルシューティングします。

csi-provisioner

  • デフォルトでは、csi-provisioner コンポーネントは、2 つのポッドを作成するデプロイメントを使用してデプロイされます。ポッドは相互に排他的であるため、同じノードにスケジュールすることはできません。コンポーネントのアップグレードに失敗した場合は、クラスタで使用可能なノードが 1 つだけかどうかを確認します。

  • バージョン 1.14 以前では、csi-provisioner コンポーネントは StatefulSet を使用してデプロイされます。クラスタ内の csi-provisioner コンポーネントが StatefulSet を使用してデプロイされている場合は、kubectl delete sts csi-provisioner コマンドを実行して、現在の csi-provisioner コンポーネントを削除できます。次に、ACK コンソール にログインし、csi-provisioner コンポーネントを再インストールします。詳細については、「コンポーネントの管理」をご参照ください。

csi-plugin

  • クラスタに NotReady 状態のノードが含まれているかどうかを確認します。NotReady ノードが存在する場合、ACK は csi-plugin コンポーネントのデプロイに使用される DaemonSet をアップグレードできません。

  • csi-plugin コンポーネントのアップグレードに失敗したが、すべてのプラグインが正常に動作する場合は、アップグレードタイムアウトエラーが原因である可能性があります。コンポーネントセンターが csi-plugin コンポーネントをアップグレードするときにタイムアウトエラーが発生した場合、コンポーネントセンターは自動的にアップグレードをロールバックします。この問題を解決するには、チケットを送信 します。

ディスクのトラブルシューティング

重要
  • ディスクをポッドにマウントするには、ディスクとポッドをホストするノードが同じリージョンとゾーンに存在することを確認します。異なるリージョンまたはゾーンで作成された場合、ディスクをノードにマウントできません。

  • Elastic Compute Service (ECS) でサポートされるディスクカテゴリは、インスタンスタイプによって異なります。詳細については、「インスタンスファミリの概要」をご参照ください。

ポッドのステータスが Running ではない

問題

PVC のステータスは Bound ですが、ポッドのステータスは Running ではありません。

原因

  • スケジュールに使用できるノードがありません。

  • システムがディスクをマウントするときにエラーが発生します。

  • ECS インスタンスが指定されたディスクタイプをサポートしていません。

解決策

PVC のステータスが Bound ではない

問題

PVC のステータスは Bound ではなく、ポッドのステータスは Running ではありません。

原因

  • 静的:PVC と永続ボリューム (PV) のセレクターが特定の条件を満たしていません。そのため、PV と PVC を関連付けることができません。たとえば、PVC のセレクター構成が PV のセレクター構成と異なっている、セレクターが異なる StorageClass 名を使用している、または PV のステータスが Release であるなどです。

  • 動的:csi-provisioner コンポーネントがディスクの作成に失敗します。

解決策

  • 静的:関連する YAML コンテンツを確認します。詳細については、「静的にプロビジョニングされたディスクボリュームを使用する」をご参照ください。

    説明

    PV のステータスが Release の場合、PV は再利用できません。ディスクを使用するには、新しい PV を作成する必要があります。

  • 動的:kubectl describe pvc <pvc-name> -n <namespace> コマンドを実行して、PVC イベントを表示します。

  • ECS API を呼び出してディスクを作成するときにエラーが発生した場合は、「ErrorCode」を参照して問題をトラブルシューティングします。問題が解決しない場合は、チケットを送信 します。

NAS のトラブルシューティング

重要
  • NAS ファイルシステムをノードにマウントするには、ノードと NAS ファイルシステムが同じ VPC (Virtual Private Cloud) にデプロイされていることを確認します。ノードと NAS ファイルシステムが異なる VPC にデプロイされている場合は、クラウドエンタープライズネットワーク (CEN) を使用して接続します。

  • NAS ファイルシステムとは異なるゾーンにデプロイされているノードに NAS ファイルシステムをマウントできます。

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

ポッドのステータスが Running ではない

問題

PVC のステータスは Bound ですが、ポッドのステータスは Running ではありません。

原因

  • NAS ファイルシステムのマウント時に fsGroups が使用されています。大量のファイルを処理する必要があるため、chmod が遅くなります。

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

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

解決策

  • fsGroups が構成されているかどうかを確認します。構成されている場合は、fsGroups を削除し、ポッドを再起動して、NAS ファイルシステムを再度マウントしてみてください。

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

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

  • その他の原因については、kubectl describe pods <pod-name> コマンドを実行して、ポッドイベントを表示します。

PVC のステータスが Bound ではない

問題

PVC のステータスは Bound ではなく、ポッドのステータスは Running ではありません。

原因

  • 静的:PVC と PV のセレクターが特定の条件を満たしていません。そのため、PV と PVC を関連付けることができません。たとえば、PVC のセレクター構成が PV のセレクター構成と異なっている、セレクターが異なる StorageClass 名を使用している、または PV のステータスが Release であるなどです。

  • 動的:csi-provisioner コンポーネントが NAS ファイルシステムのマウントに失敗します。

解決策

OSS のトラブルシューティング

重要
  • OSS バケットをノードにマウントする場合は、PV で AccessKey ペアを指定する必要があります。AccessKey ペアはシークレットに保存できます。

  • OSS バケットとノードが異なるリージョンに作成されている場合は、バケット URL を OSS バケットのパブリックエンドポイントに設定します。OSS バケットとノードが同じリージョンに作成されている場合は、OSS バケットの内部エンドポイントを使用することをお勧めします。

ポッドのステータスが Running ではない

問題

PVC のステータスは Bound ですが、ポッドのステータスは Running ではありません。

原因

  • OSS バケットのマウント時に fsGroups が使用されています。大量のファイルを処理する必要があるため、chmod が遅くなります。

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

解決策

  • fsGroups が構成されているかどうかを確認します。構成されている場合は、fsGroups を削除し、ポッドを再起動して、OSS バケットを再度マウントしてみてください。

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

  • その他の原因については、kubectl describe pods <pod-name> コマンドを実行して、ポッドイベントを表示します。

PVC のステータスが Bound ではない

問題

PVC のステータスは Bound ではなく、ポッドのステータスは Running ではありません。

原因

  • 静的:PVC と PV のセレクターが特定の条件を満たしていません。そのため、PV と PVC を関連付けることができません。たとえば、PVC のセレクター構成が PV のセレクター構成と異なっている、セレクターが異なる StorageClass 名を使用している、または PV のステータスが Release であるなどです。

  • 動的:csi-provisioner コンポーネントが OSS バケットのマウントに失敗します。

解決策