La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Problèmes connus

Contributeurs

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.

La page applications se charge à tout moment lors de la tentative de restauration d’une application appartenant à un cluster supprimé

Lorsque vous essayez de restaurer une application à partir d’un cluster supprimé à partir de la page applications, le chargement de la page applications n’est jamais terminé. Pour contourner ce problème, restaurez l’application à partir du menu actions de l’application de la page de liste applications.

Impossible de définir une application sur un espace de noms qui a été supprimé et recréé

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.

La restauration d’une application entraîne une taille de volume persistant supérieure à celle de l’application initiale

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 d’applications échouent à l’aide d’une version spécifique de PostgreSQL

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.

Les sauvegardes d’applications et les snapshots échouent si la classe volumesnapshotclass est ajoutée après la gestion d’un cluster

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.

Les snapshots finissent par échouer lorsque les snapshots externes sont utilisés version 4.2.0

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.

Les opérations de gestion des données d’application échouent avec l’erreur de service interne (500) lorsque Astra Trident est hors ligne

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