kubenetes: ポッドにバインドされていないPersistentVolumeClaimsがあります。

背景
helm chart を使用して rabbitmq をデプロイすると、pod has unbound PersistentVolumeClaims というエラーが報告されます。
原因分析
rabbitmqのチャートファイルを確認したところ、value.yamlのstorageClassNameがNULLになっていました。storageClassNameがNULLの時にDefaultStorageClassを指定しないと、クレームにpvが割り当てられない。
テンプレートファイル内のstorageclassが数値を取得するロジック

DefaultStorageClassを記述します。
PVCとPVのバインドはStorageClassNameで行われます。しかし、StorageClassNameを指定せずにPVCを定義した場合はどうでしょうか。これは、コミッションプラグインでDefaultDefaultStorageClass機能が有効になっているかどうかに依存します。

DefaultDefaultStorageClassが有効な場合、このPVCのStorageClassNameはDefaultStorageClassとして指定されます。StorageClassを定義する際に、Annotation: storageclass.kubernetes.io/is-default-class: trueにキーと値のペアを追加すると、このStorageClassがデフォルトStorageClassとなることがわかりました。
DefaultDefaultStorageClass機能がオンになっていない場合、StorageClassNameを指定しないPVCは、同じくStorageClassNameを指定しないPVにのみバインドすることが可能です。
当環境のstorageclassの定義を見たところ、DefaultDefaultStorageClassの機能がオンになっていないことがわかりました

解決策
この対処法は2つあります。 1. storageclass.kubernetes.io/is-default-class: trueを追加してstorageclassを再定義する。
2. 2. チャートファイルのpvc fetchを変更し、storageClass = 既存のstorageclass名とします。

結果
しばらくして再度ポッドの状態を確認すると、稼働しています

Cloud Native Test Development Group に参加し、一緒に議論し、学ぶことを歓迎します。
二次元コードの期限切れは、グループchenpf4618に私のWeChatを追加することができ、グループにcsdnに注意してください