Gerenciar o comportamento de falhas durante a atualização

Este guia descreve os recursos de comportamento em caso de falha na atualização do AOSM (Azure Operator Service Manager - Gerenciador de Serviço do Operador do Microsoft Azure) para funções de rede de contêiner (CNFs). Para retries mais rápidas, use pausar em caso de falha. Para retornar ao ponto de partida, use a reversão na falha.

Visão geral de pausa em caso de falha

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

• Um usuário inicia uma operação de reputação do SNS com pausa em caso de falha habilitada.
• Os NfApps são processados após a ordenação updateDependsOn ou na ordem sequencial em que aparecem.
• Se houver falha em uma operação de instalação ou atualização do nfApp, a configuração de reversão atômica será cumprida para essa operação e para o nfApp.
• Nenhum NfApp concluído anteriormente passa por operações adicionais.
• A tarefa termina e deixa o recurso SNS em estado de falha.

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

Atualização bem-sucedida

Uma atualização é considerada bem-sucedida se todos os nfApps atingirem o estado de destino desejado sem gerar falhas na instalação ou atualização do helm. Nessas condições, o Gerenciador de Serviços de Operador do Azure retorna o seguinte status operacional e mensagem:

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

Atualização malsucedida

Uma atualização será considerada malsucedida se qualquer nfApp causar uma falha ao instalar ou atualizar o helm. Nessas condições, o Gerenciador de Serviços de Operador do Azure retorna o seguinte status operacional e mensagem:

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

Visão geral da reversão em caso de falha

Para resolver o risco de versões incompatíveis do nfApp, o Gerenciador de Serviço de Operador do Azure dá suporte à reversão de nível NF em caso de falha. Com essa opção habilitada, se uma operação nfApp falhar, o nfApp com falha e todos os nfApps concluídos anteriormente poderão ser revertidos para o estado de versão inicial. Esse método minimiza ou elimina a quantidade de tempo em que a NF é exposta a incompatibilidades de versão do nfApp. O recurso de reversão opcional em caso de falha funciona da seguinte maneira:

• Um usuário inicia uma operação de reputação do SNS com reversão em caso de falha habilitada.
• Os NfApps são processados após a ordenação updateDependsOn ou na ordem sequencial em que aparecem.
• O estado atômico para todos os NfApps é definido como verdadeiro, e todos os valores fornecidos pelo operador são ignorados.
• Um instantâneo das versões atuais do nfApp é capturado e armazenado.
• A imagem instantânea é usada para determinar as ações individuais do nfApp executadas para reverter as ações previamente concluídas com êxito.
  • helm install ação em componentes excluídos,
  • helm rollback ação em componentes atualizados,
  • helm delete ação em componentes recém-instalados
• Caso uma operação de instalação ou atualização do nfApp falhe, uma reversão atômica do nfApp com falha será executada primeiro.
• Após a reversão atômica, os NfApps concluídos anteriormente são restaurados para a versão de instantâneo original, com as ações mais recentes revertidas primeiro.
• A tarefa termina e deixa o recurso SNS em estado de falha.

Atualização bem-sucedida

Uma atualização é considerada bem-sucedida se todos os nfApps atingirem o estado de destino desejado sem gerar falhas na instalação ou atualização do helm. Nessas condições, o Gerenciador de Serviços de Operador do Azure retorna o seguinte status operacional e mensagem:

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

Reversão bem-sucedida

Uma reversão será considerada bem-sucedida se todos os NfApps concluídos anteriormente atingirem o estado de instantâneo original sem gerar uma falha de reversão do helm. Nessas condições, o Gerenciador de Serviços de Operador do Azure retorna o seguinte status operacional e mensagem:

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

Reversão sem êxito

Uma reversão será considerada malsucedida se qualquer aplicativo nfApps concluído anteriormente não atingir o estado de instantâneo original, resultando em uma falha de reversão do helm. Nessas condições, o Gerenciador de Serviço do Operador do Azure interrompe o processamento de qualquer nfApps elegível para reversão e encerra com o seguinte status operacional e mensagem:

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

Configurar a reversão em caso de falha

O método mais flexível para controlar o comportamento em caso de falha é estender um novo parâmetro do esquema de grupo de configuração (CGS), rollbackEnabled, para permitir o controle de valor do grupo de configuração (CGV) por meio de roleOverrideValues no conteúdo da 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 pode agora fornecer um valor de tempo de execução, sob roleOverrideValues, como parte do conteúdo de reput da NF.

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

Gerenciar nfApps que não suportam rollback

Quase todos os editores têm alguns nfApps que não são compatíveis com a reversão do helm. Esses nfApps talvez sejam provenientes de terceiros que normalmente não dão suporte a requisitos estritos de resiliência. Esses nfApps podem ser aplicativos de banco de dados com requisitos complicados de gerenciamento de esquema. Considere as seguintes restrições ao integrar serviços com nfApps que não dão suporte à reversão.

• nfApps que não dão suporte à reversão não podem ser ignorados.
• A ordem de rollback do nfApp não pode ser alterada.
• A abordagem Incremental-NFDV deve ser usada nessas situações.

Reversão seletiva usando NFDVs incrementais

A composição de uma função de rede pode incluir nfAppa que não dá suporte a uma reversão do helm. Exemplos conhecidos são Elastic e VoltDb. Uma tentativa de reverter um desses nfApps interromperá o nfApp. Buscar aprimoramentos do editor para fazer essas reclamações de reversão do nfApps é a melhor solução. Não é suportado um parâmetro para ignorar a reversão, pois isso introduz o risco de um estado implantado não definido em um NFDV. Esse comportamento não determinístico aumenta significativamente a área de superfície de teste e prejudica as garantias de confiabilidade das implantações. Em vez disso, o método NFDV incremental permite a execução de reversão seletiva, garantindo estados de implantação determinística.

Abordagem NFDV incremental

É recomendável que os editores usem uma combinação de configurações applicationEnablement, skipUpgrade e nfRollbackEnabled em CGVs, juntamente com vários NFDVs, para segmentar logicamente nfApps em conjuntos com base na compatibilidade de reversão. Essa estratégia incremental de NFDV permite que os operadores dividam as implantações em várias operações, ignorando a reversão para tabelas selecionadas e preservando a reversão para o restante. Essa abordagem simula efetivamente o comportamento de reversão por gráfico usando constructos de nível NFDV. Considere o seguinte exemplo, onde uma função de rede é composta por 20 nfApps, sendo que cinco delas não dão suporte à reversão.

• NFDV1
  • Executa a instalação da versão inicial 1.
    • Contém todos os 20 nfApps em um estado habilitado.
  • No CGV1: rollbackEnabled: true.
    • Na primeira instalação, uma falha apaga os gráficos e não usa reversão.
• NFDV2:
  • Executa a atualização da primeira etapa para a versão 2.
    • Contém todos os 20 nfApps, mas habilita apenas os cinco nfApps sem suporte para reversão.
  • No CGV2:
    • Use skipUpgrade: true para os 15 nfApps com suporte de reversão.
    • Defina nfRollbackEnabled: false.
      • Com êxito, apenas cinco nfApps são atualizados.
      • Em caso de falha, nenhuma reversão é executada.
        • Devido a limitações de gráfico, a carga de trabalho é deixada em um estado não determinístico. Nenhuma reversão é possível. Para recuperar, há duas opções:
          • Corrija NFDV2 e tente a atualização novamente.
          • Rebaixar para NFDV1 com skipUpgrade: false
• NFDV3:
  • Executa a atualização da segunda etapa para a versão 2
    • Contém todos os 20 nfApps, mas habilita apenas os 15 nfApps com suporte de reversão.
  • No CGV3:
    • Use skipUpgrade: true para os 5 nfApps atualizados anteriormente por meio do NFDV2.
    • Defina nfRollbackEnabled: true.
      • Com êxito, os 15 nfApps restantes são atualizados
      • Em caso de falha, ocorre uma reversão para restaurar o estado inicial.

Essa abordagem proporciona uma organização mais clara e melhor gerenciamento de aplicativos que não dão suporte às operações padrão do Helm. Mantém a idempotência e o estado da operação no cluster refletido pela última operação. O NFDV 2/3 também pode ser usado para operações de instalação (instalação da versão anterior não necessária) com qualquer diferença no estado de meta. O tempo de atualização geral e a confiabilidade da implantação permanecem os mesmos.

Solucionar problemas de reversão em caso de falha

Noções básicas sobre os estados dos pods

Entender os diferentes estados dos pods é crucial para uma resolução de problemas eficaz. A seguir estão os estados dos pods mais comuns:

• Pendente: o agendamento do pod está em andamento pelo Kubernetes.
• Em execução: todos os contêineres no pod estão em execução e íntegros.
• Falha: um ou mais contêineres no pod foram 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 de contêiner está em andamento pelo runtime do contêiner.

Verificar o status e os logs do pod

Comece verificando o status do pod e os logs 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 tendo problemas com PVCs, poderá usar os seguintes comandos para depurá-los:

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

O comando "get persistentvolumeclaims" lista todos os PVCs do 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.