Skip to main content
Une version plus récente de ce produit est disponible.
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

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 clones d’application échouent lors de l’utilisation des contraintes de contexte de sécurité OCP au niveau du compte de service (SCC)

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 dans l’espace de noms du cluster OpenShift Container Platform. 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.

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 gestion d’un cluster avec Astra Control Center échoue lorsque le fichier kubeconfig par défaut contient plusieurs contextes

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.

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

Les snapshots peuvent échouer avec la version 4.2.0 du contrôleur de snapshot

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.

  1. Exécutez un appel POST pour ajouter un fichier kubeconfig mis à jour au /credentials et récupérer le noeud final affecté id du corps de réponse.

  2. Effectuer un APPEL PUT à partir du /clusters À l’aide de l’ID de cluster approprié et définissez le credentialID à la id valeur de l’étape précédente.

Une fois ces étapes terminées, les informations d’identification associées au cluster sont mises à jour et le cluster doit se reconnecter et mettre à jour son état sur available.

Trouvez plus d’informations