Pod Orchestrator dans CrashLoopBackOff ou 1/2 en cours d'exécution redémarrent plusieurs fois

Description

Si le pod Orchestrator dans CrashLoopBackOff ou 1/2 s'exécute en redémarrrant plusieurs fois, l'échec peut être lié aux clés d'authentification du fournisseur de stockage d'objets, Ceph.

Pour vérifier si l'échec est lié à Ceph, exécutez les commandes suivantes :

kubectl -n uipath get pod -l app.kubernetes.io/component=orchestrator

Si la sortie de cette commande est similaire à l'une des options suivantes, vous devez exécuter une commande supplémentaire.

Option 1:
NAME                            READY   STATUS    RESTARTS   AGE
orchestrator-6dc848b7d5-q5c2q   1/2     Running   2          6m1s
OR 
Option 2
NAME                            READY   STATUS             RESTARTS   AGE
orchestrator-6dc848b7d5-q5c2q   1/2     CrashLoopBackOff   6          16m

Vérifiez si l'échec est lié aux clés d'authentification Ceph en exécutant la commande suivante :

kubectl -n uipath logs -l app.kubernetes.io/component=orchestrator | grep 'Error making request with Error Code InvalidAccessKeyId and Http Status Code Forbidden' -o

Si la sortie de la commande ci-dessus contient la chaîne Error making request with Error Code InvalidAccessKeyId and Http Status Code Forbidden, l'échec est dû aux clés d'authentification Ceph.

Solution

Réexécutez les tâches rook-ceph-configure-script-job et credential-manager à l'aide des commandes suivantes :

kubectl -n uipath-infra get job "rook-ceph-configure-script-job" -o json | jq 'del(. | .spec.selector, .spec.template.metadata.labels)' | kubectl replace --force -f -
kubectl -n uipath-infra get job "credential-manager-job" -o json | jq 'del(. | .spec.selector, .spec.template.metadata.labels)' | kubectl replace --force -f -
kubectl -n uipath delete pod -l app.kubernetes.io/component=orchestrator