Si vous définissez une application avec une étiquette k8s inexistante, Astra Control Center crée, gère, puis supprime immédiatement l’application. Pour éviter cela, ajoutez l’étiquette k8s aux pods et aux ressources après la gestion de l’application par Astra Control Center.

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

Si vous redimensionnez un volume persistant après avoir créé une sauvegarde puis restauré à partir de cette sauvegarde, la taille du volume persistant correspond à la nouvelle taille du volume persistant, et non à la taille de la sauvegarde.

Les clones de volumes persistants de très grande taille et consommés par intermittence peuvent être lents, selon l’accès du cluster au magasin d’objets. Si le clone est suspendu et qu’aucune donnée n’a été copiée pendant plus de 30 minutes, Astra Control met fin à l’action de clonage.

Les clones d’applications au sein du même cluster échouent systématiquement avec le graphique Bitnami PostgreSQL 11.5.0. Pour effectuer un clonage réussi, utilisez une version antérieure ou ultérieure du graphique.

Un clone d’application peut échouer si les contraintes de contexte de sécurité d’origine sont configurées au niveau du compte de service au sein de l’espace de noms sur le cluster OCP. Lorsque le clone de l’application échoue, il apparaît dans la zone applications gérées du Centre de contrôle Astra avec l’état Removed. Voir la "article de la base de connaissances" pour en savoir plus.

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.

Si vous tentez de réutiliser un compartiment utilisé par une autre installation ou précédente d’Astra Control Center, les opérations de sauvegarde et de restauration échoueront. Vous devez utiliser un autre godet ou nettoyer complètement le godet utilisé précédemment. Vous ne pouvez pas partager de compartiments entre les instances d’Astra Control Center.

Lorsque vous ajoutez un compartiment, sélectionnez le fournisseur approprié et entrez les identifiants appropriés pour ce fournisseur. Par exemple, l’interface utilisateur accepte NetApp ONTAP S3 comme type et accepte les identifiants StorageGRID. Toutefois, toutes les futures sauvegardes et restaurations des applications à l’aide de ce compartiment é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.

Lors d’une sauvegarde ou d’une restauration d’application, vous pouvez éventuellement spécifier un ID de compartiment. Cependant, une opération de clonage d’application utilise toujours le compartiment par défaut défini. Il n’existe aucune option pour modifier les compartiments d’un clone. Si vous souhaitez contrôler le godet utilisé, vous pouvez l’un des deux "modifiez les paramètres par défaut du compartiment" ou faites un "sauvegarde" suivi d’un "restaurer" séparément.

Vous ne pouvez pas utiliser un kubeconfig avec plus d’un cluster et un contexte. Voir la "article de la base de connaissances" pour en savoir plus.

Si Trident sur un cluster d’applications est déconnecté (et rétabli en ligne) et 500 erreurs de service internes se produisent lors de la tentative de gestion des données des applications, redémarrez tous les nœuds Kubernetes du cluster d’applications pour restaurer la fonctionnalité.

Si l’exécution d’un crochet d’exécution prend plus de 25 minutes, le crochet échoue, créant une entrée de journal d’événements avec un code retour « N/A ». Tout instantané affecté sera dépassé et marqué comme ayant échoué, une entrée du journal d’événements signalant le délai d’attente est alors indiquée.

Puisque les crochets d’exécution réduisent ou désactivent complètement la fonctionnalité de l’application contre laquelle ils s’exécutent, vous devez toujours essayer de réduire le temps d’exécution de vos crochets personnalisés.

Lors de la collecte ASUP, l’état du bundle dans l’interface utilisateur est signalé comme étant l’un ou l’autre collecting ou done. La collecte peut prendre jusqu’à une heure pour les grands environnements. Pendant le téléchargement ASUP, la vitesse de transfert des fichiers réseau du bundle peut s’avérer insuffisante et le téléchargement peut durer 15 minutes sans indication dans l’interface utilisateur. Les problèmes de téléchargement dépendent de la taille des données ASUP, de la taille du cluster mise à l’échelle, et si le délai de collecte dépasse la limite de sept jours.

Lorsque vous utilisez le snapshot-contrôleur Kubernetes (également appelé External-snapshotter) version 4.2.0 avec Kubernetes 1.20 ou 1.21, les snapshots peuvent échouer. Pour éviter cela, utilisez un autre "version prise en charge" D’un snapshoter externe, comme la version 4.2.1, avec Kubernetes version 1.20 ou 1.21.

Si vous tentez de restaurer une ou plusieurs applications gérées individuellement dans un espace de noms simultanément, les opérations de restauration peuvent échouer après une longue période. Pour résoudre ce problème, restaurez chaque application une par une.

Si vous mettez à niveau un système Astra Control Center qui utilise un registre qui ne nécessite pas d’authentification vers une version plus récente qui utilise un registre qui nécessite une authentification, la mise à niveau échoue. Pour résoudre ce problème, procédez comme suit :

Si vous n’avez pas dégéré les clusters avant de désinstaller Astra Control Center, vous pouvez supprimer manuellement les pods dans l’espace de noms netapp-Monitoring et dans l’espace de noms à l’aide des commandes suivantes :

Vous pouvez supprimer manuellement les CRD Traefik. Les CRDS sont des ressources globales, et leur suppression peut avoir un impact sur d’autres applications du cluster.