Plate-forme d’automatisation Dell : Problèmes de mise à niveau Le coffre-fort du portail ne démarre pas
Résumé: Cet article décrit la solution aux problèmes de mise à niveau de la plate-forme d’automatisation Dell, lorsque les pods Portal Vault ne sont pas disponibles.
Symptômes
Les utilisateurs peuvent rencontrer des problèmes en raison d’un webhook mutant conflictuel lors de la mise à niveau de Dell Automation Platform.
Le premier symptôme est que la mise à niveau reste bloquée pendant une longue période (plus de 25 minutes) à l’étape du PORTAL ChartKey déploiement. Le journal d’installation principal indique :
... Orchestrator chart exists. Skip unarchive... Portal chart exists. Skip unarchive... Portal Installation has started OperationType: INSTALL OperationStatus: IN_PROGRESS ChartKey: PORTAL
Ce problème bloque généralement la mise à niveau lorsque le déploiement du coffre-fort du portail apparaît dans la liste des pods. Le coffre-fort affiche les 2/3 de l’état READY pour deux de ses déploiements. Comme:
#kubectl get po -A ... dapp edgevault-0 3/3 Running 0 30m dapp edgevault-1 2/3 Running 0 30m dapp edgevault-2 2/3 Running 0 30m ...
Les logs indiquent que l’archive ne parvient pas à communiquer entre les nœuds :
2025-10-30T15:27:26.896Z [INFO] core: attempting to join possible raft leader node: leader_addr=http://edgevault-2.edgevault-internal:8200 2025-10-30T15:27:26.900Z [ERROR] core: failed to retry join raft cluster: retry=2s err="failed to send answer to raft leader node: error bootstrapping cluster: cluster already has state" 2025-10-30T15:27:28.664Z [ERROR] core: failed to get raft challenge: leader_addr=http://edgevault-1.edgevault-internal:8200 error="error during raft bootstrap init call: context deadline exceeded" 2025-10-30T15:27:28.664Z [ERROR] core: failed to get raft challenge: leader_addr=http://edgevault-0.edgevault-internal:8200 error="error during raft bootstrap init call: context deadline exceeded"
Cause
La cause première de ce problème est le webhook mutant en conflit dans Orchestrator, qui interfère avec le portail.
Ce conflit se produit lorsque le webhook mutant de l’orchestrateur n’est pas correctement configuré, ce qui entraîne l’échec du chiffrement du trafic sortant par le side-car. Par conséquent, la logique de terminaison SSL est incapable de gérer correctement le trafic, ce qui entraîne le chaos dans l’espace de nommage. Ce problème se produit généralement dans les installations qui ont été initialement installées avec NativeEdge Orchestrator (NEO) 2.2 ou des versions antérieures, puis mises à niveau ultérieures.
Explication
Un webhook mutant est une fonctionnalité Kubernetes qui permet de modifier des ressources, telles que des pods, avant leur création ou leur mise à jour. Dans le contexte de Dell Automation Platform, le webhook mutant de l’orchestrateur joue un rôle crucial dans l’injection de side-cars dans les pods. Historiquement, les installations étaient effectuées dans un seul espace de nommage, ce qui éliminait le besoin d’un sélecteur d’espace de nommage. Toutefois, avec les versions plus récentes, un sélecteur d’espace de nommage est requis pour empêcher le webhook mutant d’Orchestrator d’interférer avec d’autres composants. Cela permet de s’assurer que l’injection side-car se produit dans l’espace de nommage approprié.
Résolution
Pour résoudre ce problème, il est essentiel de modifier la configuration du webhook mutant d’Orchestrator avant de lancer le processus de mise à niveau.
- Restauration du snapshot antérieur à la mise à niveau
- Supprimez les données de point de contrôle de
ConfigMaps. Cela garantit un processus de mise à niveau propre et réussi. Pour supprimer leConfigMaps, utilisez les commandes suivantes :
#kubectl get cm -A | grep check hzp checkpoint-data 7 31m #kubectl delete cm checkpoint-data -n hzp
Correction du webhook :
Avant de démarrer (ou de redémarrer) la mise à niveau, ajoutez l’entrée suivante au champ webhooks.namespaceSelector.matchExpressions chemin d’accès dans la configuration du webhook mutant d’Orchestrator :
kubectl edit mutatingwebhookconfigurations hzp-iam-sidecar-injector
Accédez à la section suivante :
....
namespaceSelector:
matchExpressions:
...
Si cette section ne contient pas cet extrait, ajoutez-le. L’indentation est importante !
- key: kubernetes.io/metadata.name
operator: In
values:
- hzp
Cela empêche l’orchestrateur de muter le webhook d’interférer dans le portail. Lorsqu’elle est appliquée, l’injection sidecar n’est pas appliquée pour l’espace de nommage « portal ». Cela résout le problème rencontré dans tous les pods.