Fehlerhafte Dienste nach Clusterwiederherstellung oder Rollback

Beschreibung

Nach einer Clusterwiederherstellung oder einem Rollback sind AI Center, Orchestrator, Platform, Document Understanding oder Task Mining möglicherweise fehlerhaft, wobei die RabbitMQ-Pod-Protokolle den folgenden Fehler anzeigen:

[root@server0 UiPathAutomationSuite]# k -n rabbitmq logs rabbitmq-server-0
2022-10-29 07:38:49.146614+00:00 [info] <0.9223.362> accepting AMQP connection <0.9223.362> (10.42.1.161:37524 -> 10.42.0.228:5672)
2022-10-29 07:38:49.147411+00:00 [info] <0.9223.362> Connection <0.9223.362> (10.42.1.161:37524 -> 10.42.0.228:5672) has a client-provided name: rabbitConnectionFactory#77049094:2100
2022-10-29 07:38:49.147644+00:00 [erro] <0.9223.362> Error on AMQP connection <0.9223.362> (10.42.1.161:37524 -> 10.42.0.228:5672, state: starting):
2022-10-29 07:38:49.147644+00:00 [erro] <0.9223.362> PLAIN login refused: user 'aicenter-service' - invalid credentials
2022-10-29 07:38:49.147922+00:00 [info] <0.9223.362> closing AMQP connection <0.9223.362> (10.42.1.161:37524 -> 10.42.0.228:5672 - rabbitConnectionFactory#77049094:2100)
2022-10-29 07:38:55.818447+00:00 [info] <0.9533.362> accepting AMQP connection <0.9533.362> (10.42.0.198:45032 -> 10.42.0.228:5672)
2022-10-29 07:38:55.821662+00:00 [info] <0.9533.362> Connection <0.9533.362> (10.42.0.198:45032 -> 10.42.0.228:5672) has a client-provided name: rabbitConnectionFactory#2100d047:4057
2022-10-29 07:38:55.822058+00:00 [erro] <0.9533.362> Error on AMQP connection <0.9533.362> (10.42.0.198:45032 -> 10.42.0.228:5672, state: starting):
2022-10-29 07:38:55.822058+00:00 [erro] <0.9533.362> PLAIN login refused: user 'aicenter-service' - invalid credentials
2022-10-29 07:38:55.822447+00:00 [info] <0.9533.362> closing AMQP connection <0.9533.362> (10.42.0.198:45032 -> 10.42.0.228:5672 - rabbitConnectionFactory#2100d047:4057)

Lösung

Um das Problem zu beheben, überprüfen Sie, ob sich einige oder alle RabbitMQ-Pods aufgrund des Schreibproblems der Mnesia-Tabellendaten im Status CrashLoopBackOff befinden.

Wenn alle Pods ausgeführt werden, führen Sie die folgenden Schritte aus:

1. Löschen Sie die Benutzer in RabbitMQ:

   kubectl -n rabbitmq exec rabbitmq-server-0 -c rabbitmq -- rabbitmqctl  list_users -s --formatter json | jq '.[]|.user' | grep -v default_user | xargs -I{} kubectl -n rabbitmq exec rabbitmq-server-0 -c rabbitmq -- rabbitmqctl delete_user {}
   

2. Löschen Sie die geheimen RabbitMQ-Anwendungsgeheimnisse im UiPath-Namespace:

   kubectl -n uipath get secret --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep -i rabbitmq-secret | xargs -I{} kubectl -n uipath delete secret {}
   

3. Löschen Sie die RabbitMQ-Anwendungsgeheimnisse im RabbitMQ-Namespace:

   kubectl -n rabbitmq get secret --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep -i rabbitmq-secret | xargs -I{} kubectl -n rabbitmq delete secret {}
   

4. Synchronisieren Sie die Anwendung sfcore über ArgoCD und warten Sie, bis die Synchronisierung abgeschlossen ist:

   

5. Führen Sie einen Rollout-Neustart für alle Anwendungen im UiPath-Namespace durch:

   kubectl -n uipath rollout restart deploy
   

Wenn sich einige Pods im Status CrashLoopBackOff befinden, führen Sie die folgenden Schritte aus:

1. Ermitteln Sie, welche RabbitMQ-Pods im Status CrashLoopBackOff hängen bleiben, und überprüfen Sie die Pod-Protokolle CrashLoopBackOff von RabbitMQ:

   kubectl -n rabbitmq get pods
   kubectl -n rabbitmq logs <CrashLoopBackOff-Pod-Name>
   

2. Überprüfen Sie die Ausgabe der vorherigen Befehle. Wenn das Problem mit dem Schreiben von Daten in die Mnesia-Tabelle zusammenhängt, sollten Sie eine Fehlermeldung ähnlich der folgenden erhalten:

   Mnesia('[e-mail]'): ** ERROR ** (could not write core file: eacces)
    ** FATAL ** Failed to merge schema: Bad cookie in table definition rabbit_user_permission: '[e-mail]' = {cstruct,rabbit_user_permission,set,[],['[e-mail]','[e-mail]','[e-mail]'],[],[],0,read_write,false,[],[],false,user_permission,[user_vhost,permission],[],[],[],{{1667351034020261908,-576460752303416575,1},'[e-mail]'},{{4,0},{'[e-mail]',{1667,351040,418694}}}}, '[e-mail]' = {cstruct,rabbit_user_permission,set,[],['[e-mail]'],[],[],0,read_write,false,[],[],false,user_permission,[user_vhost,permission],[],[],[],{{1667372429216834387,-576460752303417087,1},'[e-mail]'},{{2,0},[]}}
   

3. Führen Sie die folgenden Schritte aus, um das Problem zu beheben:
   1. Ermitteln Sie die Anzahl der RabbitMQ-Replikate:

rabbitmqReplicas=$(kubectl -n rabbitmq get rabbitmqcluster rabbitmq -o json | jq -r '.spec.replicas') 2. Verringern Sie die RabbitMQ-Replikate:

kubectl -n rabbitmq patch rabbitmqcluster rabbitmq -p "{\"spec\":{\"replicas\": 0}}" --type=merge

kubectl -n rabbitmq scale sts rabbitmq-server --replicas=0 3. Warten Sie, bis alle RabbitMQ-Pods beendet sind:

kubectl -n rabbitmq get pod 4. Prüfen Sie auf ausstehende Volume-Snapshots: kubectl get volumesnapshot -n rabbitmq <crashloopbackupoff_pod_pvc_name> | grep false 5. Wenn ein ausstehender Volume-Snapshot vorhanden ist, löschen Sie ihn: kubectl delete volumesnapshot -n rabbitmq <pending_volume_snapshot_name> 6. Suchen und löschen Sie den PVC des RabbitMQ-Pods, der im Status CrashLoopBackOff festhängt:

kubectl -n rabbitmq get pvc

kubectl -n rabbitmq delete pvc <crashloopbackupoff_pod_pvc_name> 7. Skalieren Sie die RabbitMQ-Replikate:

kubectl -n rabbitmq patch rabbitmqcluster rabbitmq -p "{\"spec\":{\"replicas\": $rabbitmqReplicas}}" --type=merge 8. Überprüfen Sie, ob alle RabbitMQ-Pods fehlerfrei sind:

kubectl -n rabbitmq get pod