Si vous définissez une application avec un espace de noms, supprimez l'espace de noms, puis réinstallez l'application dans le même espace de noms, l'opération échoue avec un code d'erreur 409. Pour définir l'application à l'aide de l'espace de noms recréé, supprimez d'abord l'ancienne instance d'application.

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.

Dans ce scénario, les sauvegardes et les instantanés échouent avec une erreur UI 500. Pour contourner ce problème, actualisez la liste des applications.

Si vous effectuez une restauration sur place d'une application (restaurez-la dans son espace de noms d'origine) et que la classe de stockage de l'application utilise le ontap-nas-economy pilote, l'opération de restauration peut échouer si le répertoire de snapshot n'est pas masqué. Avant de remettre le produit en place, suivez les instructions de la section "Sauvegardez et restaurez les opérations ontap-nas" pour masquer le répertoire d'instantanés.

Lorsque vous restaurez une application à partir d'une sauvegarde vers un back-end de stockage utilisant le chiffrement à la volée Kerberos, l'opération de restauration peut échouer. Ce problème n'affecte pas la restauration à partir d'un snapshot ni la réplication des données d'application à l'aide de NetApp SnapMirror.

Si vous supprimez la sauvegarde immuable d'une application après l'expiration de la politique de conservation du compartiment, la sauvegarde est supprimée d'Astra Control, mais pas du compartiment. Ce problème sera corrigé dans une prochaine version.

Si Astra Trident sur un cluster d'application est mis hors ligne (et reconnecté) et 500 erreurs de service internes sont rencontrées lors de la tentative de gestion des données d'application, redémarrez tous les nœuds Kubernetes du cluster d'application pour restaurer la fonctionnalité.