Skip to main content
Une version plus récente de ce produit est disponible.
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Limites connues

Contributeurs

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.

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 de même nom dans le même cloud

Si vous tentez d’ajouter un cluster portant le même nom qu’un cluster existant déjà dans votre cloud, l’opération échouera. 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 :

  1. Modifiez votre carte de configuration kubeadm-config :

    kubectl edit configmaps -n kube-system kubeadm-config

  2. Modifiez le clusterName valeur de champ de kubernetes (Nom par défaut de Kubernetes) vers un nom personnalisé unique.

  3. Modifiez kubecconfig (.kube/config).

  4. 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 deux clusters et contexts 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

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 :

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.

Le cluster est dans le removed état bien que le cluster et le réseau fonctionnent autrement comme prévu

Si un cluster se trouve dans le removed État et pourtant, la connectivité cluster et réseau semble saine (les tentatives externes d’accès au cluster via les API Kubernetes sont réussies). Le kubeconfig que vous avez fourni au contrôle Astra pourrait ne plus être valide. Cela peut être dû à une rotation ou à une expiration du certificat sur le cluster. Pour corriger ce problème, mettez à jour les informations d’identification associées au cluster dans Astra Control à l’aide du "API de contrôle Astra":

  1. Exécutez un appel POST pour ajouter un fichier kubeconfig mis à jour au /credentials et récupérer le noeud final affecté id du corps de réponse.

  2. Effectuer un APPEL PUT à partir du /clusters À l’aide de l’ID de cluster approprié et définissez le credentialID à la id valeur de l’étape précédente.

Une fois ces étapes terminées, les informations d’identification associées au cluster sont mises à jour et le cluster doit se reconnecter et mettre à jour son état sur available.

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 applications déployées avec les opérateurs OLM (Operator Lifecycle Manager) ou les opérateurs à périmètre cluster.

Le clonage des applications n’est possible qu’avec la même distribution de K8s

Si vous clonez une application entre les clusters, les clusters source et destination doivent être de la même distribution que Kubernetes. Par exemple, si vous clonez une application depuis un cluster OpenShift 4.7, utilisez un cluster de destination qui est également OpenShift 4.7.

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.

Le métal LB 0.11.0 n’est pas pris en charge

Le métallique LB 0.11.0 n’est pas un équilibreur de charge pris en charge pour le centre de contrôle Astra. Pour plus d’informations sur les équilibreurs de charge pris en charge, reportez-vous à la section "Exigences du centre de contrôle Astra".

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".

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.

Protection des données pour Astra Control Center alors que l’application n’est pas encore disponible

Cette version ne prend pas en charge la gestion d’Astra en tant qu’application à l’aide des options de snapshot, de sauvegarde ou de restauration.

Les pods défectueux affectent la gestion des applications

Si une application gérée contient des pods dans un état non sain, Astra Control ne peut pas créer de nouvelles sauvegardes et de nouveaux clones.

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.

Trident n’est pas désinstallé d’un cluster

Lorsque vous dégérez un cluster depuis Astra Control Center, Trident n’est pas automatiquement désinstallé du cluster. Pour désinstaller Trident, vous devez procéder comme ça "Suivez ces étapes dans la documentation Trident".

Trouvez plus d’informations