Si vous souhaitez gérer un cluster sur une autre instance Astra Control Center, vous devez d’abord "annuler la gestion du cluster" à partir de l’instance sur laquelle elle est gérée avant de la gérer sur une autre instance. Une fois le cluster supprimé de la gestion, vérifiez que le cluster n’est pas géré en exécutant la commande suivante :

Il ne doit y avoir aucun pod en cours d’exécution dans cet espace de nom, sinon l’espace de noms ne doit pas exister. Si l’un de ces deux éléments est vrai, le cluster n’est pas géré.

Si vous tentez d’ajouter un cluster portant le même nom qu’un cluster existant, l’opération échoue. Ce problème se produit le plus souvent dans un environnement Kubernetes standard si vous n’avez pas modifié le nom de cluster par défaut dans les fichiers de configuration Kubernetes.

Pour résoudre ce problème, procédez comme suit :

Un utilisateur doté de contraintes RBAC d’espace de noms ne doit pas être autorisé à ajouter ou annuler la gestion des clusters. En raison d’une limitation actuelle, Astra n’empêche pas ces utilisateurs de dégérer les clusters.

Toutes member Les utilisateurs ayant des contraintes RBAC en fonction du nom/ID de l’espace de noms peuvent cloner ou restaurer une application vers un nouvel espace de noms sur le même cluster ou vers tout autre cluster du compte de leur entreprise. Cependant, le même utilisateur ne peut pas accéder à l’application clonée ou restaurée dans le nouvel espace de noms. Après la création d’un espace de noms par une opération de clonage ou de restauration, le compte admin/propriétaire peut modifier le member contraintes de compte d’utilisateur et de rôle de mise à jour pour l’utilisateur affecté pour accorder l’accès au nouvel espace de noms.

Astra Control prend en charge les applications installées avec des opérateurs à espace de noms. Ces opérateurs sont généralement conçus avec une architecture « pass-by-value » plutôt qu’une architecture « pass-by-Reference ». Voici quelques applications opérateur qui suivent ces modèles :

Astra Control peut ne pas être en mesure de cloner un opérateur conçu avec une architecture « pass-by-Reference » (par exemple, l’opérateur CockroachDB). Lors de ces types d’opérations de clonage, l’opérateur cloné tente de référencer les secrets de Kubernetes de l’opérateur source malgré avoir son propre nouveau secret dans le cadre du processus de clonage. Il est possible que le clonage échoue, car Astra Control ne connaît pas les secrets de Kubernetes qui sont présents dans l’opérateur source.

Cette version d’Astra Control Center ne prend pas en charge la restauration sur place des applications avec des gestionnaires de certificats. Les opérations de restauration vers un espace de noms et des clones différents sont prises en charge.

Astra Control Center ne prend pas en charge les activités de gestion d’applications avec des opérateurs à périmètre de cluster.

Si vous utilisez Helm pour déployer des applications, Astra Control Center requiert Helm version 3. La gestion et le clonage des applications déployées avec Helm 3 (ou mises à niveau de Helm 2 à Helm 3) sont entièrement pris en charge. Pour plus d’informations, voir "Exigences du centre de contrôle Astra".

Avant de sauvegarder ou de cloner des applications gérées par Astra Control Center, vérifiez les informations de compartiment dans le système de gestion ONTAP ou StorageGRID.

Assurez-vous que vous "entrez les valeurs correctes" lors de l’établissement d’une connexion.

Lorsque vous exécutez des opérations sur les modules Postgres, vous ne devez pas vous connecter directement dans le pod pour utiliser la commande psql. Astra Control nécessite un accès psql pour geler et dégeler les bases de données. S’il existe une connexion existante, le snapshot, la sauvegarde ou le clone échoueront.

Si vous disposez d’une licence d’évaluation, veillez à stocker votre identifiant de compte afin d’éviter toute perte de données en cas d’échec du Centre de contrôle Astra si vous n’envoyez pas d’ASUP.