Services défectueux après la restauration ou l'annulation du cluster

Description

À la suite d'une restauration ou d'un retour en arrière du cluster, AI Center, Orchestrator, Platform, Document Understanding ou Task Mining peuvent ne pas fonctionner correctement, les journaux des pods RabbitMQ affichant l'erreur suivante :

[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)

Solution

Pour résoudre le problème, vérifiez si certains ou tous les pods RabbitMQ sont à l'état CrashLoopBackOff en raison du problème d'écriture des données de la table Mnesia.

Si tous les pods sont en cours d'exécution, procédez comme suit :

1. Supprimez les utilisateurs dans 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. Supprimez les clés secrètes de l'application RabbitMQ dans l'espace de noms UiPath :

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

3. Supprimez les clés secrètes de l'application RabbitMQ dans l'espace de noms RabbitMQ :

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

4. Synchronisez l'application sfcore via ArgoCD et attendez la fin de la synchronisation :
   
   

   

   
   

5. Effectuez un redémarrage du déploiement sur toutes les applications de l'espace de noms UiPath :

   kubectl -n uipath rollout restart deploy

Si certains pods sont à l'état CrashLoopBackOff, procédez comme suit :

1. Identifiez les pods RabbitMQ bloqués dans l’état CrashLoopBackOff et consultez les journaux des pods RabbitMQ CrashLoopBackOff :

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

2. Vérifiez la sortie des commandes précédentes. Si le problème est lié à l'écriture des données de la table Mnesia, vous devriez voir un message d'erreur semblable au suivant :

   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. Pour résoudre le problème, procédez comme suit :

   1. Trouvez le nombre de répliques RabbitMQ :

      rabbitmqReplicas=$(kubectl -n rabbitmq get rabbitmqcluster rabbitmq -o json | jq -r '.spec.replicas')

   2. Réduire les répliques RabbitMQ :

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

      kubectl -n rabbitmq scale sts rabbitmq-server --replicas=0

   3. Attendez que tous les pods RabbitMQ soient terminés :

      kubectl -n rabbitmq get pod

   4. Rechercher les instantanés de volume en attente :

      kubectl get volumesnapshot -n rabbitmq  <crashloopbackupoff_pod_pvc_name> | grep false

   5. Si un instantané de volume en attente existe, supprimez-le :

      kubectl delete volumesnapshot -n rabbitmq <pending_volume_snapshot_name>

   6. Recherchez et supprimez la PVC du pod RabbitMQ qui est bloqué à l’état CrashLoopBackOff :

      kubectl -n rabbitmq get pvc

      kubectl -n rabbitmq delete pvc <crashloopbackupoff_pod_pvc_name>

   7. Augmentez la taille des réplicas RabbitMQ :

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

   8. Vérifiez si tous les pods RabbitMQ sont sains :

      kubectl -n rabbitmq get pod