Appliquez le correctif suivant à tous les clusters Kubernetes où la version 21.08.65 de ACC a été déployée. Il doit également être appliqué si l’ACC est redéployé.

Pour résoudre ce problème :

Le correctif supprime les deux sujets suivants de ClusterRoleBinding: "acc-operator-manager-rolebinding"

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

Les volumes créés avec des unités décimales échouent à l’aide du processus de sauvegarde ou de clonage Astra Control Center. Voir la "article de la base de connaissances" pour en savoir plus.

Après une opération de protection des données (clonage, sauvegarde, restauration) et après le redimensionnement du volume persistant, il y a vingt minutes de retard avant que la nouvelle taille du volume ne s’affiche dans l’interface utilisateur. Ce délai dans l’interface utilisateur peut également survenir lors de l’ajout ou de la modification de ressources d’application. Dans ce cas, une opération de protection des données fonctionne avec succès en quelques minutes et vous pouvez utiliser le logiciel de gestion pour le système back-end pour confirmer la modification de la taille du volume.

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.

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.

Si vous tentez de réutiliser un compartiment utilisé par une autre installation ou une installation précédente d’Astra Control Center, la sauvegarde et la 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 type de fournisseur de compartiment approprié avec les identifiants appropriés pour ce fournisseur. Par exemple, l’interface utilisateur accepte NetApp ONTAP S3 comme type avec 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.

Parfois, une ou plusieurs sauvegardes dans Astra Control Center sont conservées au-delà du numéro spécifié pour être conservées dans le programme de sauvegarde. Ces sauvegardes supplémentaires doivent être supprimées dans le cadre d’une sauvegarde planifiée, mais elles ne sont pas supprimées et bloquées dans un pending état. Pour résoudre le problème, "forcer la suppression" les sauvegardes supplémentaires.

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.

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. Lors du téléchargement ASUP, la vitesse de transfert du fichier réseau pour le bundle peut être insuffisante et le téléchargement peut s’interrompre au bout de 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.

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 :

Si un pod ASUP est arrêté ou redémarré, il est possible que la collecte ASUP soit bloquée en état de génération ou de téléchargement. Effectuez les opérations suivantes "API REST Astra Control" appeler pour lancer à nouveau la collecte manuelle :