クラスターの復元またはロールバック後にサービスが異常になる

説明

クラスターの復元またはロールバック後に、AI Center、Orchestrator、Platform、Document Understanding、または Task Mining が異常になり、RabbitMQ ポッド ログに次のエラーが表示されることがあります。

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

解決策

この問題を解決するには、Mnesia テーブルのデータ書き込みの問題が原因で一部またはすべての RabbitMQ ポッドが CrashLoopBackOff ステートになっているのかどうかを確認します。

すべてのポッドが動作している場合は、以下の手順を実行します。

1. 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. UiPath 名前空間で RabbitMQ アプリケーション シークレットを削除します。

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

3. RabbitMQ 名前空間で 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. ArgoCD を介して sfcore アプリケーションを同期し、同期が完了するまで待ちます。
   
   

   

   
   

5. UiPath 名前空間ですべてのアプリケーションに対してロールアウトの再実行を行います。

   kubectl -n uipath rollout restart deploy

一部のポッドが CrashLoopBackOff ステートである場合は、以下の手順を実行します。

1. CrashLoopBackOff ステートでスタックしている RabbitMQ ポッドを特定し、RabbitMQ の CrashLoopBackOff ポッド ログを確認します。

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

2. 前のコマンドの出力を確認します。問題が Mnesia テーブルのデータ書き込みに関連している場合は、次のようなエラー メッセージが表示されます。

   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. この問題を修正するには、次の手順に従います。

   1. RabbitMQ レプリカの数を確認します。

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

   2. RabbitMQ レプリカを縮小します。

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

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

   3. すべての RabbitMQ ポッドが終了するまで待ちます。

      kubectl -n rabbitmq get pod

   4. 保留中のボリュームスナップショットを確認します。

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

   5. 保留中のボリューム スナップショットが存在する場合は、削除します。

      kubectl delete volumesnapshot -n rabbitmq <pending_volume_snapshot_name>

   6. CrashLoopBackOff ステートでスタックしている RabbitMQ ポッドの PVC を見つけて削除します。

      kubectl -n rabbitmq get pvc

      kubectl -n rabbitmq delete pvc <crashloopbackupoff_pod_pvc_name>

   7. RabbitMQ レプリカを拡大します。

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

   8. すべての RabbitMQ ポッドが正常かどうかを確認します。

      kubectl -n rabbitmq get pod