既知の制限
既知の制限事項は、このリリースの製品でサポートされていないプラットフォーム、デバイス、機能、または製品と正しく相互運用できない機能を特定します。これらの制限事項を慎重に確認してください
2 つの Astra Control Center インスタンスで同じクラスタを管理することはできません
別の Astra Control Center インスタンスでクラスタを管理する場合は、最初にを実行する必要があります "クラスタの管理を解除します" 別のインスタンスで管理する前に、管理対象のインスタンスから管理します。管理対象からクラスタを削除したら、次のコマンドを実行してクラスタが管理対象外であることを確認します。
oc get pods n -netapp-monitoring
そのネームスペースでポッドを実行していないことを確認するか、ネームスペースを存在させないようにします。どちらかが true の場合、クラスタは管理対象外です。
Astra Control Center は、同じ名前の 2 つのクラスタを同じクラウドで管理することはできません
すでにクラウドに存在するクラスタと同じ名前のクラスタを追加しようとすると、処理に失敗します。この問題は、 Kubernetes 構成ファイルでクラスタ名のデフォルトを変更していない場合、通常は標準の Kubernetes 環境で発生します。
回避策として、次の手順を実行します。
-
kubeadm -config 構成マップを編集します。
kubectl edit configmaps -n kube-system kubeadm-config
-
「 clusterName 」フィールドの値を「 Kubernetes 」( Kubernetes のデフォルト名)から一意のカスタム名に変更します。
-
kubeconfig (
.kube/config
) を編集します。 -
クラスタ名を「 Kubernetes 」から一意のカスタム名に更新します(以下の例では「 xyz-cluster 」を使用します)。次の例に示すように 'clusters' および contexts の両方のセクションで更新を行います
apiVersion: v1 clusters: - cluster: certificate-authority-data: ExAmPLERb2tCcjZ5K3E2Njk4eQotLExAMpLEORCBDRVJUSUZJQ0FURS0txxxxXX== server: https://x.x.x.x:6443 name: xyz-cluster contexts: - context: cluster: xyz-cluster namespace: default user: kubernetes-admin name: kubernetes-admin@kubernetes current-context: kubernetes-admin@kubernetes
参照渡し演算子を使用してインストールされたアプリケーションのクローンが失敗することがあります
Astra Control は、名前空間を対象とした演算子でインストールされたアプリケーションをサポートします。これらの演算子は、一般に「パスバイリファレンス」アーキテクチャではなく「パスバイ値」で設計されています。これらのパターンに続くいくつかのオペレータアプリを次に示します。
Astra Control では、「パスバイリファレンス」アーキテクチャ( CockroachDB オペレータなど)で設計されたオペレータをクローニングできない場合があります。クローニング処理では、クローニング処理の一環として独自の新しいシークレットが存在する場合でも、クローニングされたオペレータがソースオペレータから Kubernetes シークレットを参照しようとします。Astra Control がソースオペレータの Kubernetes シークレットを認識しないため、クローニング処理が失敗する場合があります。
クラスタの状態は removed
クラスタとネットワークは想定どおりに機能していることを確認します
クラスタが「 re moved 」状態であり、ネットワーク接続が正常であると表示される場合( Kubernetes API を使用してクラスタに外部からアクセスしようとすると成功します)、 Astra Control に指定した beckufig は無効になる可能性があります。クラスタでの証明書のローテーションまたは有効期限が原因の可能性があります。この問題を修正するには、を使用して、 Astra Control のクラスタに関連付けられたクレデンシャルを更新します "Astra Control API の略":
-
POST 呼び出しを実行して更新された kubeconfig ファイルを「 /credentials 」エンドポイントに追加し、応答本文から割り当てられた「 id 」を取得します。
-
適切なクラスタ ID を使用して '/clusters' エンドポイントから PUT 呼び出しを実行し 'credentialId' を前の手順の id' 値に設定します
これらの手順を完了すると、クラスタに関連付けられたクレデンシャルが更新され、クラスタは再接続して、その状態を「 available 」に更新する必要があります。
OLM 対応およびクラスタ対象のオペレータ展開アプリケーションはサポートされていません
Astra Control Center は、 Operator Lifecycle Manager ( OLM )対応のオペレータまたはクラスタを対象としたオペレータによって展開されるアプリケーションをサポートしません。
アプリケーションのクローニングは、同じ Kubernetes ディストリビューションでのみ実行できます
クラスタ間でアプリケーションをクローニングする場合は、ソースクラスタとデスティネーションクラスタが Kubernetes に同一に分散されている必要があります。たとえば、 OpenShift 4.7 クラスタからアプリケーションをクローニングする場合は、 OpenShift 4.7 でもあるデスティネーションクラスタを使用します。
Astra Control Center の S3 バケットは、使用可能容量を報告しません
Astra Control Center で管理されているアプリケーションのバックアップまたはクローニングを行う前に、 ONTAP または StorageGRID 管理システムでバケット情報を確認します。
MetalLB 0.11.0 はサポートされていません
metalLB 0.11.0 は、 Astra Control Center でサポートされているロードバランサではありません。サポートされているロードバランサの詳細については、を参照してください "Astra Control Center の要件"。
Helm 2 で展開されたアプリケーションはサポートされていません
Helm を使用してアプリケーションを展開する場合、 Astra Control Center には Helm バージョン 3 が必要です。Helm 3 (または Helm 2 から Helm 3 にアップグレード)を使用して展開されたアプリケーションの管理とクローニングが完全にサポートされています。詳細については、を参照してください "Astra Control Center の要件"。
Astra Control Center は、プロキシサーバー用に入力した詳細を検証しません
実行することを確認してください "正しい値を入力します" 接続を確立するとき。
Astra Control Center のデータ保護はまだ利用できません
このリリースでは、 Snapshot 、バックアップ、リストアの各オプションを使用して Astra をアプリケーションとして管理する機能はサポートされていません。
正常でないポッドは、アプリケーション管理に影響を与えます
管理対象アプリケーションにポッドが正常な状態でない場合、 Astra Control は新しいバックアップとクローンを作成できません。
Postgres ポッドへの既存の接続が原因で障害が発生します
Postgres ポッドで操作を実行する場合は、 psql コマンドを使用するためにポッド内で直接接続しないでください。Astra Control では、 psql にアクセスしてデータベースをフリーズし、解凍する必要があります。既存の接続がある場合、スナップショット、バックアップ、またはクローンは失敗します。
Tridentはクラスタからアンインストールされません
Trident は、 Astra Control Center からクラスタの管理を解除しても、クラスタから自動的にはアンインストールされません。Trident をアンインストールするには、が必要です "Trident のドキュメントでは、次の手順を実行します"。