Skip to main content
Eine neuere Version dieses Produkts ist erhältlich.
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Bekannte Probleme

Beitragende
PDFs

Die Wiederherstellung einer App führt zu einer PV-Größe, die größer ist als das ursprüngliche PV

Wenn Sie ein persistentes Volume nach der Erstellung eines Backups skalieren und dann aus diesem Backup wiederherstellen, wird die Größe des persistenten Volumes an die neue PV-Größe angepasst, anstatt die Backup-Größe zu verwenden.

Applikationsklone können nicht mit einer bestimmten Version von PostgreSQL verwendet werden

App-Klone innerhalb desselben Clusters schlagen konsequent mit dem Bitnami PostgreSQL 11.5.0 Diagramm fehl. Um erfolgreich zu klonen, verwenden Sie eine frühere oder höhere Version des Diagramms.

Anwendungsklone sind bei der Verwendung von OCP-Sicherheitskontextsensitonen (SCC) auf Servicekontoebene fehlgeschlagen.

Ein Applikationsklon kann fehlschlagen, wenn die ursprünglichen Einschränkungen des Sicherheitskontexts auf der Service-Kontoebene im Namespace im Cluster der OpenShift Container Platform konfiguriert sind. Wenn der Anwendungsklon ausfällt, wird er im Bereich Managed Applications im Astra Control Center mit dem Status angezeigt Removed. Siehe "knowledgebase-Artikel" Finden Sie weitere Informationen.

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 standardmäßige kubeconfig-Datei 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.

Einige Pods können nach dem Upgrade auf Astra Control Center 23.04 nicht gestartet werden

Nach dem Upgrade auf Astra Control Center 23.04 können einige Pods möglicherweise nicht gestartet werden. Um dies zu umgehen, starten Sie die betroffenen Pods mithilfe der folgenden Schritte manuell neu:

  1. Ermitteln Sie die betroffenen Pods, und ersetzen Sie <namespace> durch den aktuellen Namespace:

    kubectl get pods -n <namespace> | grep au-pod

    Die betroffenen Pods haben ähnliche Ergebnisse wie die folgenden:

    pcloud-astra-control-center-au-pod-0 0/1 CreateContainerConfigError 0 13s

  2. Starten Sie jeden betroffenen Pod neu, indem Sie <namespace> durch den aktuellen Namespace ersetzen:

    kubectl delete pod pcloud-astra-control-center-au-pod-0 -n <namespace>

Einige Pods zeigen nach der Phase des Upgrades von 23.04 auf 23.04.2 einen Fehlerstatus

Nach einem Upgrade auf Astra Control Center 23.04.2 wird bei einigen Pods möglicherweise ein Fehler angezeigt
Protokolle in Bezug auf 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>

Dieser Fehlerstatus bedeutet, dass ein Bereinigungsschritt nicht ordnungsgemäß ausgeführt wurde. Das Upgrade auf 23.04.2 ist erfolgreich. Führen Sie den folgenden Befehl aus, um die Aufgabe zu bereinigen und den Fehlerstatus zu entfernen:

kubectl delete job task-service-task-purge-[system-generated task ID] -n <netapp-acc or custom namespace>

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:

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

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

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

Verwaltete Cluster werden nicht in NetApp Cloud Insights angezeigt, wenn die Verbindung über einen Proxy hergestellt wird

Wenn Astra Control Center eine Verbindung zu NetApp Cloud Insights über einen Proxy herstellt, werden gemanagte Cluster möglicherweise nicht im Cloud Insights angezeigt. Führen Sie als Workaround die folgenden Befehle auf jedem verwalteten Cluster aus:

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 pod

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.

Weitere Informationen