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

「InvalidDataDiskCatagory.NotSupported」エラーによる PV の動的作成の失敗

現象

永続ボリューム (PV) の作成に失敗します。永続ボリューム要求 (PVC) のイベントにエラー InvalidDataDiskCategory.NotSupported が表示されます。

原因

現在のゾーンが StorageClass で指定されたディスクタイプをサポートしていないか、指定されたディスクタイプが現在のゾーンで在庫切れです。

ソリューション

• Container Storage Interface (CSI) コンポーネントをアップグレードし、alicloud-disk-topology-alltype という名前の StorageClass を使用します。または、複数のディスクタイプを宣言するカスタム StorageClass を作成して使用します。詳細については、「動的にプロビジョニングされたディスクボリュームの使用」をご参照ください。

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

「The specified AZone inventory is insufficient」エラーによる PV の動的作成の失敗

現象

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

原因

指定されたゾーンでディスクが在庫切れです。これにより、ディスクの作成が失敗します。

ソリューション

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

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

「disk size is not supported」エラーによる PV の動的作成の失敗

現象

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

原因

PVC で指定されたディスク容量が無効です。ディスクタイプごとに最小容量要件が異なります。ディスク容量要件の詳細については、「ディスクタイプ」をご参照ください。

ソリューション

要件を満たすように PVC で指定された容量を調整してください。

「waiting for first consumer to be created before binding」エラーによる PV の動的作成の失敗

現象

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

原因

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

• アプリケーションの YAML ファイルで nodeName が明示的に指定されています。これらの Pod はスケジューラのロジックをバイパスするため、PVC がノードを検出できません。したがって、nodeName を指定してスケジュールされた Pod は、WaitForFirstConsumer モードの StorageClass を使用できません。

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

ソリューション

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

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

「no topology key found on CSINode node-XXXX」エラーによる PV の動的作成の失敗

現象

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

原因

• node-XXXX ノード上の csi-plugin が起動に失敗しました。

• ボリュームがシステムでサポートされていないドライバーを使用しています。システムはデフォルトで Disk、NAS、OSS をサポートしています。

ソリューション

1. Pod が Normal 状態であるかどうかを確認します。

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

   • 状態が異常な場合は、kubectl logs csi-plugin-xxxx -nkube-system -c csi-plugin コマンドを実行してエラーログを確認します。ほとんどの場合、原因はノード上のポート競合です。この問題は、次のいずれかの方法で解決できます：

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

     • csi-plugin に SERVICE_PORT 環境変数を追加して、新しいポートを指定します。

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

   • 状態が Normal の場合は、次のステップに進みます。

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

「selfLink was empty, can't make reference」エラーによる PV の動的作成の失敗

現象

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 への移行」をご参照ください。

要求された PVC 容量が 20 GiB 未満の場合の PV の動的作成の失敗

ディスクタイプによってサポートされる容量範囲は異なります。ACK が提供するデフォルトの StorageClass (alicloud-disk-topology-alltype や alicloud-disk-essd など) を使用する場合、自動的に作成されるディスク (たとえば、PL1 ESSD) の最小容量は 20 GiB です。ストレージ要件が 20 GiB 未満の場合は、手動で StorageClass を作成し、ESSD AutoPL ディスクや PL0 ESSD など、20 GiB 未満の容量をサポートするディスクタイプを指定する必要があります。

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

• さまざまなディスクタイプでサポートされる容量範囲の詳細については、「Elastic Block Storage のパフォーマンス」をご参照ください。

ディスクボリュームを持つ Pod の「had volume node affinity conflict」エラーによる起動失敗

現象

ディスクボリュームを持つ Pod の起動に失敗します。Pod のイベントにエラー had volume node affinity conflict が表示されます。

原因

すべての PV には nodeaffinity プロパティがあります。このエラーは、PV の nodeaffinity プロパティが Pod の nodeaffinity プロパティと一致しない場合に発生します。この競合のため、スケジューラは Pod をスケジュールできません。

ソリューション

PV または Pod の nodeaffinity プロパティを変更して、それらの nodeaffinity プロパティが一致するようにします。

ディスクボリュームを持つ Pod の「can't find disk」エラーによる起動失敗

現象

ディスクボリュームを持つ Pod の起動に失敗します。Pod のイベントにエラー can't find disk が表示されます。

原因

• PV の設定時に、不正なディスク ID または別のリージョンのディスク ID が入力されました。

• ご利用のアカウントにディスクに対する操作権限がありません。ディスクが別のアカウントに属している可能性があります。

ソリューション

• ディスクが静的にアタッチされている場合は、ディスクが次の要件を満たしているか確認してください：

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

  • ディスク ID が正しくコピーされていること。

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

• ディスクが動的にアタッチされている場合は、CSI コンポーネントの権限を確認してください。

  クラスターにアドオントークンが存在するかどうかを確認します。

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

  • AccessKey が提供されていない場合、デフォルトでノードのワーカーロールのユーザー定義 AccessKey が使用されます。対応するポリシーの権限を確認する必要があります。

ディスクボリュームを持つ Pod の「Previous attach action is still in process」エラーによる起動失敗

現象

ディスクボリュームを持つ Pod を起動すると、エラー Previous attach action is still in process が報告されます。数秒後に Pod は正常に起動します。

原因

Elastic Compute Service (ECS) は、単一の仮想マシンに複数のディスクを同時にアタッチすることをサポートしていません。そのため、ディスクボリュームを持つ複数の Pod が同じホストにスケジュールされると、ディスクは直列にアタッチされます。このメッセージは、現在別のディスクがノードにアタッチ中であることを示します。

ソリューション

対応は不要です。システムは成功するまで自動的にリトライします。

ディスクボリュームを持つ Pod の「InvalidInstanceType.NotSupportDiskCategory」エラーによる起動失敗

症状

ディスクボリュームを持つ Pod を起動すると、エラー InvalidInstanceType.NotSupportDiskCategory が報告されます。

原因

ディスクタイプと ECS インスタンスタイプが一致しません。Pod がスケジュールされた ECS ノードがこのディスクタイプをサポートしていないため、アタッチに失敗します。

ソリューション

問題を解決するために、次の方法を試してください：

• ECS ノードのインスタンスタイプを確認します。このディスクタイプをサポートする ECS ノードが存在することを確認し、Pod がそのノードにスケジュールされるようにスケジューリングが設定されていることを確認してください。

• 現在の ECS ノードのインスタンスタイプがこのディスクタイプをサポートしていない場合は、別のタイプのディスクを使用してください。

ディスクボリュームを持つ Pod の「diskplugin.csi.alibabacloud.com not found in the list of registered CSI drivers」エラーによる起動失敗

現象

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

原因

• この警告は通常、新しく追加されたノードで発生します。CSI Pod はアプリケーション Pod と同時に起動しますが、CSI の登録には時間がかかります。アプリケーション Pod がアタッチプロセスを開始したときに CSI がまだ登録されていないため、この警告が発生します。

• 現在のノード上の CSI コンポーネントが登録に失敗しました。これは、CSI コンポーネントが正しく起動しなかったことが原因である可能性があります。

ソリューション

• 警告が新しいノードに対するものである場合、対応は不要です。システムがリトライするのを待ってください。

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

ディスクボリュームを持つ Pod の「Multi-Attach error for volume」エラーによる起動失敗

現象

ディスクボリュームを持つ Pod の起動に失敗します。Pod のイベントに警告 warning failedAttachVolume xxx xxx Multi-Attach error for volume "xxx" が表示されます。kubectl describe pvc <pvc-name> コマンドを実行すると、複数の Pod が同じ PVC を参照していることがわかります。

原因

• 原因 1：マルチアタッチが有効になっていないディスクは、一度に 1 つの Pod にしかアタッチできません。複数の Pod で同時に使用することはできません。

• 原因 2：PVC を使用していた Pod は削除されましたが、PVC に対応するディスクが正しくデタッチされませんでした。

  ECS コンソールで、PVC に対応するディスクが現在アタッチされているノードを見つけます。次に、そのノードの csi-plugin Pod のログでメッセージ Path is mounted, no remove: /var/lib/kubelet/plugins/kubernetes.io/csi/diskplugin.csi.alibabacloud.com/xxx/globalmount を確認します。次のコマンドを実行して、csi-plugin が /var/run HostPath を直接マウントしているかどうかを確認します：

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

  出力が空でない場合、直接マウントが存在し、問題が確認されます。

ソリューション

• 原因 1 のソリューション：

  複数の Pod が同じ PVC を参照しないようにしてください。

• 原因 2 のソリューション：

  次のコマンドを実行して、csi-plugin の 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 の「Unable to attach or mount volumes: unmounted volumes=[xxx], unattached volumes=[xxx]: timed out waiting for the condition」エラーによる起動失敗

現象

ストレージボリュームを持つ Pod の起動に失敗します。Pod のイベントにエラー Unable to attach or mount volumes: unmounted volumes=[xxx], unattached volumes=[xxx]: timed out waiting for the condition が表示されます。

原因

このエラーメッセージは kubelet によって報告されます。kubelet は、すべてのノード上の Pod で使用されるボリュームが準備完了かどうかを定期的にチェックします。ボリュームが準備完了でない場合、このエラーが発生します。

このイベントは特定の問題を示すものではなく、その時点でアタッチが完了していなかったことを意味するだけです。考えられる原因は次のとおりです：

• 原因 1：アタッチエラーが発生しました。エラーが長時間続いたため、関連するイベントが期限切れになり、上書きされました。kubelet のエラーイベントのみが残っています。

• 原因 2：kubelet が configmap/serviceaccount defaulttoken を取得しようとしてタイムアウトしました。これはノードのネットワークの問題です。唯一の解決策は、別のノードを試すことです。

• 原因 3：Pod テンプレートで securityContext.fsGroup パラメーターが設定されている場合、ディスクボリュームがアタッチされるときにボリューム内のファイルの所有者が自動的に変更されます。ファイルの数によっては、準備に時間がかかることがあります。

• 原因 4：ボリュームが静的にアタッチされている場合、ボリュームの driver フィールドが正しいことを確認してください。たとえば、スペルミスがないか確認します。このフィールドが正しくないと、kubelet は正しい driver を見つけて呼び出すことができず、ボリュームが準備完了状態にならなくなります。

ソリューション

• 原因 1 のソリューション：Pod を削除して再起動します。その後、エラーイベントを見つけて特定の問題を特定します。

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

• 原因 3 のソリューション：Kubernetes バージョン 1.20 以降のクラスターでは、fsGroupChangePolicy を OnRootMismatch に設定できます。これにより、Pod が初めて起動するときにのみファイル所有者が変更されます。Pod のアップグレードや再作成などの後続のシナリオでは、ボリュームのアタッチ時間は正常になります。fsGroupChangePolicy パラメーターの詳細については、「Pod またはコンテナのセキュリティコンテキストを設定する」をご参照ください。これがニーズを満たさない場合は、initContainer を使用してカスタムの権限調整操作を実装してください。

• 原因 4 のソリューション：正しいドライバー名を入力してください。例：

  • diskplugin.csi.alibabacloud.com

  • nasplugin.csi.alibabacloud.com

  • ossplugin.csi.alibabacloud.com

ディスクボリュームを持つ Pod の「validate error Device /dev/nvme1n1 has error format more than one digit locations」エラーによる起動失敗

現象

ディスクボリュームを持つ Pod の起動に失敗します。Pod のイベントにエラー validate error Device /dev/nvme1n1 has error format more than one digit locations が表示されます。

原因

ノードが g7se、r7se、c7se、または第 8 世代の ECS インスタンスタイプを使用しており、クラスターと CSI コンポーネントのバージョンが古すぎて NVMe タイプのノードでのディスクアタッチをサポートしていません。

ソリューション

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

ディスクボリュームを持つ Pod の「ecs task is conflicted」エラーによる起動失敗

現象

ディスクボリュームを持つ Pod の起動に失敗します。Pod のイベントにエラー ecs task is conflicted が表示されます。

原因

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

ソリューション

次のいずれかのソリューションを選択できます：

• しばらく待ちます。CSI は自動的に操作をリトライします。他のタスクが完了すると、CSI はリトライ時にディスクを正常にアタッチします。

• 詳細については、「並列ディスクアタッチの使用」をご参照ください。

ディスクボリュームを持つ Pod の「wrong fs type, bad option, bad superblock on /dev/xxxxx missing codepage or helper program, or other error」エラーによる起動失敗

現象

ディスクボリュームを持つ Pod の起動に失敗します。Pod のイベントに次のエラーが表示されます。

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

原因

ディスク上のファイルシステムが破損しており、ディスクをアタッチできません。

ソリューション

これは通常、ディスクの不適切なデタッチによって引き起こされます。問題を解決するには、次の手順に従ってください。

1. アプリケーションがディスクを使用する際に、次の要件を満たしているか確認してください：

   • 複数の Pod が同じディスクにアタッチされていないこと。

   • デタッチプロセス中にデータが書き込まれていないこと。

2. Pod が配置されているホストにログインし、fsck -y /dev/xxxxx コマンドを実行してディスク上のファイルシステムを修復します。

   このコマンドの /dev/xxxxx は、Pod イベントのエラーメッセージに対応します。ディスクファイルシステムの修復は、ファイルシステムのメタデータを変更します。修復が失敗するか完了できない場合、ディスク上のファイルシステムは破損しており、もはや使用できません。

ディスクボリュームを持つ Pod の「exceed max volume count」エラーによる起動失敗

現象

ディスクボリュームを持つ Pod が長時間 Pending 状態のままでスケジュールされません。しかし、ECS インスタンスタイプに基づくと、ノードにはさらに多くのディスクをアタッチできます。Pod のイベントに次のエラーが表示されます。

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

原因

Pod のスケジューリングは、MAX_VOLUMES_PERNODE 環境変数で指定された数によって制限されます。

ディスクボリュームを持つ Pod の「The amount of the disk on instance in question reach its limits」エラーによる起動失敗

現象

ディスクボリュームを持つ 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 環境変数が高すぎます。

デフォルトのディスク StorageClass の構成を変更する方法

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

csi-provisioner コンポーネントをインストールすると、alicloud-disk-topology-alltype などの StorageClass がクラスターにデフォルトで作成されます。これらのデフォルトの StorageClass は変更しないでください。ボリュームタイプやリクレームポリシーなどの StorageClass 構成を調整するには、新しい StorageClass を作成します。StorageClass の数に制限はありません。詳細については、「StorageClass の作成」をご参照ください。

複数のコンテナ化されたアプリケーションで同じディスクボリュームを使用できるか

ディスクは共有ストレージではありません。マルチアタッチが有効になっていないディスクは、一度に 1 つの Pod にしかアタッチできません。マルチアタッチの詳細については、「NVMe ディスクのマルチアタッチと予約の使用」をご参照ください。

ディスクマウントディレクトリへの読み書き時にアプリケーションが「input/output error」を報告する

現象

ディスクは正しくアタッチされ、アプリケーションは正常に起動します。しかし、しばらくすると、アプリケーションが突然 input/output error を報告します。

原因

アプリケーションが使用しているディスクが見つかりません。

ソリューション

ディスクの状態を確認し、その状態に基づいて対処してください。

1. ディスクマウントディレクトリに基づいて、Pod の VolumeMount 定義から対応する PVC を見つけます。

2. kubectl get pvc <pvc-name> コマンドを実行して PVC の状態を表示し、対応する PV をメモします。

3. PV 名に基づいて、PV の YAML ファイルを表示し、pv.VolumeHandle フィールドからディスク ID を取得します。

4. ECS コンソールの[Elastic Block Storage] ページで、ディスク ID を使用してディスクのステータスを確認します。

   • ディスクの状態が [利用可能] の場合、ディスクはデタッチ済みです。ディスクを再アタッチするには、Pod を再起動します。

     説明

     Pod は Running 状態であり、これはディスクが以前にアタッチされ、その後デタッチされたことを意味します。これは、複数の Pod が同じディスクを参照していたことを示唆しています。kubectl describe pvc <pvc-name> コマンドを実行し、出力の UsedBy フィールドを確認して、複数の Pod が現在の PVC を参照しているかどうかを確認してください。

   • ディスクが見つからない場合、ディスクは解放されており、回復できません。

     重要

     エンタープライズ SSD (ESSD) をアタッチする場合、ESSD の自動スナップショット機能を使用してディスクボリューム上のデータを保護してください。詳細については、「予期しないディスク削除によるデータ損失」をご参照ください。

ディスクボリュームのマウントディレクトリのユーザーアクセス権限を設定する方法

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

ディスクボリュームは自動的に拡張されるか

デフォルトでは、ディスクボリュームの容量が使い果たされても自動的に拡張されません。ディスクボリュームを拡張するには、PVC のストレージ容量宣言を手動で更新する必要があります。詳細については、「ディスクボリュームのオンライン拡張」をご参照ください。

自動拡張が必要な場合は、カスタムリソース定義 (CRD) を使用して自動ディスク拡張ポリシーを定義します。これにより、ボリュームの使用量が特定のしきい値を超えたときに自動的に拡張されます。詳細については、「自動拡張の設定」をご参照ください。

「Waiting for user to (re-)start a pod to finish file system resize of volume on node」エラーによるディスク拡張の失敗

現象

PVC のストレージ容量宣言を更新した後、PVC のステータスの StorageCapacity が変更されず、PVC イベントに次のメッセージが報告されます：

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

原因

ディスクの拡張には 2 つの部分が含まれます：ResizeDisk API 操作を呼び出してディスク容量を拡張することと、ファイルシステムを拡張することです。このエラーメッセージは、基盤となるブロックデバイスは拡張されたが、ファイルシステムの拡張に失敗したことを示します。これはノード側の問題を示唆しています。

ソリューション

現在のノードのタイプを特定します。

• 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-plugin のステータスを取得します。

  • csi-plugin が正常な状態の場合、DingTalk ユーザーグループ (グループ ID: 35532895) に参加して相談してください。

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

「only dynamically provisioned pvc can be resized and the storageclass that provisions the pvc must support resize」エラーによるディスク拡張の失敗

現象

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 のプロパティは変更できません。新しい StorageClass を作成し、allowVolumeExpansion を true に設定し、次に PVC を変更して新しい StorageClass を参照させ、最後に PVC を拡張する必要があります。

ディスクボリュームを持つ Pod の「The specified disk is not a portable disk」エラーによる削除失敗

現象

ディスクをデタッチすると、エラー The specified disk is not a portable disk が報告されます。

原因

ディスクの課金方法はサブスクリプションです。サブスクリプションディスクをリクエストしたか、ECS インスタンスのアップグレード時に ECS インスタンスに関連付けられたディスクをサブスクリプション課金方法に変換した可能性があります。

ソリューション

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

ディスクがデタッチできず、kubelet ログに孤立した Pod が見つかることによるディスクボリュームを持つ Pod の削除失敗

現象

Pod のデタッチに失敗し、ACK によって管理されていない Pod のログが kubelet に表示されます。

原因

Pod が異常終了したため、デタッチプロセス中にボリュームマウントポイントがクリーンアップされませんでした。これにより、最終的に Pod の削除が妨げられます。Kubernetes v1.22 より前では、kubelet のボリュームに対するガベージコレクション (GC) プロセスが完全には実装されておらず、未解決のマウントポイントを手動またはスクリプトでクリーンアップする必要がありました。

ソリューション

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

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

ディスクボリュームを持つ Pod の削除後、マウント失敗で Pod が再起動できず、自動回復しない

現象

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" プロパティセットと共に使用されています。

原因

詳細については、GitHub の issue Pod fails to start after restarting rapidly をご参照ください。

ソリューション

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

• StatefulSet を orderedready に変更するか、podManagementPolicy: "Parallel" プロパティを削除します。

• クラスターのノード数が少ない場合は、次のソリューションを使用してください。

  1. Pod が配置されているノードに cordon ラベルを追加して、ノードをスケジュール不可にします。

  2. Pod を削除し、そのステータスが Pending に変わるのを待ちます。

  3. ノードから cordon ラベルを削除し、Pod が再起動するのを待ちます。

• クラスターに多数のノードがある場合は、Pod を別のノードにスケジュールできます。Pod は正常に起動します。

ディスクボリュームを持つ Pod の「target is busy」エラーによる削除失敗

現象

Pod を削除すると、Pod イベントまたは kubelet ログ (/var/log/messages) に次のエラーが報告されます。

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

原因

プロセスがデバイスを使用しているため、Pod の削除に失敗しました。Pod が配置されているホストにログインして、プロセスを見つける必要があります。

ソリューション

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 が同時に削除されたか、PV が PVC より先に削除されました。

ソリューション

• 原因 1 のソリューション：reclaimPolicy が Retain に設定されている場合、CSI は PVC が削除されても PV とディスクを削除しません。手動で削除する必要があります。

• 原因 2 のソリューション：PV に deleteTimestamp annotation がある場合、CSI はディスクリソースの回収を担当しません。詳細については、「controller」をご参照ください。ディスクリソースを削除するには、単に PVC を削除します。削除された PVC にバインドされた PV は自動的にクリーンアップされます。

PVC の削除に失敗し、削除後も PVC が存在する

現象

クラスター内の PVC が、--force フラグを使用しても削除に失敗します。

原因

クラスター内の Pod が PVC を使用しています。PVC の finalizer がまだ存在するため、PVC の削除が妨げられています。

ソリューション

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

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

2. 参照している Pod が使用されなくなったことを確認した後、Pod を削除し、再度 PVC の削除を試みます。

ボリュームとして使用されるディスクをサブスクリプション課金方法に変換できるか

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

ECS コンソールの Elastic Block Storage ページでボリュームに関連付けられたディスクを特定する方法

ディスクボリュームに関連付けられたディスクの ID（フォーマット：d-********）を取得します。次に、ECS コンソールの [Elastic Block Storage] ページで、ディスク ID を使用して、どのディスクがボリュームに関連付けられているかを特定します。

• デフォルトでは、動的に作成されたディスク PV の名前はディスク ID です。ディスク ID は、クラスターの [ストレージ] > [永続ボリューム] ページで確認できます。

• ディスク PV の名前がディスク ID でない場合は、kubectl get pv <pv-name> -o yaml コマンドを実行してディスク PV の詳細を表示します。volumeHandle フィールドの値がディスク ID です。