Controlar o comportamento de falha de atualização

Descrição geral

Este guia descreve os recursos de comportamento de falha de atualização do Azure Operator Service Manager (AOSM) para funções de rede de contêiner (CNFs). Esses recursos, como parte da iniciativa de práticas de atualização segura do AOSM, oferecem uma escolha entre tentativas mais rápidas, com pausa em caso de falha, versus retorno ao ponto de partida, com reversão em caso de falha.

Pausa em caso de falha

Qualquer atualização usando o AOSM começa com uma opreação de recolocação do serviço de rede do site (SNS). A operação de reput processa os aplicativos de função de rede (NfApps) encontrados na versão de design de função de rede (NFDV). A operação de reput implementa a seguinte lógica padrão:

• NfApps são processados após a ordem updateDependsOn ou na ordem sequencial em que aparecem.
• NfApps com o parâmetro "applicationEnabled" definido para desativar são ignorados.
• Os NFApps presentes, mas não referenciados pelo novo NFDV, são suprimidos.
• A sequência de execução é pausada se alguma das atualizações do NfApp falhar e uma reversão for considerada.
• A falha deixa o recurso NF em um estado de falha.

Com a pausa na falha, o AOSM reverte apenas o NfApp com falha, por meio dos parâmetros testOptions, installOptions ou upgradeOptions. Nenhuma ação é tomada em qualquer NfApps que prossiga o NfApp com falha. Esse método permite que o usuário final solucione problemas do NfApp com falha e, em seguida, reinicie a atualização a partir desse ponto. Como o comportamento padrão, esse método é o método mais eficiente, mas pode causar inconsistências de função de rede (NF) enquanto em um estado de versão mista.

Reversão em caso de falha

Para lidar com o risco de versões NfApp incompatíveis, o AOSM agora suporta a reversão de nível NF em caso de falha. Com esta opção ativada, se uma operação NfApp falhar, tanto o NfApp com falha, como todos os NfApps concluídos anteriormente, podem ser revertidos para o estado da versão inicial. Esse método minimiza, ou elimina, a quantidade de tempo que o NF é exposto a incompatibilidades de versão do NfApp. O recurso opcional de reversão em caso de falha funciona da seguinte maneira:

• Um usuário inicia uma operação de recolocação do sSNS e habilita a reversão em caso de falha.
• Um instantâneo das versões atuais do NfApp é capturado e armazenado.
• O instantâneo é usado para determinar as ações individuais do NfApp tomadas para reverter as ações concluídas com êxito.
  • Ação "helm install" em componentes excluídos,
  • ação de "reversão de leme" em componentes atualizados,
  • Ação "helm delete" em componentes recém-instalados
• Falha NfApp ocorre, AOSM restaura o NfApps para o estado da versão de instantâneo antes da atualização, com as ações mais recentes revertidas primeiro.

O AOSM retorna o seguinte status operacional e mensagens, dados os respetivos resultados:

  - Upgrade Succeeded
    - Provisioning State: Succeeded
    - Message: <empty>

  - Upgrade Failed, Rollback Succeeded
    - Provisioning State: Failed
    - Message: Application(<ComponentName>) : <Failure Reason>; Rollback succeeded

  - Upgrade Failed, Rollback Failed
    - Provisioning State: Failed
    - Message: Application(<ComponentName>) : <Failure reason>; Rollback Failed (<RollbackComponentName>) : <Rollback Failure reason>

Como configurar a reversão em caso de falha

O método mais flexível para controlar o comportamento de falha é estender um novo parâmetro de esquema de grupo de configuração (CGS), rollbackEnabled, para permitir o controle do valor do grupo de configuração (CGV) via roleOverrideValues na carga útil NF. Primeiro, defina o parâmetro CGS:

{
  "description": "NF configuration",
  "type": "object",
  "properties": {
    "nfConfiguration": {
      "type": "object",
      "properties": {
        "rollbackEnabled": {
          "type": "boolean"
        }
      },
      "required": [
        "rollbackEnabled"
      ]
    }
  }
}

Com o novo parâmetro rollbackEnable definido, o Operador agora pode fornecer um valor de tempo de execução, em roleOverrideValues, como parte da carga útil de reposição NF.

example:
{
  "location": "eastus",
  "properties": {
    // ...
    "roleOverrideValues": [
          "{\"nfConfiguration\":{\"rollbackEnabled\":true}}",
            "{\"name\":\"nfApp1\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\" : \"Disabled\"}}",
            "{\"name\":\"nfApp2\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\" : \"Disabled\"}}",
          //... other nfapps overrides
       ]
  }
}

Como solucionar problemas de reversão em caso de falha

Compreender os estados do pod

Compreender os diferentes estados do pod é crucial para uma solução de problemas eficaz. A seguir estão os estados de pod mais comuns:

• Pendente: O agendamento de pods está em andamento pelo Kubernetes.
• Execução: Todos os recipientes no pod estão funcionando e saudáveis.
• Falha: Um ou mais contêineres no pod são encerrados com um código de saída diferente de zero.
• CrashLoopBackOff: Um contêiner dentro do pod está falhando repetidamente e o Kubernetes não consegue reiniciá-lo.
• ContainerCreating: A criação do contêiner está em andamento pelo tempo de execução do contêiner.

Verificar o estado e os registos do pod

Primeiro, comece verificando o status e os logs do pod usando um comando kubectl:

$ kubectl get pods
$ kubectl logs <pod-name>

O comando get pods lista todos os pods no namespace atual, juntamente com seu status atual. O comando logs recupera os logs de um pod específico, permitindo que você inspecione quaisquer erros ou exceções. Para solucionar problemas de rede, use os seguintes comandos:

$ kubectl get services
$ kubectl describe service <service-name>

O comando get services exibe todos os serviços no namespace atual. O comando fornece detalhes sobre um serviço específico, incluindo os pontos de extremidade associados e quaisquer mensagens de erro relevantes. Se você estiver encontrando problemas com PVCs, você pode usar os seguintes comandos para depurá-los:

$ kubectl get persistentvolumeclaims
$ kubectl describe persistentvolumeclaims <pvc-name>

O comando "get persistentvolumeclaims" lista todos os PVCs no namespace atual. O comando describe fornece informações detalhadas sobre um PVC específico, incluindo o status, a classe de armazenamento associada e quaisquer eventos ou erros relevantes.