第7章 既知の問題

Arbiter ノードに OpenShift Container Storage ノードラベルでラベル付けできない

Arbiter ノードは、OpenShift Container Storage ノードラベル cluster.ocs.openshift.io/openshift-storage でラベル付けされた場合に、有効な Arbiter 以外のノードとみなされます。これは、Arbiter 以外のリソースの配置が確定されないことを意味します。この問題を回避するには、Arbiter リソースのみが Arbiter ノードに配置されるように Arbiter ノードに OpenShift Container Storage ノードラベルを付けないようにします。

Ceph のステータスは、ディスクの交換後の HEALTH_WARN です。

ディスクの交換後に、すべての OSD Pod が稼働している場合でも、1 daemons have recently crashed 警告が見られます。この警告により、Ceph のステータスが変更されます。Ceph のステータスは、HEALTH_WARN ではなく HEALTH_OK である必要があります。この問題を回避するには、rsh を ceph-tools Pod に実行し警告を非表示にすると、Ceph の正常性は HEALTH_OK に戻ります。

CephCluster リソースでのモニターリング仕様がリセットされる

ocs-operator が再起動するか、またはアップグレード時には常に監視仕様は空になります。これは機能への影響はありませんが、モニターリングエンドポイントの詳細が必要な場合は、空にします。

noobaa-db-pg-0 の問題

noobaa-db-pg-0 Pod は、ホストしているノードがダウンしても他のノードに移行しません。NooBaa は、ノードがダウンすると noobaa-db-pg-0 Pod の移行がブロックされるために機能しません。

プラグイン Pod が削除されると、ノードの再起動が行われるまでデータはアクセス不可能になります。

この問題は、csi-cephfsplugin Pod が再起動すると、マウントの netns が破棄されるため、csi-cephfsplugin はすべてのマウントされたボリュームをロックします。この問題は、multus を有効にしてクラスターでのみ見られます。

暗号化パスフレーズは、スナップショットからボリュームを復元するためのソース KMS に保存されます。

親と復元された PVC の異なるバックエンドパスを持つ StorageClass が異なる場合、復元された PVC は Bound 状態に行われ、スナップショットから KMS 設定のバックエンドパスに暗号化パスフレーズが作成されます。暗号化パスフレーズの確認は 2 番目の StorageClass パスにリンクされた設定を使用するので、復元された PVC は Pod に割り当てられないようにすることができます。この場合、暗号化パスフレーズはバックエンドパスに見つかりません。

キーは、kv-v2 シークレットエンジンを使用する場合に、暗号化された PVC を削除した後に Vault に一覧表示されます。

HashiCorp Vault は、保存されたキーの削除先である key-value store v2 の機能を追加しました。これにより、削除されたキーのメタデータが別のステップで削除されない場合にコンテンツを回復できます。Hashicorp Vault のシークレットに key-value v2 ストレージを使用する場合に、ボリュームを削除すると、KMS から暗号化パスフレーズのメタデータは削除されません。後で暗号化パスフレーズを復元することが可能です。これらの部分的に削除されたキーは、KMS によって自動的にクリーンアップされません。

親 PVC よりもサイズが大きい Restore Snapshot/Clone 操作により無限ループが生じる

Ceph CSI は、親 PVC よりもサイズが大きい場合にスナップショットの復元やクローンの作成をサポートしません。そのため、サイズが多い Restore Snapshot/Clone 操作により、無限ループが生じます。この問題を回避するには、保留中の PVC を削除します。より大きい PVC を取得するには、仕様しちえる操作に基づいて以下のいずれかを完了する必要があります。スナップショットを使用する場合、既存のスナップショットを復元し、親 PVC と同じサイズのボリュームを作成し、これを Pod に割り当て、PVC を必要なサイズに拡張します。詳細は、Volume snapshots を参照してください。Clone を使用する場合、親 PVC のクローンを作成し、親 PVC と同じサイズのボリュームを作成し、これを Pod に割り当て、PVC を必要なサイズに拡張します。詳細は、ボリュームのクローン作成を参照してください。

PVC はスナップショットから復元するか、シックプロビジョニングされた PVC からクローンがプロビジョニングされていません。

シックプロビジョニングされた PVC のスナップショットが thic provisioning のストレージクラスを使用して復元されると、復元されたボリュームはプロビジョニングされません。復元される PVC は、シックプロビジョニングなしで Bound 状態に達します。この問題は、RHCS-5.x が使用される場合にのみ修正できます。以前の Ceph バージョンは、ゼロ入力データブロックのコピーをサポートしません (シックプロビジョニング時に使用)。

プロビジョニングが進行中に保留中の PVC および RBD プロビジョナーリーダー Pod を削除すると、古いイメージと OMAP メタデータが残されます。

RBD PVC がプロビジョニングされている場合、Persistent Volume Claim (永続ボリューム要求、PVC) は Pending 状態になります。RBD プロビジョナーリーダーおよび PVC 自体が削除されても、RBD イメージと OMAP メタデータは削除されません。

ストレージクラスターの使用が 85% に達するか、PVC を削除した後にも、プロビジョニングは停止しませんでした。

RBD シック PVC がプロビジョニングされている間にストレージクラスターの使用状況が 85% に達すると、プロビジョニングは保留中の PVC を削除して自動的に停止しません。また、保留中の PVC を削除しても RBD イメージは削除されません。

kv-v2 が使用されると、Vault の OSD のキーはアンインストール時に削除されません

キー暗号化キーデータは、Vault K/V Secret エンジンがバージョン 2 の場合に、クラスターの削除時に Vault からソフト削除されます。つまり、任意のバージョンのキーを取得できるため、削除が元に戻されます。メタデータは引き続き表示されるので、鍵を復元できます。これによって不整合が生じても、vault コマンドに destroy 引数を指定して手動でキーを削除できます。

CephBlockPool の削除がスタックし、新規プールの作成をブロックします。

Multus が有効なクラスターでは、Rook Operator にはネットワークアノテーションがないため、OSD ネットワークにアクセスできません。つまり、プールのクリーンアップ中に rbd タイプコマンドを実行すると、OSD と通信できないためコマンドがハングします。回避策として、toolbox を使用して CephBlockPool を手動で削除します。

デバイス置き換えのアクションは、暗号化された OpenShift Container Storage クラスター用のユーザーインターフェイスから実行できません。

暗号化された OpenShift Container Storage クラスターでは、検出の結果 CR は Ceph OSD (Object Storage Daemon) がサポートするデバイスを検出します。これは、Ceph アラートで報告されるデバイスとは異なります。アラートをクリックすると、ユーザーには Disk not found というメッセージが表示されます。不一致があるため、コンソール UI は OpenShift Container Storage ユーザー用にディスク置き換えオプションを有効にすることはできません。この問題を回避するには、デバイスの置き換えガイドにあるように、障害のあるデバイスの置き換えに CLI 手順を使用します。

volumeMode をブロックとして持つ PVC の false 通知

Kubernetes の変更により、OpenShift Container Platform の Prometheus アラートでリグレッションが発生します。この変更は以下に影響があります。

ストレージクラスターの再インストール中に cephobjectstore の ceph オブジェクトが作成されると、Arbiter ストレージクラスターのインストール後に重大なアラート通知が送信されます。

CephCluster および 1 つ以上の CephObjectStores を含むストレージクラスターでは、CephCluster リソースがすべて CephObjectStore リソースを完全に削除する前に削除しても、Rook Operator はメモリー内の CephObjectStore(s) に関する接続の詳細を保持できます。同じ CephCluster および CephObjectStore(s) が再作成されると、CephObjectStore(s) は Failed の状態になる可能性があります。