既知の制限
既知の制限事項は、このリリースの製品でサポートされていないプラットフォーム、デバイス、機能、または製品と正しく相互運用できない機能を特定します。これらの制限事項を慎重に確認してください
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
ネームスペースの RBAC に制約があるユーザは、クラスタの追加と管理解除を行うことができます
ネームスペースの RBAC に制限があるユーザは、クラスタの追加または管理解除を行うことができません。現在の制限により、 Astra は、このようなユーザによるクラスタの管理解除を妨げません。
名前空間の制約を持つメンバは、管理者が名前空間を制約に追加するまで、クローンまたは復元されたアプリケーションにアクセスできません
任意 member
ネームスペース名/ IDによるRBACの制約があるユーザは、同じクラスタまたは組織のアカウントにある他のクラスタの新しいネームスペースにアプリケーションをクローニングまたはリストアできます。ただし、同じユーザが、クローニングまたはリストアされたアプリケーションに新しいネームスペースからアクセスすることはできません。クローン処理またはリストア処理で新しいネームスペースが作成されると、アカウントの管理者/所有者は member
影響を受けるユーザーが新しい名前空間へのアクセスを許可するためのユーザーアカウントの制約を更新します。
コネクタ以外のクラスタのリソースでは、制限的なロール制約は無視できます。
-
アクセス対象のリソースが最新のAstra Connectorがインストールされているクラスタに属している場合:LDAPグループメンバーシップを通じてユーザに複数のロールが割り当てられると、ロールの制約が結合されます。たとえば、ローカルのビューアロールを持つユーザーが、メンバーロールにバインドされている3つのグループに参加した場合、ユーザーは元のリソースへのビューアロールアクセス権と、グループメンバーシップによって取得されたリソースへのメンバーロールアクセス権を持つようになります。
-
アクセス対象のリソースがAstra Connectorがインストールされていないクラスタに属している場合:ユーザにLDAPグループメンバーシップを通じて複数のロールが割り当てられている場合、最も権限の厳しいロールの制約のみが有効になります。
1つのネームスペース内の複数のアプリケーションをまとめて別のネームスペースにリストアすることはできません
複数のアプリケーションを1つのネームスペースで管理する場合(Astra Controlで複数のアプリケーション定義を作成する)、すべてのアプリケーションを別の1つのネームスペースにリストアすることはできません。各アプリケーションを専用のネームスペースにリストアする必要があります。
Astra Controlでは、ネームスペースごとに複数のストレージクラスを使用するアプリケーションはサポートされていません
Astra Controlは、ネームスペースごとに単一のストレージクラスを使用するアプリケーションをサポートします。ネームスペースにアプリケーションを追加するときは、そのアプリケーションのストレージクラスがネームスペース内の他のアプリケーションと同じであることを確認してください。
Astra Controlでは、クラウドインスタンスにデフォルトのバケットは自動的に割り当てられません
Astra Controlでは、どのクラウドインスタンスに対してもデフォルトのバケットが自動的に割り当てられることはありません。クラウドインスタンスのデフォルトバケットは手動で設定する必要があります。デフォルトのバケットが設定されていないと、2つのクラスタ間でアプリケーションのクローニング処理を実行できません。
パスバイリファレンス演算子を使用してインストールされたアプリケーションのクローンが失敗することがあります
Astra Control は、名前空間を対象とした演算子でインストールされたアプリケーションをサポートします。これらの演算子は、一般に「パスバイリファレンス」アーキテクチャではなく「パスバイ値」で設計されています。これらのパターンに続くいくつかのオペレータアプリを次に示します。
-
K8ssandra では、 In Place リストア処理がサポートされます。新しいネームスペースまたはクラスタにリストアするには、アプリケーションの元のインスタンスを停止する必要があります。これは、ピアグループ情報がインスタンス間通信を行わないようにするためです。アプリケーションのクローニングはサポートされていません。
Astra Controlでは、「パスバイリファレンス」アーキテクチャ(CockroachDBオペレータなど)で設計されたオペレータをクローニングできない場合があります。クローニング処理では、クローニング処理の一環として独自の新しいシークレットが存在する場合でも、クローニングされたオペレータがソースオペレータから Kubernetes シークレットを参照しようとします。Astra Control がソースオペレータの Kubernetes シークレットを認識しないため、クローニング処理が失敗する場合があります。
|
クローン処理中に、IngressClassリソースまたはwebhookを必要とするアプリケーションが正常に機能するためには、これらのリソースがデスティネーションクラスタですでに定義されていない必要があります。 |
証明書マネージャを使用するアプリケーションの In Place リストア処理はサポートされていません
このリリースの Astra Control Center では、証明書マネージャを使用したアプリのインプレースリストアはサポートされていません。別のネームスペースへのリストア処理とクローニング処理がサポートされています。
OLM 対応およびクラスタ対象のオペレータ展開アプリケーションはサポートされていません
Astra Control Center は、クラスタを対象としたオペレータによるアプリケーション管理アクティビティをサポートしません。
Helm 2 で展開されたアプリケーションはサポートされていません
Helm を使用してアプリケーションを展開する場合、 Astra Control Center には Helm バージョン 3 が必要です。Helm 3 (または Helm 2 から Helm 3 にアップグレード)を使用して展開されたアプリケーションの管理とクローニングが完全にサポートされています。詳細については、を参照してください "Astra Control Center の要件"。
特定のバージョンのSnapshotコントローラを含むKubernetes 1.25以降のクラスタでは、Snapshotが失敗することがあります
バージョン1.25以降を実行しているKubernetesクラスタのSnapshotは、クラスタにSnapshotコントローラAPIのバージョンv1beta1がインストールされている場合に失敗することがあります。
既存のKubernetes 1.25以降のインストールをアップグレードする場合は、回避策 として次の手順を実行します。
-
既存のSnapshot CRDと既存のSnapshotコントローラをすべて削除します。
Astra Control Center インスタンスの削除中にバックアップとスナップショットが保持されない場合があります
評価用ライセンスをお持ちの場合は、 Astra Control Center に障害が発生したときに ASUP を送信していないときにデータが失われないように、アカウント ID を必ず保存してください。
ONTAP NASエコノミーストレージクラスへのIn Placeリストア処理が失敗する
アプリケーションのインプレースリストアを実行し(アプリケーションを元のネームスペースにリストア)、アプリケーションのストレージクラスで ontap-nas-economy
ドライバの場合、スナップショットディレクトリが非表示になっていないとリストア処理が失敗することがあります。インプレースでリストアする前に、の手順に従ってください。 "ONTAP NAS経済性に優れた運用向けのバックアップとリストアを実現" Snapshotディレクトリを非表示にします。
LDAPユーザおよびグループの制限事項
Astra Control Centerは、最大5,000のリモートグループと10,000のリモートユーザをサポートします。
Astra Controlでは、末尾にスペースがあるRDNを含むDNを持つLDAPエンティティ(ユーザまたはグループ)はサポートされません。
Astra Control Center の S3 バケットは、使用可能容量を報告しません
Astra Control Center で管理されているアプリケーションのバックアップまたはクローニングを行う前に、 ONTAP または StorageGRID 管理システムでバケット情報を確認します。
Astra Control Center は、プロキシサーバー用に入力した詳細を検証しません
実行することを確認してください "正しい値を入力します" 接続を確立するとき。
Postgres ポッドへの既存の接続が原因で障害が発生します
Postgres ポッドで操作を実行する場合は、 psql コマンドを使用するためにポッド内で直接接続しないでください。Astra Control では、 psql にアクセスしてデータベースをフリーズし、解凍する必要があります。既存の接続がある場合、スナップショット、バックアップ、またはクローンは失敗します。
[Activity]ページには、最大10万件のイベントが表示されます
[Astra Control Activity]ページには、最大10、000件のイベントを表示できます。ログに記録されたすべてのイベントを表示するには、を使用してイベントを取得します "Astra Control API の略"。
SnapMirrorはストレージバックエンドにNVMe over TCPを使用するアプリケーションをサポートしない
Astra Control Centerでは、NVMe over TCPプロトコルを使用するストレージバックエンドのNetApp SnapMirrorレプリケーションはサポートされません。