Plataforma de automação da Dell: Problemas de upgrade O cofre do portal não está iniciando
Resumo: Este artigo descreve a solução para problemas de upgrade da plataforma de automação da Dell quando os pods do Portal Vault não estão sendo exibidos.
Sintomas
Os usuários podem enfrentar problemas devido a um webhook mutante conflitante ao atualizar a plataforma de automação da Dell.
O primeiro sintoma é que o upgrade fica travado por um longo tempo (mais de 25 minutos) na etapa do PORTAL ChartKey implantação. O registro de instalação principal mostra:
... Orchestrator chart exists. Skip unarchive... Portal chart exists. Skip unarchive... Portal Installation has started OperationType: INSTALL OperationStatus: IN_PROGRESS ChartKey: PORTAL
Esse problema geralmente bloqueia o upgrade em um momento em que a implementação do Portal Vault aparece na lista dos pods. O cofre mostra 2/3 dos estados READY para duas de suas implementações. Gostar:
#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 ...
Os logs mostram que o cofre não consegue se comunicar entre os nós:
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"
Causa
A causa raiz desse problema é o Webhook mutante conflitante no Orchestrator, que interfere no portal.
Esse conflito surge quando o Webhook mutante do Orchestrator não está configurado corretamente, fazendo com que o sidecar não consiga criptografar o tráfego de saída. Como resultado, a lógica de terminação SSL não consegue lidar adequadamente com o tráfego, levando ao caos no namespace. Geralmente, esse problema ocorre em instalações que foram instaladas inicialmente com o 2.2 NativeEdge Orchestrator (NEO) ou versões anteriores e que passaram por upgrade posteriormente.
Explicação
Um webhook mutante é um recurso do Kubernetes que permite a modificação de recursos, como pods, antes que eles sejam criados ou atualizados. No contexto da Dell Automation Platform, o Webhook mutante do Orchestrator desempenha um papel crucial na injeção de sidecars nos pods. Historicamente, as instalações eram feitas em um único namespace, eliminando a necessidade de um seletor de namespace. No entanto, nas versões mais recentes, um seletor de namespace é necessário para evitar que o webhook mutante do orquestrador interfira em outros componentes. Isso garante que a injeção do sidecar ocorra dentro do namespace correto.
Resolução
Para resolver esse problema, é essencial modificar a configuração do Webhook mutante do Orchestrator antes de iniciar o processo de upgrade.
- Reverter para o snapshot de pré-upgrade
- Remova os dados do checkpoint do
ConfigMaps. Isso ajuda a garantir um processo de upgrade limpo e bem-sucedido. Para remover oConfigMaps, use os seguintes comandos:
#kubectl get cm -A | grep check hzp checkpoint-data 7 31m #kubectl delete cm checkpoint-data -n hzp
Corrigindo o webhook:
Antes de iniciar (ou reiniciar) o upgrade, adicione a seguinte entrada ao webhooks.namespaceSelector.matchExpressions na configuração de webhook mutante do Orchestrator:
kubectl edit mutatingwebhookconfigurations hzp-iam-sidecar-injector
Encontre a seguinte seção:
....
namespaceSelector:
matchExpressions:
...
Caso esta seção não contenha esse trecho, adicione-o. O recuo é importante!
- key: kubernetes.io/metadata.name
operator: In
values:
- hzp
Isso impede que o webhook mutante do orquestrador interfira no portal. Quando aplicada, a injeção de sidecar não é aplicada ao namespace "portal". Isso resolve o problema enfrentado em todos os pods.