Skip to main content
È disponibile una versione più recente di questo prodotto.
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Problemi noti

Collaboratori

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

Un pod di monitoraggio può bloccarsi negli ambienti Istio

Se si associa il centro di controllo Astra a Cloud Insights in un ambiente Istio, il telegraf-rs pod può bloccarsi. Per risolvere il problema, attenersi alla seguente procedura:

  1. Individuare il pod bloccato:

    kubectl -n netapp-monitoring get pod | grep Error

    L’output dovrebbe essere simile a quanto segue:

    NAME READY STATUS RESTARTS AGE
    telegraf-rs-fhhrh 1/2 Error 2 (26s ago) 32s
  2. Riavviare il pod bloccato, sostituendo <pod_name_from_output> con il nome del pod interessato:

    kubectl -n netapp-monitoring delete pod <pod_name_from_output>

    L’output dovrebbe essere simile a quanto segue:

    pod "telegraf-rs-fhhrh" deleted
  3. Verificare che il pod sia stato riavviato e che non si trovi in uno stato di errore:

    kubectl -n netapp-monitoring get pod

    L’output dovrebbe essere simile a quanto segue:

    NAME READY STATUS RESTARTS AGE
    telegraf-rs-rrnsb 2/2 Running 0 11s

Le 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à.

Trova ulteriori informazioni