Problèmes connus
Suggérer des modifications
PDF
Les problèmes connus identifient les problèmes susceptibles de vous empêcher d'utiliser cette version du produit avec succès.
Les problèmes connus suivants ont une incidence sur la version actuelle :
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 sauvegardes d'applications et les snapshots échouent si la classe volumesnapshotclass est ajoutée après la gestion d'un cluster
Les sauvegardes et les snapshots échouent avec un UI 500 error dans ce scénario. Pour contourner ce problème, actualisez la liste des applications.
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.
Certains pods ne parviennent pas à démarrer après la mise à niveau vers Astra Control Center 23.04
Après la mise à niveau vers Astra Control Center 23.04, certains pods peuvent ne pas démarrer. Pour contourner ce problème, redémarrez manuellement les pods affectés en procédant comme suit :
-
Rechercher les pods affectés, en remplaçant <namespace> par l'espace de noms actuel :
kubectl get pods -n <namespace> | grep au-pod
Les résultats des pods affectés seront similaires à ceux suivants :
pcloud-astra-control-center-au-pod-0 0/1 CreateContainerConfigError 0 13s
-
Redémarrez chaque pod affecté, en remplaçant <namespace> par l'espace de noms actuel :
kubectl delete pod pcloud-astra-control-center-au-pod-0 -n <namespace>
Certains pods affichent un état d'erreur après l'étape de purge de la mise à niveau de 23.04 à 23.04.2
Après la mise à niveau vers Astra Control Center 23.04.2, certains pods peuvent afficher une erreur dans
journaux liés à task-service-task-purge:
kubectl get all -n netapp-acc -o wide|grep purge pod/task-service-task-purge-28282828-ab1cd 0/1 Error 0 48m 10.111.0.111 openshift-clstr-ol-07-zwlj8-worker-jhp2b <none> <none>
Cet état d'erreur signifie qu'une étape de nettoyage n'a pas été exécutée correctement. La mise à niveau globale vers 23.04.2 a réussi. Exécutez la commande suivante pour nettoyer la tâche et supprimer l'état d'erreur :
kubectl delete job task-service-task-purge-[system-generated task ID] -n <netapp-acc or custom namespace>
Un pod de surveillance peut se bloquer dans les environnements Istio
Si vous couplez Astra Control Center avec Cloud Insights dans un environnement Istio, le telegraf-rs le pod peut se bloquer. Pour résoudre ce problème, procédez comme suit :
-
Trouvez le pod qui s'est écrasé :
kubectl -n netapp-monitoring get pod | grep Error
Vous devez voir les résultats similaires à ce qui suit :
NAME READY STATUS RESTARTS AGE telegraf-rs-fhhrh 1/2 Error 2 (26s ago) 32s
-
Redémarrez le module en panne, en le remplaçant
<pod_name_from_output>avec le nom du pod affecté :kubectl -n netapp-monitoring delete pod <pod_name_from_output>
Vous devez voir les résultats similaires à ce qui suit :
pod "telegraf-rs-fhhrh" deleted
-
Vérifiez que le pod a redémarré et qu'il n'est pas dans un état d'erreur :
kubectl -n netapp-monitoring get pod
Vous devez voir les résultats similaires à ce qui suit :
NAME READY STATUS RESTARTS AGE telegraf-rs-rrnsb 2/2 Running 0 11s
Les clusters gérés n'apparaissent pas dans NetApp Cloud Insights lors de la connexion via un proxy
Lorsque le centre de contrôle Astra se connecte à NetApp Cloud Insights par le biais d'un proxy, il se peut que les clusters gérés n'apparaissent pas dans Cloud Insights. Pour contourner ce problème, exécutez les commandes suivantes sur chaque cluster géré :
kubectl get cm telegraf-conf -o yaml -n netapp-monitoring | sed '/\[\[outputs.http\]\]/c\ [[outputs.http]]\n use_system_proxy = true' | kubectl replace -f -kubectl get cm telegraf-conf-rs -o yaml -n netapp-monitoring | sed '/\[\[outputs.http\]\]/c\ [[outputs.http]]\n use_system_proxy = true' | kubectl replace -f -kubectl get pods -n netapp-monitoring --no-headers=true | grep 'telegraf-ds\|telegraf-rs' | awk '{print $1}' | xargs kubectl delete -n netapp-monitoring podLes 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é.