Dieses Handbuch enthält Dokumentation für Wickr Enterprise. Wenn Sie AWS Wickr verwenden, finden Sie weitere Informationen im AWS Wickr Administration Guide oder im AWS Wickr User Guide.
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Fehlerbehebung bei eingebetteten Wickr-Cluster-Installationen
Bei allen Schritten zur Fehlerbehebung wird davon ausgegangen, dass Sie Shell-Zugriff auf die Instanz haben, auf der die Wickr Embedded Cluster-Installation ausgeführt wird, und dass Sie den ./wickr-enterprise-ha
shell Befehl ausgeführt haben, um direkt mit der Kubernetes-Installation interagieren zu können.
Allgemeine Probleme
Die Schaltfläche „Knoten hinzufügen“ fehlt auf dem Bildschirm „Clusterverwaltung“
Airgapped-Installationen
Wenn Sie eine Airgap-Installation verwenden, wenden Sie sich bitte an den Wickr-Support, um Support bei der Behebung dieses Verhaltens zu erhalten.
Standardinstallationen
Wenn Ihre Lizenz die Embedded Cluster Multi-Node-Berechtigung beinhaltet, führen Sie eine Lizenzsynchronisierung durch, um die neueste Version zu erhalten. Wenn Sie sich nicht sicher sind oder diesen Anspruch nicht haben, wenden Sie sich bitte an den Wickr-Support.
Führen Sie die folgenden Schritte aus, um eine Lizenzsynchronisierung durchzuführen.
-
Navigieren Sie zum KOTS-Bedienfeld.
-
Suchen Sie auf der Dashboard-Seite den Lizenzbereich oben rechts auf der Seite.
-
In diesem Abschnitt sollten Sie in der oberen rechten Ecke einen Hyperlink „Lizenz synchronisieren“ sehen. Wählen Sie den Hyperlink aus.
-
Sobald die Lizenz synchronisiert wurde, wird die Benutzeroberfläche aktualisiert und die Meldung Letzte Synchronisierung vor einigen Sekunden angezeigt.
-
Wählen Sie auf der KOTS-Dashboardseite im Abschnitt Version die Option Erneut bereitstellen aus.
-
Sobald die erneute Bereitstellung abgeschlossen ist, kehren Sie zur Clusterverwaltung zurück, wo Sie Knoten hinzufügen können.
Probleme beim Upgrade
Das Upgrade blieb beim Upgrade des Clusters hängen
Wenn Ihr Upgrade beim Upgrade des Clusters hängen bleibt, bedeutet dies wahrscheinlich, dass einige Pods nicht ordnungsgemäß beendet wurden. Melden Sie sich bei der Instanz an und verwenden Sie den ./wickr-enteprise-ha shell Befehl, um die Shell-Umgebung für die Verwaltung der Kubernetes-Installation aufzurufen.
-
Identifizieren Sie die Pods, die noch laufen:
kubectl -n kotsadm get pods | grep Running -
kubectl -n kotsadm delete podname-of-running-podAnmerkung
Wenn einer der laufenden Pods
embedded-cluster-upgrade-XXXXXXXXXXXXXX-xxxxxkotsadm-xxxxxxxoder ähnliches ist, löschen Sie ihn nicht, da diese Pods für die Durchführung des Upgrades erforderlich sind. -
Stellen Sie sicher, dass keine Pods mehr laufen.
kubectl -n kotsadm get pods | grep Running
Dieses Verfahren sollte es ermöglichen, das Cluster-Upgrade mit dem Wickr-Upgrade fortzusetzen.
Die Anwendung wurde während des Cluster-Upgrades nicht aktualisiert und kann keine neue Version bereitstellen
Wenn die Anwendung nach dem Upgrade weiterhin die alte Version verwendet, befindet sich die neue Version möglicherweise in einem inkonsistenten Zustand.
Überprüfen Sie die Kubernetes-Installationsaufzeichnungen:
-
Öffnen Sie die Kubernetes-Shell im Installationsprogramm.
./wickr-enterprise-ha shell -
Führen Sie den folgenden kubectl-Befehl aus:
kubectl get installations -
Die Ausgabe wird ungefähr so aussehen:
[root@ip-172-31-6-72 ~]# kubectl get installations NAME STATE INSTALLERVERSION CREATEDAT AGE 20251113170603 Obsolete 2.1.3+k8s-1.30 2025-11-13T17:06:05Z 22h 20251113180133 Failed 2.6.0+k8s-1.31 2025-11-13T18:01:37Z 21h -
Löschen Sie die fehlgeschlagene Installation.
kubectl delete installation 20251113180133 -
Versuchen Sie erneut, das Upgrade über das KOTS Admin-Panel auszuführen.
RabbitMQ Pod schlägt mit Protokollzeilen fehl Error while waiting for Mnesia tables:
{timeout_waiting_for_tables}
Das Geheimnis und der Speicher von RabbitMQ sind nicht synchron. Dies passiert normalerweise, wenn mehrere RabbitMQ-Instanzen ausgeführt werden und es zu einem Fehler bei der Auswahl eines Leiters oder eines Quorums kommt. Um dieses Problem zu beheben, löschen Sie den RabbitMQ-Dienst und seine Speichervolumes und stellen Sie sie dann erneut bereit.
Gehen Sie wie folgt vor, um das fehlgeschlagene RabbitMQ zu löschen.
-
Lösche das RabbitMQ Statefulset.
kubectl -n kotsadm delete statefulset rabbitmq —cascade=orphan -
Löschen Sie die verbleibenden RabbitMQ-Pods. Wenn mehrere RabbitMQ-X-Pods laufen, geben Sie diesen Befehl mehrmals ein und aktualisieren Sie den RabbitMQ-X-Wert so, dass er den zusätzlichen Pod-Namen entspricht.
kubectl -n kotsadm delete pod rabbitmq-0 -
PVCsLöschen Sie den entsprechenden. Wenn mehrere Pods ausgeführt werden, geben Sie diesen Befehl mehrmals ein und aktualisieren Sie sie so data-RabbitMQ-X, dass sie den entsprechenden Pods entsprechen.
kubectl -n kotsadm delete pvc data-rabbitmq-0 -
Überprüfen Sie, ob noch Pods übrig sind. Wenn dies erfolgreich ist, sollte dies nichts ausgeben.
kubectl -n kotsadm get pods|grep -i rabbitmq -
Prüfen Sie PVCs, ob noch welche übrig sind. Bei Erfolg sollte nichts ausgegeben werden.
kubectl -n kotsadm get pvc|grep -i rabbitmq -
Stellen Sie die Lösung erneut über das KOTS Admin-Panel bereit.
Weitere Informationen zur Fehlerbehebung finden Sie unter Problembehandlung.