Unhealthy services after cluster restore or rollback

Description

Após uma restauração ou reversão de cluster, AI Center, Orchestrator, Platform, Document Understanding ou Task Mining podem não estar íntegros, com os logs do pod RabbitMQ mostrando o seguinte erro:

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

Solução

Para corrigir o problema, verifique se alguns ou todos os pods RabbitMQ estão no estado CrashLoopBackOff devido ao problema de gravação de dados da tabela Mnesia.

Se todos os pods estiverem em execução, execute as seguintes etapas:

1. Exclua os usuários no 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. Exclua os segredos do aplicativo RabbitMQ no namespace 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. Exclua os segredos do aplicativo RabbitMQ no namespace do 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. Sincronize o aplicativo sfcore via ArgoCD e aguarde a conclusão da sincronização:
   
   

   

   
   

5. Execute uma reinicialização de distribuição em todos os aplicativos no namespace UiPath:

   kubectl -n uipath rollout restart deploy

Se alguns pods estiverem no estado CrashLoopBackOff, execute as seguintes etapas:

1. Identifique quais pods RabbitMQ estão presos no estado CrashLoopBackOff e verifique os logs do pod RabbitMQ CrashLoopBackOff :

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

2. Verifique a saída dos comandos anteriores. Se o problema estiver relacionado à gravação de dados da tabela Mnesia, você verá uma mensagem de erro semelhante à seguinte:

   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. Para corrigir o problema, siga as seguintes etapas:

   1. Encontre o número de réplicas do RabbitMQ:

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

   2. Reduza as réplicas do RabbitMQ:

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

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

   3. Aguarde até que todos os pods do RabbitMQ sejam encerrados:

      kubectl -n rabbitmq get pod

   4. Check for pending volume snapshots:

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

   5. If any pending volume snapshot exists, delete it:

      kubectl delete volumesnapshot -n rabbitmq <pending_volume_snapshot_name>

   6. Encontre e exclua o PVC do pod RabbitMQ que está preso no estado CrashLoopBackOff :

      kubectl -n rabbitmq get pvc

      kubectl -n rabbitmq delete pvc <crashloopbackupoff_pod_pvc_name>

   7. Faça réplicas do RabbitMQ em escala:

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

   8. Verifique se todos os pods do RabbitMQ estão íntegros:

      kubectl -n rabbitmq get pod