Dell Automatisierungsplattform: Upgradeprobleme Portal-Vault startet nicht

Beim Upgrade der Dell Automatisierungsplattform können Probleme aufgrund eines widersprüchlichen mutierenden Webhook auftreten.

Das erste Symptom ist, dass das Upgrade über einen längeren Zeitraum (mehr als 25 Minuten) im Schritt der PORTAL ChartKey Einsatz. Das Hauptinstallationsprotokoll zeigt Folgendes an:

...
Orchestrator chart exists. Skip unarchive...
Portal chart exists. Skip unarchive...
Portal Installation has started
OperationType: INSTALL OperationStatus: IN_PROGRESS ChartKey: PORTAL

Dieses Problem blockiert in der Regel das Upgrade in einem Moment, in dem die Portal-Vault-Bereitstellung in der Liste der Pods angezeigt wird. Der Vault zeigt 2/3 des Status READY für zwei seiner Bereitstellungen an. Mögen:

#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
...

Die Protokolle zeigen, dass der Vault nicht zwischen den Nodes kommunizieren kann:

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"

Die Hauptursache für dieses Problem ist der in Konflikt stehende mutierende Webhook im Orchestrator, der das Portal stört.

Dieser Konflikt tritt auf, wenn der Webhook "Mutating Webhook" des Orchestrators nicht ordnungsgemäß konfiguriert ist, was dazu führt, dass der Sidecar ausgehenden Datenverkehr nicht verschlüsseln kann. Infolgedessen kann die SSL-Terminierungslogik den Datenverkehr nicht ordnungsgemäß verarbeiten, was zu einem Chaos im Namespace führt. Dieses Problem tritt in der Regel bei Installationen auf, die anfänglich mit 2.2 NativeEdge Orchestrator (NEO) oder früheren Versionen installiert und später aktualisiert wurden. 

Erklärung

Ein mutierender Webhook ist eine Kubernetes-Funktion, die die Änderung von Ressourcen, z. B. Pods, ermöglicht, bevor sie erstellt oder aktualisiert werden. Im Kontext der Dell Automation Platform spielt der Mutating Webhook des Orchestrators eine entscheidende Rolle bei der Injektion von Sidecars in Pods. In der Vergangenheit wurden Installationen in einem einzigen Namespace durchgeführt, sodass kein Namespace-Selektor erforderlich war. Bei neueren Versionen ist jedoch eine Namespace-Auswahl erforderlich, um zu verhindern, dass der mutierende Webhook des Orchestrator andere Komponenten beeinträchtigt. Dadurch wird sichergestellt, dass die Sidecar-Einschleusung im richtigen Namespace erfolgt.
 

Um dieses Problem zu beheben, ist es wichtig, die mutierende Webhook-Konfiguration des Orchestrators zu ändern, bevor der Upgradeprozess initiiert wird.
 

#kubectl get cm -A | grep check
hzp               checkpoint-data                                        7      31m
#kubectl delete cm checkpoint-data -n hzp

Reparieren des Webhooks:
Bevor Sie das Upgrade starten (oder neu starten), fügen Sie den folgenden Eintrag zum webhooks.namespaceSelector.matchExpressions -Pfad in der Webhook-Konfiguration "Mutating Webhook" des Orchestrators: 

kubectl edit mutatingwebhookconfigurations hzp-iam-sidecar-injector

Suchen Sie den folgenden Abschnitt:

....
 namespaceSelector:
      matchExpressions:
...

Falls dieser Abschnitt dieses Snippet nicht enthält, fügen Sie dieses Snippet hinzu. Einrückung ist wichtig!

    - key: kubernetes.io/metadata.name
      operator: In
      values:
      - hzp

Dadurch wird verhindert, dass der mutierende Webhook des Orchestrators in das Portal eingreift. Wenn die Sidecar-Einschleusung angewendet wird, wird sie nicht für den Namespace "portal" angewendet. Dadurch wird das Problem behoben, das in allen Pods auftritt.