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.

Limitations générales

Voici quelques restrictions qui affectent la gestion des clusters Kubernetes par Astra Control Service dans tous les déploiements Kubernetes pris en charge.

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

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

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 Service requiert 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.

NetApp Cloud Volumes ONTAP n’est pas officiellement pris en charge pour Amazon Web Services

Depuis le 17 janvier 2023, la version d’Astra Control Service, NetApp Cloud Volumes ONTAP n’est pas encore officiellement prise en charge pour Amazon Web Services.

Limitations de la gestion des clusters GKE

Les limites suivantes s’appliquent à la gestion des clusters Kubernetes dans Google Kubernetes Engine (GKE).

Les applications Google Marketplace n’ont pas été validées

NetApp n’a pas validé les applications déployées depuis Google Marketplace. Certains utilisateurs signalent des problèmes de découverte ou de sauvegarde des applications Postgres, MariaDB et MySQL déployées à partir de Google Marketplace.

Quel que soit le type d’application que vous utilisez avec Astra Control Service, vous devez toujours tester vous-même le flux de travail de sauvegarde et de restauration afin de vous assurer que vous respectez vos exigences de reprise après incident.

Limites de gestion des applications

Les restrictions suivantes affectent la gestion des applications par le service Astra Control.

De même, vous ne pouvez pas restaurer collectivement plusieurs applications qui utilisent le même namespace

Si vous gérez plusieurs applications qui utilisent le même espace de noms (en créant plusieurs définitions d’applications dans Astra Control), vous ne pouvez pas restaurer toutes les applications dans un espace de noms différent. Chaque application doit être restaurée dans son propre espace de noms distinct.

Astra Control n’attribue pas automatiquement de compartiments par défaut pour les instances de cloud

Astra Control n’attribue pas automatiquement de compartiment par défaut à une instance de cloud. Vous devez définir manuellement un compartiment par défaut pour une instance de cloud. Si un compartiment par défaut n’est pas défini, vous ne pourrez pas effectuer les opérations de clonage d’applications entre les deux clusters.

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

Les clones d’application échouent après le déploiement d’une application avec une classe de stockage définie

Après le déploiement d’une application avec une classe de stockage définie explicitement (par exemple, helm install …​-set global.storageClass=netapp-cvs-perf-extreme), les tentatives ultérieures de clonage de l’application nécessitent que le cluster cible ait la classe de stockage spécifiée à l’origine. Le clonage d’une application avec une classe de stockage définie explicitement dans un cluster ne disposant pas de la même classe de stockage échouera. Il n’y a pas d’étapes de récupération dans ce scénario.

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 :

  • "Apache K8ssandra"

    Note 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.
  • "IC Jenkins"

  • "Cluster Percona XtraDB"

Notez qu’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.

Note Lors des opérations de clonage, les applications nécessitant une ressource IngressClass ou des crochets Web ne doivent pas avoir ces ressources déjà définies sur le cluster de destination.

Limites du contrôle d’accès basé sur des rôles (RBAC)

Les restrictions suivantes s’appliquent à la façon dont Astra Control limite l’accès des utilisateurs aux ressources et aux fonctionnalités.

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 utilisateur membre avec des contraintes d’espace de noms ne peut pas accéder aux applications clonées ou restaurées tant qu’un utilisateur administrateur 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 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.