Bekannte Probleme
Änderungen vorschlagen
PDFs
Bekannte Probleme identifizieren Probleme, die Sie daran hindern könnten, diese Produktversion erfolgreich zu verwenden.
Die folgenden bekannten Probleme wirken sich auf die aktuelle Version aus:
App-Backups und Snapshots schlagen fehl, wenn die Volume-Snapshot-Klasse nach dem Management eines Clusters hinzugefügt wird
Backups und Snapshots schlagen fehl UI 500 error In diesem Szenario. Aktualisieren Sie die App-Liste als Workaround.
Applikationsklone scheitern, nachdem eine Applikation mit einer festgelegten Storage-Klasse implementiert wurde
Nachdem eine Applikation mit einer Storage-Klasse bereitgestellt wurde (z. B. helm install …-set global.storageClass=netapp-cvs-perf-extreme). Nachfolgende Klonversuche der Applikation erfordern, dass das Ziel-Cluster die ursprünglich angegebene Storage-Klasse hat.
Das Klonen einer Applikation mit einer explizit festgelegten Storage-Klasse auf ein Cluster ohne dieselbe Storage-Klasse schlägt fehl. Es gibt keine Wiederherstellungsschritte in diesem Szenario.
Das Verwalten eines Clusters mit Astra Control Center schlägt fehl, wenn die Datei kubeconfig mehr als einen Kontext enthält
Sie können ein kubeconfig nicht mit mehr als einem Cluster und Kontext darin verwenden. Siehe "knowledgebase-Artikel" Finden Sie weitere Informationen.
Ein Monitoring-Pod kann in Istio Umgebungen zum Absturz kommen
Wenn Sie Astra Control Center mit Cloud Insights in einer Istio Umgebung koppeln, bietet die telegraf-rs Pod kann abstürzen. Führen Sie als Workaround die folgenden Schritte aus:
-
Suchen Sie den abgestürzten POD:
kubectl -n netapp-monitoring get pod | grep Error
Sie sollten eine Ausgabe wie die folgende sehen:
NAME READY STATUS RESTARTS AGE telegraf-rs-fhhrh 1/2 Error 2 (26s ago) 32s
-
Starten Sie den abgestürzten Pod neu, und ersetzen Sie ihn
<pod_name_from_output>Mit dem Namen des betroffenen Pods:kubectl -n netapp-monitoring delete pod <pod_name_from_output>
Sie sollten eine Ausgabe wie die folgende sehen:
pod "telegraf-rs-fhhrh" deleted
-
Überprüfen Sie, ob der Pod neu gestartet wurde und sich nicht im Fehlerzustand befindet:
kubectl -n netapp-monitoring get pod
Sie sollten eine Ausgabe wie die folgende sehen:
NAME READY STATUS RESTARTS AGE telegraf-rs-rrnsb 2/2 Running 0 11s
Das Management der App-Daten schlägt mit Fehler des internen Service (500) fehl, wenn Astra Trident offline ist
Wenn Astra Trident auf einem App-Cluster offline geschaltet wird (und wieder online geschaltet wird) und 500 interne Servicefehler auftreten, wenn versucht wird, das App-Datenmanagement zu managen, starten Sie alle Kubernetes-Nodes im App-Cluster neu, um die Funktionalität wiederherzustellen.