Container Service for Kubernetes:ディスクボリュームに関するFAQ

動的にプロビジョニングされたPVを作成するときに、システムがInvalidDataDiskCatagory.NotSupportedをプロンプトするのはなぜですか。

問題

動的にプロビジョニングされたPVの作成に失敗し、永続ボリューム要求 (PVC) イベントInvalidDataDiskCatagory.NotSupportedが生成されます。

原因

ゾーンが永続ボリューム (PV) の作成に使用されるStorageClassで指定されたディスクタイプをサポートしていないか、または指定されたタイプのディスクがゾーン内で不足しています。

解決策

• PVの作成に使用するStorageClassで複数のディスクタイプを指定します。 詳細については、「動的にプロビジョニングされたディスクボリュームの使用」をご参照ください。 または、クラスターで使用されるContainer Storage Interface (CSI) プラグインを最新バージョンに更新することもできます。 この方法では、alicloud-disk-topology-alltype StorageClassを使用してPVを作成できます。

• 新しいゾーンのノードをクラスターに追加します。 詳細については、「クロスゾーンデプロイの推奨ストレージ設定」をご参照ください。

動的にプロビジョニングされたPVを作成するときに、システムプロンプトが指定されたAZoneインベントリが不十分であるのはなぜですか。

問題

動的にプロビジョニングされたPVの作成に失敗し、システムがPVCイベントを生成します。指定されたAZoneインベントリが不十分です。

原因

Elastic Compute Service (ECS) インスタンスが不足しているため、システムはディスクの作成に失敗しました。

解決策

• PVの作成に使用するStorageClassで複数のディスクタイプを指定します。 詳細については、「動的にプロビジョニングされたディスクボリュームの使用」をご参照ください。 または、クラスターで使用されるCSIプラグインを最新バージョンに更新することもできます。 この方法では、alicloud-disk-topology-alltype StorageClassを使用してPVを作成できます。

• 新しいゾーンのノードをクラスターに追加します。 詳細については、「クロスゾーンデプロイの推奨ストレージ設定」をご参照ください。

動的にプロビジョニングされたPVを作成するときに、システムプロンプトのディスクサイズがサポートされないのはなぜですか。

問題

PVを動的にプロビジョニングしようとすると失敗し、PVCイベントが生成されます。ディスクサイズはサポートされていません。

原因

PVCで指定されたディスクサイズが無効です。 最小ディスクサイズの制限は、ディスクタイプによって異なります。 たとえば、ウルトラディスクまたはSSDのサイズは20 GiB以上でなければなりません。 詳細については、「ディスク」トピックのディスクカテゴリセクションを参照してください。

解決策

要件を満たすように、PVCで指定されたディスクサイズを変更します。

動的にプロビジョニングされたPVを作成するときに、システムプロンプトが最初のコンシューマーの作成前にバインドされるのを待つのはなぜですか。

問題

StorageClassをWaitForFirstConsumerモードで使用してPVの作成に失敗し、システムがPVCイベントを生成します。persistentvolume-controller waiting for first consumer before created before binding.

原因

関連するPVCは、アプリケーションポッドがスケジュールされているノードを認識していません。

• nodeNameパラメーターは、関連するPVCを使用するアプリケーションの設定で指定されます。 この場合、ポッドのスケジューリングはスケジューラをバイパスします。 その結果、PVCは、アプリケーションポッドがスケジュールされるノードを認識しない。 したがって、WaitForFirstConsumerモードでStorageClassesを使用して、nodeNameパラメーターが指定されているアプリケーションのPVを動的にプロビジョニングすることはできません。

• 関連するPVCはポッドでは使用されません。 この場合、ポッドを作成し、ポッド構成でPVCを指定します。

解決策

• アプリケーション設定からnodeNameパラメーターを削除します。

• ポッドを作成し、ポッド構成でPVCを指定します。

動的にプロビジョニングされたPVを作成するときに、システムがCSINodeノード-XXXXにトポロジキーを表示しないのはなぜですか。

問題

動的にプロビジョニングされたPVの作成に失敗し、システムがPVCイベントを生成します。CSINodeノード-XXXXにトポロジキーが見つかりません。

原因

• 原因1: ノードXXXX上のCSIプラグインが起動に失敗した。

• 原因2: ボリュームで使用されるドライバがサポートされていません。 デフォルトでは、ディスク、File Storage NAS (NAS) ファイルシステム、およびObject Storage Service (OSS) バケットのみがサポートされます。

解決策

1. 次のコマンドを実行して、ポッドのステータスを照会します。

   kubectl get pods -nkube-system -owide | grep node-XXXX

   • ポッドの状態が異常な場合は、kubectl logs csi-plugin-xxxx -nkube-system -c csi-pluginコマンドを実行して、エラーログを出力します。 エラーログは、ノードのほとんどのポートが占有されていることを示します。 このシナリオでは、次の手順を実行します。

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

     • 次のコマンドを実行して、SERVICE_PORT環境パラメーターをCSIプラグインに追加します。

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

   • ポッドが正常な状態の場合は、次の手順に進みます。

2. ディスク、NASファイルシステム、OSSバケットなど、サポートされているドライバーを使用するボリュームをマウントします。 他のドライバを使用するには、

   チケットを起票してサポートセンターにお問い合わせくださいしてサポートセンターにお問い合わせください。

動的にプロビジョニングされたPVを作成するときに、システムプロンプト「selfLinkが空でした。参照できません」が表示されるのはなぜですか。

発行

PVの作成に失敗し、システムがPVCイベントを生成します。selfLinkが空だった、参照できません。

原因

1. クラスターのKubernetesバージョンがCSIバージョンと一致しません。

2. クラスターはFlexVolumeを使用します。

解決策

1. CSIバージョンを更新します。 ボリュームプラグインのバージョンがクラスターのKubernetesバージョンと一致していることを確認します。 たとえば、お使いのクラスターのKubernetesバージョンが1.20の場合は、CSI 1.20以降をインストールします。

2. クラスターがFlexVolumeを使用している場合は、FlexVolumeからCSIへの移行を実行します。 詳細については、「csi-compatible-controllerを使用したFlexVolumeからCSIへの移行」をご参照ください。

ディスクがマウントされているポッドを起動したときに、ボリュームノードのアフィニティが競合するのはなぜですか。

問題

ディスクがマウントされているポッドの起動に失敗し、システムのプロンプトでボリュームノードのアフィニティ競合が発生しました。

原因

PV構成のnodeaffinity属性を、ポッド構成のnodeaffinity属性とは異なる値に設定します。 したがって、ポッドを適切なノードにスケジュールすることはできません。 各PVは、nodeaffinity属性を有する。

解決策

PVまたはポッドのnodeaffinity属性を変更して、PVとポッドが同じ値を使用するようにします。

ディスクがマウントされているポッドを起動すると、システムプロンプトでディスクが見つからないのはなぜですか。

問題

ディスクがマウントされているポッドの起動に失敗し、システムのプロンプトがディスクを見つけることができません。

原因

• DiskIDパラメーターを、ポッドがデプロイされているリージョン以外のリージョンのディスクに対応する値に設定します。

• PVを設定するときに、DiskIDパラメーターに無効な値を入力しました。

• アカウントには、DiskIDパラメーターを変更する権限がありません。 指定したディスクは、現在のアカウントに属していない可能性があります。

解決策

ディスクが静的プロビジョニングボリュームまたは動的プロビジョニングボリュームとしてマウントされているかどうかを確認します。

• ディスクが静的にプロビジョニングされたボリュームとしてマウントされている場合は、DiskIDパラメーターが次の要件を満たしていることを確認します。

  • DiskIDパラメーターの値は、ポッドがデプロイされているリージョンのディスクに対応しています。

  • DiskIDパラメーターの値は、使用するディスクのIDに設定されます。

  • DiskIDパラメーターの値は、クラスターと同じAlibaba Cloudアカウントに属するディスクに対応しています。

• ディスクが動的にプロビジョニングされたボリュームとしてマウントされている場合は、クラスターで使用されるCSIプラグインの権限が次の要件を満たしていることを確認してください。

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

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

  • Addon Tokenがクラスターに存在しない場合、CSIプラグインは、ワーカーノードに割り当てられたResource Access Management (RAM) ロールのAccessKey IDとAccessKey secretを使用します。 RAMロールにアタッチされているRAMポリシーを確認する必要があります。

ディスクがマウントされているポッドを起動すると、以前のアタッチアクションがまだ処理中であるというプロンプトが表示されるのはなぜですか。

問題

ディスクがマウントされているポッドを起動すると、以前のアタッチ操作はまだ処理中と表示されます。 ポッドは数秒後に起動します。

原因

複数のディスクを同時にECSインスタンスにマウントすることはできません。 ディスクがマウントされている複数のポッドがECSインスタンスにスケジュールされている場合、一度にマウントできるディスクは1つだけです。 システムが「以前のアタッチアクションはまだ処理中です」とプロンプトした場合、ディスクはこのノードにマウントされています。

解決策

操作は必要ありません。 ポッドが起動するまで、システムは自動的に再試行します。

ディスクがマウントされているポッドを起動すると、システムがInvalidInstanceType.NotSupportDiskCategoryを要求するのはなぜですか。

問題

ディスクがマウントされ、システムプロンプトがInvalidInstanceType.NotSupportDiskCategoryであるポッドの起動に失敗しました。

原因

ディスクタイプはECSインスタンスでサポートされていません。

解決策

「インスタンスファミリーの概要」を参照し、ECSインスタンスでサポートされているディスクの種類を確認します。 ECSインスタンスでサポートされているディスクをポッドにマウントします。

ディスクがマウントされているポッドを起動diskplugin.csi.alibabacloud.comと、登録済みのCSIドライバのリストにシステムプロンプトが表示されないのはなぜですか。

問題

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

原因

1. 警告は通常、新しく作成されたノードに表示されます。 システムは、CSIポッドおよびサービスポッドを同時に開始し、CSIを登録するために一定の時間を必要とする。 したがって、サービスポッドにボリュームをマウントするときに、CSI登録が完了していない可能性があります。 これにより、警告がトリガーされます。

2. CSIプラグインが期待どおりに実行されないため、CSI登録が失敗しました。

解決策

1. 操作は必要ありません。 ポッドが起動するまで、システムは自動的に再試行します。

2. CSIプラグインのステータスとログを確認します。 CSIプラグインが期待どおりに実行される場合は、DingTalkグループ35532895に参加してテクニカルサポートをリクエストしてください。

ディスクがマウントされているポッドを起動すると、なぜシステムはボリュームのマルチアタッチエラーを要求するのですか?

問題

ディスクボリュームを使用するポッドの起動に失敗し、警告failedAttachVolume xxx xxx Multi-Attachエラーfor volume "xxx" が表示されます。 kubectl describe pvc <pvc-name> コマンドを実行すると、出力は複数のポッドが同じPVCを使用していることを示します。

原因

• 原因1: デフォルトでは、各ディスクは1つのポッドでのみ使用できます。 ディスクを複数のポッドにマウントすることはできません。

• 原因2: PVCがマウントされているポッドは削除されますが、PVCに対応するディスクは保持されます。 ECSコンソールにログインし、PVCに対応するディスクがマウントされているノードを表示します。 ノード上のcsi-pluginのポッドログを印刷します。 ログには、パスがマウントされています。削除なし: /var/lib/kubelet/plugins/kubernetes.io/cs i/diskplugin.csi.alibabacloud.com/xxx/globalmountが含まれています。 同時に、次のコマンドを実行して、/var/runのホストパスがcsi-pluginコンポーネントにマウントされているかどうかを確認します。

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

  出力が空でない場合、/var/runのホストパスがCSIプラグインにマウントされ、問題が発生します。

解決策

原因1の解決策:

PVCが1つのポッドでのみ使用されていることを確認します。

原因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'

ディスクボリュームを使用するポッドを起動すると、[ボリュームをアタッチまたはマウントできない: unmounted volumes=[xxx], unattached volumes=[xxx]: timed out waiting for the condition] というプロンプトが表示されるのはなぜですか。

問題

ディスクボリュームを使用するポッドの起動に失敗し、[ボリュームをアタッチまたはマウントできません: unmounted volumes=[xxx], unattached volumes=[xxx]: timed out waiting for the condition] を表示します。

原因

上記のポッドイベントはkubeletによって生成されます。 kubeletは、クラスターノード上のポッドが使用するボリュームのステータスを定期的にチェックします。 ボリュームが準備できていない場合、kubeletはイベントを生成します。

解決策

• 原因1の解決策: ポッドを削除し、システムがポッドを再作成するのを待ちます。 次に、エラーに対応するイベントを見つけ、イベントの内容に基づいて原因を特定します。

• 原因2の解決策: ポッドを別のノードにスケジュールします。 詳細については、「特定のノードへのポッドのスケジュール」をご参照ください。

• 原因3の解決策: Kubernetesバージョン1.20以降を実行するクラスターの場合、fsGroupChangePolicyをOnRootMismatchに設定します。 ポッドのアップグレードや再作成などの後続のシナリオでは、マウント時間は通常に戻ります。 fsGroupChangePolicyパラメーターの詳細については、「ポッドまたはコンテナーのセキュリティコンテキストの構成」をご参照ください。 要件を満たしていない場合は、initContainerを使用してビジネス要件に基づいて権限を調整することを推奨します。

• 原因4の解決策: ドライバー名を有効な値に設定します。 例：

  • diskplugin.csi.alibabacloud.com

  • nasplugin.csi.alibabacloud.com

  • ossplugin.csi.alibabacloud.com

ディスクボリュームを使用するポッドを起動するときに、システムプロンプトがエラーを検証するのはなぜですか。Device /dev/nvme1n1にエラー形式が複数の桁の場所があります。

問題

ディスクボリュームを使用するポッドの起動に失敗し、システムがエラーの検証を要求します。Device /dev/nvme1n1にはエラー形式が1桁以上の場所があります。

原因

g7se、r7se、c7se、または第8世代のECSインスタンスタイプがクラスターで使用され、クラスターのバージョンまたはクラスターで使用されるCSIプラグインは、NVMe (Non-Volatile Memory Express) ディスクをサポートしていません。

解決策

クラスターを1.20以降に更新し、クラスターで使用するCSIプラグインのバージョンを1.22.9-30eb0ee5-aliyun以降に更新します。 プラグインの更新方法の詳細については、「コンポーネントの管理」をご参照ください。

ディスクがマウントされているポッドを起動すると、システムプロンプトecsタスクが競合するのはなぜですか。

問題

ディスクがマウントされているポッドの起動に失敗し、システムがポッドイベントecs task is conflictedを生成しました。

原因

特定のECSタスクを1つずつ実行する必要があります。 ECSインスタンスが複数のリクエストを同時に受信した場合、ECSタスク間で競合が発生する可能性があります。

解決策

1. CSIプラグインがボリュームプロビジョニングを自動的に再試行するのを待ちます。 競合するECSタスクが実行されると、CSIプラグインは自動的にディスクをポッドにマウントします。

2. 問題が解決しない場合は、

   ECSチームにチケットを送信します。

ディスクがマウントされているポッドを起動したときに、システムが間違ったfsタイプ、悪いオプション、/dev/xxxxxの悪いスーパーブロックにコードページやヘルパープログラムがない、またはその他のエラーを表示するのはなぜですか?

問題

ディスクがマウントされているポッドの起動に失敗し、システムは次のポッドイベントを生成します。

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

原因

ディスクのファイルシステムが破損しています。

解決策

ほとんどの場合、この問題はディスクが誤ってアンマウントされているために発生します。 問題を解決するには、次の手順を実行します。

1. ディスクが要件を満たしているかどうかを確認します。

   • ディスクが1つのポッドにのみマウントされていることを確認します。

   • ディスクをアンマウントするときは、ディスクにデータが書き込まれていないことを確認してください。

2. ポッドのホストにログオンし、fsck -y /dev/xxxxxコマンドを実行して、ディスクのファイルシステムを修復します。

   /dev/xxxxxエラーは、ポッドイベントに対応しています。 システムはまた、ディスクのファイルシステムを修復するときに、ファイルシステムのメタデータを復元する。 修復が失敗すると、ディスクのファイルシステムが完全に破損し、使用できなくなります。

ディスクボリュームがマウントされているポッドを起動すると、システムプロンプトが「最大ボリューム数を超える」のはなぜですか?

発行

ディスクボリュームがマウントされているポッドを起動した後、ポッドは長期間Pending状態のままです。 そのため、ポッドをスケジュールできません。 ノードのECSインスタンスタイプは、より多くのディスクボリュームをノードにマウントできることを示します。 次のポッドイベントが生成されます。

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

問題

ポッドスケジューリングは、MAX_VOLUMES_PERNODE環境変数によって制限されます。

ディスクボリュームがマウントされているポッドを起動すると、システムが「問題のインスタンス上のディスクの量が制限に達します」とプロンプトを表示するのはなぜですか?

発行

ディスクボリュームがマウントされているポッドを起動した後、ポッドは長期間ContainerCreating状態のままです。 次のポッドイベントが生成されます。

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環境変数の値が大きすぎます。

ディスクがマウントされているポッドを削除すると、指定されたディスクがポータブルディスクではないというプロンプトが表示されるのはなぜですか。

問題

ディスクのアンマウント時に、指定されたディスクはポータブルディスクではありませんというプロンプトが表示されます。

原因

ディスクが関連付けられているECSインスタンスをアップグレードしたときに、ディスクの課金方法を誤ってサブスクリプションに切り替えたか、ディスクの課金方法をサブスクリプションベースで課金されます。

解決策

ディスクの課金方法をサブスクリプションから従量課金に切り替えます。

ディスクがマウントされているポッドを削除し、ACKで管理されていない孤立したポッドがkubeletログに見つかったときに、ディスクをマウントできないというシステムプロンプトが表示されるのはなぜですか。

問題

ポッドの削除に失敗し、kubeletはACKで管理されないポッドログを生成します。

原因

ポッドが例外的に終了すると、システムがPVをアンマウントするときにマウントターゲットは削除されません。 その結果、ポッドの削除に失敗しました。 1.22より前のバージョンのKubernetesでは、データボリュームのkubeletのガベージコレクション機能は成熟していません。 手動またはスクリプトを実行して、無効なマウントターゲットを削除する必要があります。

解決策

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

システムが削除されたポッドの再作成に失敗し、マウントが失敗したことを示すプロンプトが表示された場合はどうすればよいですか?

問題

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

この問題は、次の条件を満たす場合に発生します。

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

• ディスクはアプリケーションにマウントされます。

• アプリケーションはStatefulSetを使用してデプロイされ、podManagementPolicy: "Parallel" 設定が指定されています。

原因

詳細については、「ポッドが迅速に再起動後に起動できない」をご参照ください。

解決策

• クラスターに新しいノードを追加し、元のノードをすべて削除します。 ポッドは自動的に再作成されます。 詳細については、「ノードプールの作成」および「ノードの削除」をご参照ください。

• StatefulSetをorderedreadyに設定するか、podManagementPolicy: "Parallel" 設定を削除します。

• クラスターに含まれるノード数が少ない場合は、次のソリューションを使用します。

  1. ポッドがデプロイされているノードにcordonラベルを追加して、ノードをスケジュール不可として設定します。

  2. ポッドを削除し、ポッドのステータスが [保留中] に変わるまで待ちます。

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

• クラスターに多数のノードが含まれている場合は、ポッドを別のノードにスケジュールします。 次に、ポッドを再作成できます。

ディスクがマウントされているポッドを削除すると、システムプロンプトのターゲットがビジーになるのはなぜですか?

問題

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

原因

ポッドに取り付けられたディスクは使用中です。 ポッドが実行されているホストにログオンし、ディスクを使用するプロセスを照会します。

解決策

1. 次のコマンドを実行して、マウントパスのディスクを照会します。

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

2. 次のコマンドを実行して、ディスクを使用するプロセスのIDを照会します。

   fuser -m /dev/vdtest

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

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

動的にプロビジョニングされたPVのPVCを削除した後にディスクが保持されるのはなぜですか。

発行

動的にプロビジョニングされたPVのPVCを削除した後も、ディスクはECSコンソールに保持されます。

原因

1. PVCがクラスター内の既存のStorageClassを使用しているかどうかを確認します。 そうでない場合、静的にプロビジョニングされたPVが使用される。

2. StorageClassのreclaimPolicyがRetainに設定されているかどうかを確認します。

3. PVCとPVは同時に削除されるか、PVCが削除される前にPVが削除されます。

解決策

1. CSIは、静的にプロビジョニングされたPVおよびそれらのPVCを削除しない。 ACKコンソールにログインするか、API操作を呼び出して手動で削除する必要があります。

2. reclaimPolicyがRetainに設定されていても、CSIは静的にプロビジョニングされたPVとPVCを削除しません。 ACKコンソールにログインするか、API操作を呼び出して手動で削除する必要があります。

3. deleteTimestampアノテーションがPVに追加された場合、CSIはディスクを再利用しません。 詳細については、「controller」をご参照ください。 ディスクを削除するには、PVCのみを削除します。 その後、PVCにバインドされたPVは自動的に削除されます。

削除した後もPVCがまだ存在するのはなぜですか?

発行

-- forceコマンドを実行して、クラスター内のPVCを削除できませんでした。

原因

クラスター内のポッドはまだPVCを使用しています。 PVCのファイナライザーは削除できません。

解決策

1. 次のコマンドを実行して、PVCを使用するポッドを照会します。

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

2. ポッドが使用されなくなったことを確認します。 ポッドを削除し、PVCを再度削除してみます。

システムが動的にディスクを拡張できず、Waiting for user to start a pod to finish file system resize of volume on node PVCイベントを生成できないのはなぜですか?

問題

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

原因

ディスクボリュームの拡張には、ディスクサイズの拡張とファイルシステムの拡張が含まれます。 ディスクサイズはECS APIを使用して拡張されます。 このエラーは、ディスクサイズが拡張されたが、ファイルシステムの拡張に失敗したことを示します。 ファイルシステムの拡張障害は、ノードに関連する問題が原因です。

解決策

システムがディスクを動的に拡張できず、pvcを変更するときに「動的にプロビジョニングされたpvcのみサイズ変更でき、PVCをプロビジョニングするストレージクラスはサイズ変更をサポートする必要があります」とプロンプトを表示するのはなぜですか。

発行

CLIまたはコンソールを使用してPVCのStorageClassを変更すると、次のエラーが返されます。

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

原因

原因1: PVCに対応するPVは静的にプロビジョニングされています。 静的にプロビジョニングされたボリュームを動的に拡張することはできません。

原因2: PVCのStorageClassでallowVolumeExpansionパラメーターがfalseに設定されています。 PVを動的に拡張することはできない。

解決策

原因1: 静的にプロビジョニングされたボリュームを手動で拡張します。 詳細については、「手動でディスクボリュームを拡張する」をご参照ください。

原因2の解決策: PVCのStorageClassでallowVolumeExpansionパラメーターをtrueに設定します。 次に、対応するPVを展開します。

アプリケーションがディスクボリュームのマウントディレクトリで読み取りおよび書き込み操作を実行するときに、システムが入出力エラーを表示するのはなぜですか。

問題

ディスクがマウントされているアプリケーションを正常に開始しました。 しかし、システムは、アプリケーションが起動された直後に入力 /出力エラーを促す。

原因

アプリケーションにマウントされているディスクがありません。

解決策

ディスクのステータスを確認し、問題を修正します。

1. マウントディレクトリとVolumeMountアプリケーションポッドの設定のパラメーターを指定します。

2. kubectl get pvc <pvc-name> コマンドを実行して、PVCのステータスを照会します。 PVCを使用してプロビジョニングされたPVの名前を記録します。

3. 名前でPVのYAMLファイルを見つけ、ディスクIDをpv.VolumeHandleパラメーターを使用します。

4. ECSコンソールにログインし、ディスクIDに基づいてディスクステータスを表示します。

   • ディスクの状態が [使用可能] の場合、ディスクはアンマウントされています。 ポッドを再起動して、ディスクを再度マウントできます。

     ポッドが [実行中] 状態の場合、ディスクはマウントされてからアンマウントされています。 この場合、ディスクは複数のポッドで使用できます。 kubectl describe pvc <pvc-name> コマンドを実行して、UsedByコンテンツに基づいてPVCが複数のポッドによって参照されているかどうかを確認できます。

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

     重要

     Enterprise SSD (ESSD) をアプリケーションにマウントする場合、ディスクボリュームのデータセキュリティを確保するために、インスタントアクセス (IA) スナップショット機能を有効にすることを推奨します。 詳細については、「ディスクボリュームのデータセキュリティに関するベストプラクティス」トピックの「偶発的なESSDの削除によるデータ損失が発生する」をご参照ください。