Unhealthy services after cluster restore or rollback

Descripción

Después de la restauración o reversión de un clúster, AI Center, Orchestrator, la plataforma, Document Understanding o Task Mining pueden no estar correctos y los registros del pod RabbitMQ muestran el siguiente error:

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

Solución

Para solucionar el problema, comprueba si algunos o todos los pods de RabbitMQ están en estado CrashLoopBackOff debido al problema de escritura de datos de la tabla Mnesia.

Si todos los pods se están ejecutando, siga los siguientes pasos:

1. Eliminar los usuarios en 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. Elimina los secretos de la aplicación RabbitMQ en el espacio de nombres de 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. Elimina los secretos de la aplicación RabbitMQ en el espacio de nombres de 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. Sincronice la aplicación sfcore a través de ArgoCD y espere a que se complete la sincronización:
   
   

   

   
   

5. Realiza un reinicio de implementación en todas las aplicaciones del espacio de nombres de UiPath:

   kubectl -n uipath rollout restart deploy

Si algunos pods están en estado CrashLoopBackOff, siga los siguientes pasos:

1. Identifica qué pods de Ra ConejoMQ están atascados en el estado CrashLoopBackOff CrashLoopBackOff comprueba los registros de pods

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

2. Compruebe la salida de los comandos anteriores. Si el problema está relacionado con la escritura de datos de la tabla de Mnesia, debería ver un mensaje de error similar al siguiente:

   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 solucionar el problema, realiza los siguientes pasos:

   1. Encuentre el número de réplicas de RabbitMQ:

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

   2. Reducir las réplicas de RabbitMQ:

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

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

   3. Espere hasta que finalicen todos los pods de RabbitMQ:

      kubectl -n rabbitmq get pod

   4. Busque y elimine el PVC del pod de RabbitMQ que está atascado en el estado CrashLoopBackOff :

      kubectl -n rabbitmq get pvc

      kubectl -n rabbitmq delete pvc <crashloopbackupoff_pod_pvc_name>

   5. Escala las réplicas de RabbitMQ:

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

   6. Compruebe si todos los pods de RabbitMQ están en buen estado:

      kubectl -n rabbitmq get pod