Problemi noti
Suggerisci modifiche
PDF
I problemi noti identificano i problemi che potrebbero impedire l'utilizzo corretto di questa versione del prodotto.
I seguenti problemi noti riguardano la versione corrente:
Il ripristino di un'applicazione comporta una dimensione PV superiore a quella del PV originale
Se si ridimensiona un volume persistente dopo la creazione di un backup e poi si ripristina da tale backup, le dimensioni del volume persistente corrispondono alle nuove dimensioni del PV invece di utilizzare le dimensioni del backup.
I cloni delle applicazioni non riescono a utilizzare una versione specifica di PostgreSQL
I cloni delle applicazioni all'interno dello stesso cluster si guastano costantemente con il grafico BitNami PostgreSQL 11.5.0. Per clonare correttamente, utilizzare una versione precedente o successiva del grafico.
I cloni delle applicazioni non funzionano quando si utilizzano i vincoli di contesto di protezione OCP a livello di account di servizio (SCC)
Un clone dell'applicazione potrebbe non riuscire se i vincoli del contesto di protezione originale sono configurati a livello di account di servizio all'interno dello spazio dei nomi nel cluster OpenShift Container Platform. Quando il clone dell'applicazione non funziona, viene visualizzato nell'area delle applicazioni gestite di Astra Control Center con lo stato Removed. Vedere "articolo della knowledge base" per ulteriori informazioni.
I backup e le snapshot delle applicazioni non vengono eseguiti se la classe volumesnapshotclass viene aggiunta dopo la gestione di un cluster
Backup e snapshot non vengono eseguiti con un UI 500 error in questo scenario. Come soluzione, aggiornare l'elenco delle applicazioni.
I cloni delle applicazioni si guastano dopo l'implementazione di un'applicazione con una classe di storage set
Dopo che un'applicazione è stata distribuita con una classe di storage esplicitamente impostata (ad esempio, helm install …-set global.storageClass=netapp-cvs-perf-extreme), i successivi tentativi di clonare l'applicazione richiedono che il cluster di destinazione abbia la classe di storage specificata in origine. La clonazione di un'applicazione con una classe di storage esplicitamente impostata su un cluster che non ha la stessa classe di storage non avrà esito positivo. In questo scenario non sono disponibili procedure di ripristino.
La gestione di un cluster con Astra Control Center non riesce quando il file kubeconfig predefinito contiene più di un contesto
Non è possibile utilizzare un kubeconfig con più di un cluster e un contesto. Vedere "articolo della knowledge base" per ulteriori informazioni.
I cluster gestiti non vengono visualizzati in NetApp Cloud Insights quando ci si connette tramite un proxy
Quando il centro di controllo Astra si connette a NetApp Cloud Insights tramite un proxy, i cluster gestiti potrebbero non essere visualizzati in Cloud Insights. Come soluzione alternativa, eseguire i seguenti comandi su ciascun cluster gestito:
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 podLe operazioni di gestione dei dati dell'app non riescono e si verificano errori di servizio interni (500) quando Astra Trident è offline
Se Astra Trident su un cluster di applicazioni diventa offline (e viene riportato online) e si verificano 500 errori di servizio interni durante il tentativo di gestione dei dati dell'applicazione, riavviare tutti i nodi Kubernetes nel cluster di applicazioni per ripristinare la funzionalità.