Limites connues
Les limitations connues identifient les plateformes, les périphériques ou les fonctions qui ne sont pas pris en charge par cette version du produit, ou qui ne fonctionnent pas correctement avec elle. Examinez attentivement ces limites.
-
Les sauvegardes d'applications en cours ne peuvent pas être arrêtées
-
Les clones des applications installées à l'aide d'opérateurs pass-by-Reference peuvent échouer
-
Applications activées par OLM et déployées par l'opérateur à étendue de cluster non prises en charge
-
Les applications déployées avec Helm 2 ne sont pas prises en charge
Le même cluster ne peut pas être géré par deux instances Astra Control Center
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 :
oc get pods n -netapp-monitoring
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é.
Astra Control Center ne peut pas gérer deux clusters nommés de manière identique
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 :
-
Modifiez votre carte de configuration kubeadm-config :
kubectl edit configmaps -n kube-system kubeadm-config
-
Modifiez le
clusterName
valeur de champ dekubernetes
(Nom par défaut de Kubernetes) vers un nom personnalisé unique. -
Modifiez kubecconfig (
.kube/config
). -
Mettre à jour le nom de cluster depuis
kubernetes
à un nom personnalisé unique (xyz-cluster
est utilisé dans les exemples ci-dessous). Effectuez la mise à jour dans les deuxclusters
etcontexts
sections comme indiqué dans cet exemple :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
Un utilisateur doté de contraintes RBAC d'espace de noms peut ajouter et annuler la gestion d'un cluster
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.
Un membre avec des contraintes d'espace de noms ne peut pas accéder aux applications clonées ou restaurées tant que admin n'ajoute pas l'espace de noms à la contrainte
Toutes member
Les utilisateurs ayant des contraintes RBAC en fonction du nom/ID de l'espace de noms ou des étiquettes 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.
Les sauvegardes d'applications en cours ne peuvent pas être arrêtées
Il est impossible d'arrêter une sauvegarde en cours d'exécution. Si vous devez supprimer la sauvegarde, attendez qu'elle soit terminée, puis suivez les instructions de la section "Supprimer les sauvegardes". Pour supprimer une sauvegarde ayant échoué, utilisez le "API de contrôle Astra".
Les clones des applications installées à l'aide d'opérateurs pass-by-Reference peuvent échouer
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 :
-
Pour K8ssandra, les opérations de restauration sur place sont prises en charge. Pour effectuer une opération de restauration vers un nouvel espace de noms ou un cluster, l'instance d'origine de l'application doit être arrêté. Cela permet de s'assurer que les informations du groupe de pairs transmises ne conduisent pas à une communication entre les instances. Le clonage de l'application n'est pas pris en charge.
Notez qu'Astra Control peut ne pas être en mesure de cloner un opérateur conçu avec une architecture de "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.
Les opérations de restauration sur place des applications qui utilisent un gestionnaire de certificats ne sont pas prises en charge
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.
Applications activées par OLM et déployées par l'opérateur à étendue de cluster non 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.
Les applications déployées avec Helm 2 ne sont pas prises en charge
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".
Les compartiments S3 du centre de contrôle Astra n'indiquent pas la capacité disponible
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.
Astra Control Center ne valide pas les détails que vous entrez pour votre serveur proxy
Assurez-vous que vous "entrez les valeurs correctes" lors de l'établissement d'une connexion.
Les connexions existantes à un pod Postgres provoquent des défaillances
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.
Il est possible que les sauvegardes et les snapshots ne soient pas conservés lors du retrait d'une instance Astra Control Center
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.