一般的な問題
次の手順を実行して、ボリュームプラグインのログを表示し、問題を特定します。
次のコマンドを実行して、永続ボリュームクレーム (PVC) またはポッドに関連するイベントが生成されるかどうかを確認します。
期待される出力:
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"
FlexVolumeまたはCSIプラグインがクラスターにデプロイされているかどうかを確認します。
ボリュームテンプレートがクラスターで使用されているボリュームプラグインのテンプレートと一致するかどうかを確認します。 サポートされているボリュームプラグインは、FlexVolumeとCSIです。
クラスターでボリュームを初めてマウントする場合は、永続ボリューム (PV) およびStorageClassで指定されているドライバーがCSIドライバーであるか、FlexVolumeドライバーであるかを確認します。 指定したドライバーの名前は、クラスターにデプロイされているボリュームプラグインのタイプと同じである必要があります。
ボリュームプラグインが最新バージョンに更新されているかどうかを確認します。
次のコマンドを実行して、FlexVolumeプラグインのイメージバージョンを照会します。
kubectl get ds flexvolume -n kube-system -oyaml | grep image
期待される出力:
image: registry.cn-hangzhou.aliyuncs.com/acs/Flexvolume:v1.14.8.109-649dc5a-aliyun
FlexVolumeの詳細については、「FlexVolume (非推奨) 」をご参照ください。
次のコマンドを実行して、CSIプラグインのイメージバージョンを照会します。
kubectl get ds csi-plugin -n kube-system -oyaml |grep image
期待される出力:
image: registry.cn-hangzhou.aliyuncs.com/acs/csi-plugin:v1.18.8.45-1c5d2cd1-aliyun
CSIプラグインの詳細については、「csi-plugin」および「csi-provisioner」をご参照ください。
ログを表示します。
ディスクタイプのPVCがPending状態の場合、関連するPVは作成されません。 Provisionerプラグインのログを確認する必要があります。
システムがポッドを起動したときにマウントエラーが発生した場合は、FlexVolumeまたはcsi-pluginのログを確認する必要があります。
FlexVolumeプラグインがクラスターにデプロイされている場合は、次のコマンドを実行してFlexVolumeのログを印刷します。
kubectl get pod <pod-name> -owide
ポッドが実行されているECS (Elastic Compute Service) インスタンスにログインし、/var /Log /alicloud /FlexVolume_**.log
ディレクトリでflexvolumeのログを確認します。
CSIプラグインがクラスターにデプロイされている場合は、次のコマンドを実行してcsi-pluginのログを出力します。
nodeID=`kubectl get pod <pod-name> -owide | awk 'NR>1 {print $7}'`
podID=`kubectl get pods -nkube-system -owide -lapp=csi-plugin | grep $nodeID|awk '{print $1}'`
kubectl logs <PodID> -nkube-system
kubeletのログを表示します。
次のコマンドを実行して、ポッドが実行されているノードを照会します。
kubectl get pod <pod-name> -owide | awk 'NR>1 {print $7}'
ノードにログインし、/var /Log /messageディレクトリのログファイルを確認します。
迅速な回復
ノード上のほとんどのポッドにボリュームをマウントできない場合は、ポッドを他のノードにスケジュールできます。 詳細については、「特定のノードへのポッドのスケジュール」をご参照ください。
csi-plugin更新の失敗
csi-pluginはDaemonSetを介してデプロイされます。 NotReady状態またはRunning以外の状態のノードがクラスターに存在する場合、Container Service for Kubernetes (ACK) はcsi-pluginの更新に失敗します。 手動でノードを修正し、更新を再度実行する必要があります。 詳細については、「CSIプラグインの管理」をご参照ください。
csi-pluginの起動失敗
発行
csi-provisionerとcsi-pluginの起動に失敗しました。 csi-pluginとcsi-provisionerのメインコンテナログは、403 - Forbidden
エラーを報告します。
原因
ノード上のメタデータサーバーのセキュリティ強化が有効になります。 CSIはセキュリティ強化をサポートしていないため、メタデータにアクセスできません。
解決策
チケットを起票し、ECSチームにテクニカルサポートを依頼します。 クラスター内のノード数が更新の事前チェックの要件を満たしていないためにcsi-provisionerの更新が失敗した場合はどうすればよいですか?
問題
クラスター内のノード数が要件を満たしていないため、csi-provisionerプラグインは事前チェックに合格しません。
csi-provisionerプラグインは事前チェックに合格し、更新することができます。 ただし、csi-provisionerポッドがクラッシュし、ログに次の403 Forbidden
エラーが検出されます。
time="2023-08-05T13:54:00+08:00" level=info msg="Use node id : <?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\"\n \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n<html xmlns=\"http://www.w3.org/1999/xhtml\" xml:lang=\"en\" lang=\"en\">\n <head>\n <title>403 - Forbidden</title>\n </head>\n <body>\n <h1>403 - Forbidden</h1>\n </body>\n</html>\n"
原因
問題1の原因:
csi-provisionerの高可用性を確保するために、csi-provisionerはプライマリポッドとセカンダリポッドで実行されます。 プライマリポッドとセカンダリポッドは、異なるノードにスケジュールされます。 クラスターにノードが1つしかない場合、csi-provisionerを更新することはできません。
問題2の原因:
セキュリティ強化モードは、csi-provisionerが存在するノードに対して有効になります。 このモードは、ノード上のメタデータサーバーへのアクセスを防ぎます。
ソリューション
問題1の解決策:
csi-provisionerを更新します。 詳細については、「CSIプラグインの管理」をご参照ください。
問題2の解決策:
ノードのセキュリティ強化モードを無効にして、CSIがノードのメタデータにアクセスできるようにします。
StorageClasses属性の変更によりcsi-provisionerの更新が失敗した場合はどうすればよいですか?
問題
csi-provisionerは、StorageClassesの属性が要件を満たしていないため、事前チェックに失敗します。
原因
デフォルトのStorageClassesの属性が変更されます。 デフォルトのStorageClassesと同じ名前のStorageClassesを削除して再作成しました。 デフォルトのStorageClassesの属性は変更できません。 そうでなければ、csi-provisionerは更新されないかもしれません。
解決策
デフォルトのStorageClasses: alicloud-disk-essd、alicloud-disk-available、alicloud-disk-efficiency、alicloud-disk-ssd、alicloud-disk-topologyを削除します。 削除操作は、クラスター内のアプリケーションには影響しません。 次に、csi-provisionerを再インストールします。 csi-provisionerを再インストールすると、前述のデフォルトのStorageClassesが自動的に再作成されます。
重要
カスタムStorageClassesを作成する場合は、前述の既定のStorageClassesの名前とは異なる名前を使用します。
StorageClassの変更は既存のボリュームに影響しますか?
StorageClassの変更は、PVCまたはPVのYAMLファイルが変更されていない場合、既存のボリュームには影響しません。 たとえば、StorageClassでALLOWVOLUMEEXPANSION
設定を変更した後、新しい設定はPVCのYAMLファイルでCapacityパラメーターを変更した場合にのみ有効になります。
csi-provisionerのログに「failed to renew lease xxx timed out waiting for the condition」というエラーが表示された場合はどうすればよいですか?
問題
kubectl logs csi-provisioner-xxxx -nkube-system
コマンドを実行してcsi-provisionerのログを照会すると、failed to renew lease xxx timed out waiting for the condition
エラーがログに表示されます。
原因
高可用性を実装するために、csi-provisinoerに複数のレプリケートポッドがプロビジョニングされます。 Kubernetesはリースを使用して、コンポーネントのレプリケートされたポッド間でリーダー選出を実行します。 選択中、csi-provisionerはクラスターのKubernetes APIサーバーにアクセスして、指定されたリースを要求します。 リースを取得したレプリケートされたポッドが、クラスターでサービスを提供するリーダーになります。 この問題は、csi-provisionerがクラスターのKubernetes APIサーバーにアクセスできないために発生します。
解決策
クラスターのクラスターネットワークとKubernetes APIサーバーが正常な状態かどうかを確認します。 問題が解決しない場合は、
チケットを起票してサポートセンターにお問い合わせくださいしてサポートセンターにお問い合わせください。 ボリュームプラグインによるOOMの問題
csi-provisionerは、集中型ボリュームプラグインです。 Sidecarコンテナは、ポッド、PV、およびPVCに関する情報をキャッシュするために使用されます。 クラスタのサイズが大きくなると、メモリ不足 (OOM) エラーが発生する可能性があります。 OOMエラーが発生した場合は、クラスターのサイズに基づいてリソース制限を変更する必要があります。
ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のナビゲーションウィンドウで、 を選択します。
On theアドオンページをクリックし、アイコンの右下の部分にcsi-provisionerコンポーネントとクリックYAMLで表示.
クラスターのサイズに基づいて、YAMLファイルのリソース制限を変更します。
ボリュームを作成またはマウントするときに、PVCにまったくボリュームプラグインが一致しないのはなぜですか?
問題
ボリュームを作成またはマウントするときに、ボリュームをアタッチまたはマウントできません: unmounted volumes=[xxx], unattached volumes=[xxx]: volumeSpecからボリューム "xxx" err=ボリュームプラグインが一致していません。
原因
ボリュームプラグインがYAMLテンプレートと一致しません。 その結果、システムはボリュームを作成またはマウントするときに対応するボリュームプラグインを見つけることができません。
解決策
ボリュームプラグインがクラスターに存在するかどうかを確認します。
ボリュームプラグインがインストールされていない場合は, インストールしてください。 詳細については、「コンポーネントの管理」をご参照ください。
ボリュームプラグインが既にインストールされている場合は、ボリュームプラグインがPVおよびPVCのYAMLテンプレートと一致し、YAMLテンプレートが次の要件を満たしているかどうかを確認します。
csi-pluginポッドの監視データに大量のトラフィックが記録されている場合はどうすればよいですか?
問題
csi-pluginポッドの監視データには大量のトラフィックが記録されます。
原因
csi-pluginは、NASボリュームをノードにマウントします。 NASボリュームがノード上のポッドにマウントされている場合、ポッドからNASボリュームへの要求は、csi-pluginがデプロイされている名前空間を通過します。 リクエストはクラスターによって監視されます。 その結果、csi-pluginポッドの監視データに大量のトラフィックが記録されます。
解決策
この問題を修正する必要はありません。 csi-pluginを流れるトラフィックの量は2倍になりません。 さらに、csi-pluginを介して流れるトラフィックは、追加のネットワーク帯域幅を消費しません。
ポッドに対して0/xノードが利用可能です: x pod has unbound immediate PersistentVolumeClaimsイベントが生成されるのはなぜですか。
問題
システムは、使用可能な0/xノードを生成します。x podには即時のPersistentVolumeClaimesがあります。 プリエンプション: 0/xノードが利用可能です: xプリエンプションは、ポッドのイベントをスケジュールするには役立ちません。
原因
カスタムStorageClassが存在しないため、ポッドによって参照されるカスタムStorageClassが見つかりません。
解決策
ポッドが動的にプロビジョニングされたボリュームを使用する場合は、ポッドによって参照されるカスタムStorageClassを見つけます。 StorageClassが存在しない場合は、作成します。
PVがリリース状態で、再作成されたPVCにバインドできない場合はどうすればよいですか?
問題
誤ってPVCを削除しました。 PVはリリース済み状態であり、再作成したPVCにバインドすることはできません。
原因
PVCのreclaimPolicyがRetainの場合、PVCを削除するとPVのステータスがReleasedに変わります。
解決策
pvのPV. spec.claimRef
フィールドを削除し、静的にプロビジョニングされたボリュームとしてPVをPVCにバインドする必要があります。 これにより、PVのステータスがBoundに変わります。
PVがLost状態にあり、再作成されたPVCにバインドできない場合はどうすればよいですか?
問題
PVCとPVが作成された後、PVはLost状態のままであり、PVCにバインドすることはできません。
原因
PVのclaimRef
フィールドに指定されたPVC名は存在しません。 その結果、PVのステータスはLostに変わります。
解決策
pvのPV. spec.claimRef
フィールドを削除し、静的にプロビジョニングされたボリュームとしてPVをPVCにバインドする必要があります。 これにより、PVのステータスがBoundに変わります。
FlexVolumeからCSIへの移行に関するFAQ
以前のACKバージョンでは、FlexVolumeがボリュームプラグインとして使用されていました。 FlexVolumeは、それ以降のバージョンでは廃止されます。 ACKクラスターのバージョンが1.18より前の場合は、FlexVolumeからCSIに移行することを推奨します。 詳細については、「FlexVolumeからCSIへの移行」をご参照ください。
その他のStorageClassの問題
mountOptionパラメーターにスペルミスがある場合、PVCが参照するStorageClassが存在しない場合、またはマウント対象のドメイン名が存在しない場合は、Container Network File System (CNFS) ボリュームを使用することを推奨します。 CNFSの詳細については、「CNFS」をご参照ください。
クラスタ内の複数のアプリケーションが同じボリュームを使用できますか?
ディスクに対して自動的に作成されるStorageClassesの構成を変更するにはどうすればよいですか。
自動的に作成されるStorageClassesは変更できません。
csi-provisionerをインストールすると、alicloud-disk-topology-alltypeなどのStorageClassesがクラスターに自動的に作成されます。 これらのStorageClassesは変更しないでください。 ディスクのStorageClassesの詳細については、「StorageClass」をご参照ください。 ボリュームタイプ、パフォーマンス、再利用ポリシーなど、StorageClassの設定を変更する必要がある場合は、新しいStorageClassを作成できます。 作成できるStorageClassesの数は無制限です。 詳細については、「StorageClassの作成」をご参照ください。