Container Service for Kubernetes:ディスクボリュームに関するよくある質問

動的な PV 作成の失敗：InvalidDataDiskCategory.NotSupported

事象

PV の作成に失敗し、PVC イベントにエラーメッセージ InvalidDataDiskCategory.NotSupported が表示されます。

原因

StorageClass で指定されたクラウドディスクタイプが現在のゾーンで利用できないか、在庫が不足しています。

解決策

• CSI プラグインをアップグレードし、alicloud-disk-topology-alltype StorageClass を使用するか、複数のクラウドディスクタイプを持つカスタム StorageClass を作成します。 詳細については、「動的にプロビジョニングされたディスクボリュームを使用する」をご参照ください。

• クラスターに複数のゾーンを追加します。 詳細については、「ディスクボリュームの高可用性構成の推奨事項」をご参照ください。

動的な PV 作成の失敗：AZone の在庫不足

事象

PV の作成に失敗し、PVC イベントにエラーメッセージ The specified AZone inventory is insufficient が表示されます。

原因

指定されたゾーンの在庫が不足しているため、クラウドディスクの作成に失敗します。

解決策

• CSI プラグインをアップグレードし、alicloud-disk-topology-alltype StorageClass を使用するか、複数のクラウドディスクタイプを持つカスタム StorageClass を作成します。 詳細については、「動的にプロビジョニングされたディスクボリュームを使用する」をご参照ください。

• クラスターに複数のゾーンを追加します。 詳細については、「ディスクボリュームの高可用性構成の推奨事項」をご参照ください。

動的な PV 作成の失敗：ディスクサイズがサポートされていない

事象

動的な PV の作成に失敗し、PVC イベントにエラーメッセージ disk size is not supported が表示されます。

原因

PVC には無効な容量が指定されています。最小値はクラウドディスクタイプによって異なります。

解決策

PVC で宣言された容量をサポートされている値に調整してください。

動的な PV 作成の失敗：最初のコンシューマーを待機中

事象

WaitForFirstConsumer バインディングモードの StorageClass を使用すると PV の作成に失敗し、PVC イベントにエラーメッセージ persistentvolume-controller waiting for first consumer to be created before binding が表示されます。

原因

PVC が Pod のスケジュール先のノードを検出できていません。

• アプリケーションの YAML ファイルで nodeName を明示的に設定すると、Pod がスケジューラーをバイパスします。これにより、PVC がノードを検出できなくなり、WaitForFirstConsumer バインディングモードと互換性がなくなります。

• 現在の PVC を参照している Pod がありません。

解決策

• アプリケーションの YAML ファイルから nodeName フィールドを削除し、別のスケジューリング方法を使用してください。

• 現在の PVC を使用する Pod を作成してください。

動的な PV 作成の失敗：CSINode に topologyKey がない

事象

PV の作成に失敗し、PVC イベントにエラーメッセージ no topology key found on CSINode node-XXXX が表示されます。

原因

• 原因1：対応するノード node-XXXX 上の CSI プラグインの起動に失敗しています。

• 原因2：システムでサポートされていないドライバーがマウントに使用されています。デフォルトでは、システムは Disk、NAS、OSS ドライバーをサポートしています。

解決策

1. Pod のステータスを確認します。

   kubectl get pods -n kube-system -o wide | grep node-XXXX

   • Pod が異常なステータスの場合：kubectl logs csi-plugin-xxxx -n kube-system -c csi-plugin コマンドでエラーログを確認します。これは通常、ノードのポート競合が原因です。次のように解決します。

     • ポートを占有しているプロセスを終了します。

     • CSI プラグインに SERVICE_PORT 環境変数を追加して、新しいポートを指定します。

       kubectl set env -n kube-system daemonset/csi-plugin --containers="csi-plugin" SERVICE_PORT="XXX"

   • ステータスが正常な場合は、次の手順に進んでください。

2. Disk、NAS、OSS などのデフォルトのシステムドライバーを使用してください。 詳細については、「ストレージドキュメント」をご参照ください。

動的な PV 作成の失敗：selfLink が空

事象

PV の作成に失敗し、PVC イベントにエラーメッセージ selfLink was empty, can't make reference が表示されます。

原因

1. クラスターのバージョンと CSI プラグインのバージョンが一致していません。

2. クラスターが FlexVolume ストレージプラグインを使用しています。

解決策

1. CSI プラグインのバージョンをアップグレードしてください。プラグインのバージョンは、クラスターのバージョンと互換性がある必要があります。たとえば、Kubernetes 1.20 クラスターには CSI バージョン 1.20 以降が必要です。

2. クラスターで FlexVolume ストレージプラグインを使用している場合は、「FlexVolume から CSI への移行」をご参照ください。

動的な PV 作成の失敗：PVC 容量が 20 GiB 未満

デフォルトの ACK StorageClass (例：alicloud-disk-topology-alltype、alicloud-disk-essd) では、最小容量が 20 GiB 必要です。より小さいボリュームの場合は、ESSD AutoPL や ESSD PL0 など、より低い容量をサポートするディスクタイプを使用してカスタム StorageClass を作成してください。

• 詳細については、「動的にプロビジョニングされたディスクボリュームを使用する」をご参照ください。

• ディスクタイプごとの容量範囲については、「ブロックストレージのパフォーマンス」をご参照ください。

Pod 起動の失敗：ボリュームノードアフィニティの競合

現象

クラウドディスクがマウントされた Pod の起動が失敗し、Pod イベントにエラーメッセージ had volume node affinity conflict が表示されます。

原因

すべての PV には nodeaffinity プロパティがあります。このエラーは、PV の nodeaffinity と Pod の nodeaffinity が競合し、スケジューリングできない場合に発生します。

ソリューション

PV の nodeaffinity と Pod の nodeaffinity が一致していることを確認してください。

Pod 起動の失敗：ディスクが見つからない

現象

クラウドディスクがマウントされた Pod の起動が失敗し、Pod イベントにエラーメッセージ can't find disk が表示されます。

原因

• PV に誤ったクラウドディスク ID または別のリージョンのクラウドディスク ID が設定されています。

• アカウントにクラウドディスクへのアクセス権限がありません。クラウドディスクが別のアカウントに属している可能性があります。

ソリューション

• 静的にプロビジョニングされたクラウドディスクを使用している場合は、次の要件を満たしているか確認してください。

  • クラウドディスクのリージョンがクラスターのリージョンと同じであること。

  • クラウドディスク ID が正しいこと。

  • クラウドディスクとクラスターが同じ Alibaba Cloud アカウントに属していること。

• クラウドディスクが動的にマウントされている場合は、CSI プラグインの権限を確認してください。

  クラスターに Addon Token が存在するか確認します。

  • Addon Token が存在する場合は、クラスターの CSI プラグインのバージョンを確認し、プラグインを最新バージョンにアップグレードしてから再試行してください。

  • Addon Token が存在しない場合は、デフォルトでノードのワーカー RAM ロールのカスタム AccessKey が使用されます。対応する RAM ポリシーの権限を確認する必要があります。

Pod 起動の失敗：アタッチアクション処理中

現象

クラウドディスクがマウントされた Pod に Previous attach action is still in process と表示されますが、数秒後に正常に起動します。

原因

ECS インスタンスは一度に 1 つのクラウドディスクをアタッチします。複数のディスクを利用する Pod が同じホストに配置される場合、ディスクは順次アタッチされます。このメッセージは、別のアタッチが進行中であることを意味します。

ソリューション

対応は不要です。システムが自動的に再試行します。

Pod 起動の失敗：InvalidInstanceType.NotSupportDiskCategory

現象

クラウドディスクがマウントされた Pod を起動すると、エラーメッセージ InvalidInstanceType.NotSupportDiskCategory が表示されます。

原因

Pod が、このクラウドディスクタイプをサポートしていないインスタンスタイプの ECS ノードにスケジュールされています。

ソリューション

次のいずれかを試してください。

• クラスターに、このクラウドディスクタイプをサポートするインスタンスタイプの ECS ノードがあり、Pod がそのノードにスケジュールできることを確認してください。

• このクラウドディスクタイプをサポートするインスタンスタイプのノードがない場合は、互換性のあるディスクタイプに切り替えてください。

Pod 起動の失敗：CSI ドライバーが登録されていない

現象

Pod を起動すると、次の警告が表示されます。

Warning  FailedMount       98s (x9 over 3m45s)  kubelet, cn-zhangjiakou.172.20.XX.XX  MountVolume.MountDevice failed for volume "d-xxxxxxx": kubernetes.io/csi: attacher.MountDevice failed to create newCsiDriverClient: driver name diskplugin.csi.alibabacloud.com not found in the list of registered CSI drivers

原因

• これは通常、新しいノードで発生します。アプリケーション Pod が、同時に起動中の CSI プラグインの登録が完了する前にボリュームをマウントしようとします。

• ノード上の CSI プラグインの登録が失敗しました。起動の失敗が原因である可能性があります。

ソリューション

• 新しく追加されたノードでは、対応は不要です。システムが自動的に再試行します。

• CSI プラグインの登録に失敗した場合は、そのステータスとログを確認してください。 プラグインが正常な場合は、DingTalk ユーザーグループ (ID: 35532895) に参加してサポートを依頼してください。

Pod 起動の失敗：マルチアタッチエラー

現象

クラウドディスクをマウントする Pod のイベントに warning failedAttachVolume xxx xxx Multi-Attach error for volume "xxx" と表示されます。kubectl describe pvc <pvc-name> を実行すると、複数の Pod が同じ PVC を参照していることがわかります。

原因

• 原因 1：マルチアタッチが有効になっていない場合、クラウドディスクは 1 つの Pod にのみマウントできます。

• 原因 2：PVC を使用している Pod が削除されましたが、クラウドディスクが適切にアンマウントされませんでした。

  ECS コンソールで、PVC のクラウドディスクがアタッチされているノードを特定し、そのノード上の CSI プラグインポッドのログを確認します。Path is mounted, no remove: /var/lib/kubelet/plugins/kubernetes.io/csi/diskplugin.csi.alibabacloud.com/xxx/globalmount が表示された場合は、CSI プラグインが /var/run HostPath を直接マウントしていることを確認してください。

  kubectl get ds -n kube-system csi-plugin -ojsonpath='{.spec.template.spec.volumes[?(@.hostPath.path=="/var/run/")]}'

  出力が空でない場合、この問題が確認されます。

ソリューション

• 原因 1 の解決策：

  PVC を参照する Pod が 1 つのみであることを確認してください。

• 原因 2 の解決策：

  CSI プラグインの YAML ファイルに手動でパッチを適用します。

  kubectl patch -n kube-system daemonset csi-plugin -p '
  spec:
    template:
      spec:
        containers:
          - name: csi-plugin
            volumeMounts:
              - mountPath: /host/var/run/efc
                name: efc-metrics-dir
              - mountPath: /host/var/run/ossfs
                name: ossfs-metrics-dir
              - mountPath: /host/var/run/
                $patch: delete
        volumes:
          - name: ossfs-metrics-dir
            hostPath:
              path: /var/run/ossfs
              type: DirectoryOrCreate
          - name: efc-metrics-dir
            hostPath:
              path: /var/run/efc
              type: DirectoryOrCreate
          - name: fuse-metrics-dir
            $patch: delete'

Pod 起動の失敗：マウントタイムアウト

現象

ボリュームがマウントされた Pod を起動すると、Pod イベントにエラーメッセージ Unable to attach or mount volumes: unmounted volumes=[xxx], unattached volumes=[xxx]: timed out waiting for the condition が表示されます。

原因

このイベントは、kubelet によって報告されるエラーメッセージです。kubelet は、すべてのノード上の Pod が使用するボリュームが Ready 状態であるかを定期的にチェックします。ボリュームが Ready でない場合、上記のエラーメッセージが表示されます。

このイベントは、チェック時にマウントが完了していなかったことを示します。考えられる原因は次のとおりです。

• 原因 1：マウントエラーが発生しましたが、詳細なイベントが上書きされました。kubelet のエラーイベントのみが残っています。

• 原因 2：kubelet が ConfigMap/ServiceAccount default-token を取得する際にタイムアウトします。これはノードのネットワークの問題です。別のノードで再試行する必要があります。

• 原因 3：securityContext.fsGroup が設定されている場合、kubelet はマウント時にすべてのファイルの所有権を再帰的に変更します。これは、多数のファイルを含むボリュームでは低速です。

• 原因 4：静的にプロビジョニングされたボリュームの場合、driver フィールドが正しい (誤字がない) ことを確認してください。driver 名が正しくないと、ボリュームが Ready 状態になりません。

ソリューション

• 原因 1 の解決策：Pod を削除して再起動し、実際のエラーイベントを見つけて診断してください。

• 原因 2 の解決策: ポッドを別のノードに再スケジュールします。詳細については、「アプリケーションを指定ノードにスケジュールする」をご参照ください。

• 原因 3 の解決策: バージョン 1.20+ のクラスターでは、fsGroupChangePolicy を OnRootMismatch に設定します。これにより、ルートディレクトリの権限が異なる場合、再帰的な所有権の変更は最初のマウントに限定され、後続の Pod 再起動時のマウント時間が正常化されます。fsGroupChangePolicy パラメーターの詳細については、「Pod またはコンテナーのセキュリティコンテキストを設定する」をご参照ください。それでも不十分な場合は、initContainer を使用して権限を調整します。

• 原因 4 の解決策：正しいドライバー名を確認して指定してください。例：

  • diskplugin.csi.alibabacloud.com

  • nasplugin.csi.alibabacloud.com

  • ossplugin.csi.alibabacloud.com

Pod 起動の失敗：NVMe の無効なデバイス形式

現象

クラウドディスクがマウントされた Pod の起動が失敗し、Pod イベントにエラーメッセージ validate error Device /dev/nvme1n1 has error format more than one digit locations が表示されます。

原因

ノードが NVMe ベースのインスタンスタイプ (g7se、r7se、c7se、または第 8 世代 ECS など) ですが、クラスターと CSI プラグインのバージョンが古すぎてサポートされていません。

ソリューション

お使いの ACK クラスターがバージョン 1.20 以降であることを確認し、CSI プラグインを v1.22.9-30eb0ee5-aliyun 以降にアップグレードしてください。詳細については、「コンポーネントの管理」をご参照ください。

Pod 起動の失敗：ECS タスクの競合

現象

クラウドディスクがマウントされた Pod の起動が失敗し、Pod イベントにエラーメッセージ ecs task is conflicted が表示されます。

原因

一部の ECS タスクは順次実行する必要があります。複数のリクエストが同時に ECS に送信されると、ECS タスクの競合エラーが発生します。

ソリューション

解決策：

• CSI プラグインが自動的に再試行するまでお待ちください。他の ECS タスクが完了すると、マウントが成功します。

• 「クラウドディスクの並列アタッチメントを有効にする」をご参照ください。

Pod 起動の失敗：破損したファイルシステム

現象

クラウドディスクがマウントされた Pod の起動が失敗し、Pod イベントに次のエラーメッセージが表示されます。

wrong fs type, bad option, bad superblock on /dev/xxxxx  missing codepage or helper program, or other error

原因

ファイルシステムが破損しているため、クラウドディスクをマウントできません。

ソリューション

これは通常、不適切なアンマウントが原因です。解決するには：

1. アプリケーションが次の要件を満たしていることを確認してください。

   • 同じクラウドディスクをマウントする Pod が 1 つ以下であること。

   • ディスクのデタッチプロセス中にデータを書き込まないこと。

2. Pod のホストにログオンし、fsck -y /dev/xxxxx を実行してファイルシステムを修復してください。

   /dev/xxxxx を Pod イベントのデバイスパスに置き換えてください。修復によりファイルシステムのメタデータが変更されます。修復が失敗すると、ファイルシステムが永久に破損します。

Pod 起動の失敗：最大ボリューム数を超過

現象

クラウドディスクがマウントされた Pod が Pending 状態のままでスケジュールできません。ECS インスタンスタイプではより多くのディスクアタッチが許可されているにもかかわらず、次のメッセージが表示されます。

0/1 nodes are available: 1 node(s) exceed max volume count.

原因

スケジューリングが MAX_VOLUMES_PERNODE 環境変数によって制限されています。

Pod 起動の失敗：インスタンスディスク制限に到達

現象

クラウドディスクがマウントされた Pod が ContainerCreating 状態のままです。Pod イベント：

MountVolume.MountDevice failed for volume "d-xxxx": rpc error: code = Aborted desc = NodeStageVolume: Attach volume: d-xxxx with error: rpc error: code = Internal desc = SDK.ServerError
ErrorCode: InstanceDiskLimitExceeded
Message: The amount of the disk on instance in question reach its limits

原因

MAX_VOLUMES_PERNODE 環境変数の値が高すぎます。

OperationDenied.HpnZoneMismatch エラー（Lingjun ノード）

クラウドディスクに、Lingjun ノードに必要な attachToHpnZone:XX タグがありません。このタグは、ディスク作成時にのみ追加できます。タグ付きの新しいクラウドディスクを作成してください。

1. ECS コンソール - ブロックストレージに移動します。

2. 作成時に次のタグを追加します (後から追加することはできません)。

   • createdByProduct:eflo

   • attachToHpnZone:XX (XX を、ノードをクエリするコマンドを実行して取得した実際の HpnZone に置き換えます。)

   詳細については、「空のデータディスクを作成する」をご参照ください。

3. 古い PV と PVC を削除し、交換用のクラウドディスクで新しいものを作成します。 詳細については、「静的にプロビニングされたディスクボリュームを使用する」または「動的にプロビニングされたディスクボリュームを使用する」をご参照ください。

デフォルト StorageClass の設定変更

デフォルト StorageClass は変更できません。

csi-provisioner のインストール後、デフォルトの StorageClass (例: alicloud-disk-topology-alltype) が作成されます。デフォルトの StorageClass は変更せず、代わりに希望するボリュームタイプまたはリクラメーションポリシーを使用して新しい StorageClass を作成してください。

複数のアプリケーションでの単一ディスクボリュームの使用

クラウドディスクは非共有ストレージです。マルチアタッチが有効になっていない場合、クラウドディスクは 1 つのポッドにのみマウントできます。詳細については、「クラウドディスクで NVMe ベースのマルチアタッチを有効にし、予約を設定する」をご参照ください。

ディスクボリュームのアプリケーション I/O エラー

現象

クラウドディスクは正常にマウントされ、アプリケーションは起動しますが、その直後に 入出力エラー を報告します。

原因

アプリケーションが使用しているクラウドディスクがデタッチまたは削除されています。

解決策

クラウドディスクのステータスを確認し、ステータスに基づいて対処してください。

1. 影響を受けるマウントディレクトリに対応する Pod の VolumeMount 定義から PVC を特定します。

2. kubectl get pvc <pvc-name> を実行して PVC のステータスを確認し、バインドされている PV をメモします。

3. PV の YAML ファイル内にある volumeHandle フィールドからクラウドディスク ID を取得します。

4. ECS コンソールの ブロックストレージ ページで、クラウドディスク ID に基づいてクラウドディスクのステータスを確認します。

   • クラウドディスクが [利用可能] の場合、アンマウントされています。Pod を再起動して再マウントします。

     説明

     Pod が Running 状態であることは、ディスクがマウントされた後にアンマウントされたことを示します。これは、複数の Pod が同じディスクを参照していることが原因である可能性があります。kubectl describe pvc <pvc-name> を実行して UsedBy を確認してください。

   • クラウドディスクが見つからない場合、リリース済みであり、回復不能です。

     重要

     ESSD をマウントする際は、自動スナップショットを使用してディスクボリュームのデータを保護してください。詳細については、「予期しないクラウドディスクの削除によるデータ損失」をご参照ください。

マウントディレクトリのユーザー権限の設定

クラウドディスクのユーザーアクセス権限は設定できません。マウントディレクトリのユーザーアクセス権限を設定する必要がある場合は、アプリケーションの作成時に Pod の securityContext を設定して権限を変更します。詳細については、「Pod のボリューム権限と所有権の変更ポリシーを設定する」をご参照ください。

ディスクボリュームの自動拡張

ディスクボリュームは自動的に拡張されないため、拡張するには PVC ストレージ容量を更新する必要があります。詳細については、「ディスクボリュームのオンライン拡張」をご参照ください。

自動拡張を有効にするには、使用量がしきい値を超えたときに CRD を使用してボリュームを拡張します。詳細については、「自動拡張を構成する」をご参照ください。

ディスク拡張の失敗：ユーザーによるPodの再起動待ち

現象

PVC のストレージ容量を更新した後、PVC ステータスの StorageCapacity フィールドが変更されず、PVC イベントに次のメッセージが表示されます。

 Waiting for user to (re-)start a pod to finish file system resize of volume on node.

原因

クラウドディスクの拡張には、ResizeDisk API によるディスク容量の拡張と、ファイルシステムの拡張という 2 つのステップがあります。このエラーは、ステップ 1 は成功したもののステップ 2 が失敗し、ノードレベルの問題が発生していることを示します。

解決策

現在のノードのタイプを確認します。

• ノードが ECI の場合は、kubectl get configmap -n kube-system eci-profile -o jsonpath="{.data.enablePVCController}" を実行し、値が true であることを確認します。詳細については、「eci-profile 設定パラメーター」をご参照ください。

  問題が解決しない場合は、チケットを送信してサポートを依頼してください。

• ノードが ECS の場合、kubectl get pods -n kube-system -l app=csi-plugin --field-selector=spec.nodeName=<node-name> を実行して CSI プラグインのステータスを確認してください。

  • CSI プラグインが正常な場合は、DingTalk ユーザーグループ (ID: 35532895) に参加して、サポートを依頼してください。

  • 異常な場合は、CSI プラグイン Pod を再起動して再試行してください。問題が解決しない場合は、DingTalk ユーザーグループ (ID: 35532895) に参加してサポートを依頼してください。

ディスク拡張の失敗：静的PVCまたはサイズ変更が許可されていない

現象

PVC のストレージ容量を更新した後、次のエラーが表示されます。

only dynamically provisioned pvc can be resized and the storageclass that provisions the pvc must support resize 

原因

• 原因 1：ディスクボリュームの PVC と PV が静的な方法で手動で作成されています。PVC の storageClassName パラメータが指定されていないか、指定された名前の StorageClass がクラスターに存在しません。

• 原因 2：PVC が参照する StorageClass で、allowVolumeExpansion パラメータが false に設定されているため、拡張はサポートされていません。

解決策

• 原因 1 の解決策：PVC の storageClassName 構成を確認し、同じ名前の StorageClass がクラスターに存在することを確認してください。存在しない場合は、既存のディスクボリュームのプロパティに基づいて対応する StorageClass を作成し、allowVolumeExpansion: true を設定してください。

• 原因 2 の解決策：StorageClass は不変です。allowVolumeExpansion パラメータを true に設定した新しい StorageClass を作成してください。PVC の storageClassName は変更できないため、新しい StorageClass を使用するには、新しい PVC を作成してデータを移行する必要があります。

Pod 削除の失敗：ポータブルディスクではない

現象

クラウドディスクをアンマウントすると、エラーメッセージ The specified disk is not a portable disk が表示されます。

原因

クラウドディスクの課金方法がサブスクリプションになっています。これは、サブスクリプションのディスクを購入したか、ECS インスタンスのアップグレード時に課金方法を変更したことが原因と考えられます。

解決策

クラウドディスクの課金方法を従量課金に変更してください。

Pod 削除の失敗：オーファン Pod によるアンマウント失敗

現象

Pod のアンマウントが失敗し、kubelet ログに ACK で管理されていないオーファン Pod が表示されます。

原因

Pod が異常終了し、オーファンのボリュームマウントポイントが残っています。Kubernetes 1.22 より前のバージョンでは、kubelet のボリューム GC が不完全なため、手動でのクリーンアップが必要です。

解決策

問題のあるノードで次のスクリプトを実行して、不要なマウントポイントをクリーンアップします。

wget https://raw.githubusercontent.com/AliyunContainerService/kubernetes-issues-solution/master/kubelet/kubelet.sh
sh kubelet.sh

Pod 再起動の失敗：回復不能なマウント失敗

現象

削除後、Pod が再起動できず、回復不能なマウント失敗が報告されます。

Warning FailedMount 9m53s (x23 over 40m) kubelet MountVolume.SetUp failed for volume "xxxxx" : rpc error: code = Internal desc = stat /var/lib/kubelet/plugins/kubernetes.io/csi/pv/xxxxx/globalmount: no such file or directory

対象

• ACK クラスターのバージョンが 1.20.4-aliyun-1 です。

• アプリケーションがストレージメディアとしてクラウドディスクを使用しています。

• StatefulSet が使用され、 podManagementPolicy: "Parallel" プロパティが設定されています。

原因

「高速な再起動後に Pod が起動に失敗する」をご参照ください。

解決策

• 新しいノードを追加し、古いノードを削除します。障害のある Pod は自動的に復旧します。詳細については、「ノードプールの作成と管理」および「ノードの削除」をご参照ください。

• StatefulSet の podManagementPolicy を OrderedReady に変更するか、 podManagementPolicy: "Parallel" フィールドを削除します。

• 小規模クラスターの場合：

  1. cordon を使用して、Pod のノードをスケジュール不可に設定します。

  2. Pod を削除し、ステータスが Pending になるまで待ちます。

  3. ノードの cordon を解除し、Pod が再起動するまで待ちます。

• 大規模クラスターの場合、Pod は別のノードにスケジュールされると回復します。

Pod 削除の失敗：ターゲットがビジー状態

現象

Pod を削除すると、Pod イベントまたは kubelet ログ (/var/log/messages) に次のメッセージが表示されます。

unmount failed, output <mount-path> target is busy

原因

プロセスがまだデバイスを使用しています。ホストにログオンして、プロセスを特定し終了してください。

解決策

1. 対応するマウントパスにあるブロックデバイスを見つけます。

   mount | grep <mount-path>
   /dev/vdtest <mount-path>

2. ブロックデバイスを使用しているプロセスの ID を見つけます。

   fuser -m /dev/vdtest

3. プロセスを終了します。

   プロセスが終了すると、クラウドディスクは自動的にアンマウントされます。

PVC 削除後もクラウドディスクが残る

現象

PVC を削除しても、ECS コンソールにクラウドディスクが残ります。

原因

• 原因 1：PV の reclaimPolicy が Retain であるため、PVC 削除後も PV とクラウドディスクが保持されます。

• 原因 2：PVC と PV が同時に削除されたか、PVC の前に PV が削除されました。

解決策

• 原因 1 の解決策：reclaimPolicy が Retain に設定されている場合、CSI は PVC が削除されても PV やクラウドディスクを削除しません。手動で削除してください。

• 原因 2 の解決策: PV に deleteTimestamp アノテーションがある場合、CSI はクラウドディスクを回収しません。コントローラーをご参照ください。代わりに PVC を削除してください。バインドされた PV は自動的にクリーンアップされます。

削除後も PVC が残る

現象

--force フラグを使用しても PVC の削除が失敗します。

原因

Pod がまだ PVC を使用しているため、ファイナライザー が削除を防ぎます。

解決策

1. PVC を参照している Pod を表示します。

   kubectl describe pvc <pvc-name> -n kube-system

2. 参照している Pod が使用されていないことを確認し、削除してから、PVC の削除を再試行してください。

ボリュームの課金方法をサブスクリプションに変更

ボリュームとして使用するクラウドディスクは従量課金である必要があり、サブスクリプションに変更することはできません。

ECS コンソールでボリュームに対応するクラウドディスクを特定

クラウドディスク ID (d-******** フォーマット) を取得し、ECS コンソールの ブロックストレージ ページで該当するクラウドディスク ID を検索して、関連付けられているクラウドディスクを特定します。

• 動的に作成された PV の場合、PV 名がクラウドディスク ID です。クラスターの ボリューム > ボリューム ページで確認できます。

• PV 名がクラウドディスク ID ではない場合は、kubectl get pv <pv-name> -o yaml を実行してください。volumeHandle フィールドにクラウドディスク ID が含まれています。