Compartilhar via

Controlar o comportamento de falha durante de atualização

  • Artigo

Visão geral

Este guia descreve os recursos de comportamento de falha durante a atualização do AOSM (Gerenciador de Serviço do Operador do Microsoft Azure) para CNFs (funções de rede de contêiner). Esses recursos, como parte da iniciativa de práticas seguras de atualização do AOSM, oferecem a escolha entre tentativas mais rápidas, com pausa em caso de falha, e 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 operação de saída do SNS (serviço de rede do site). A operação de saída processa os aplicativos de função de rede (NfApps) encontradas na versão de design de função de rede (NFDV). A operação de saída implementa a seguinte lógica padrão:

  • Os NfApps são processados após a ordenação updateDependsOn ou na ordem sequencial em que aparecem.
  • NfApps com o parâmetro "applicationEnabled" definido como desabilitado são ignorados.
  • Os NFApps presentes, mas não referenciados pelo novo NFDV, são excluídos.
  • A sequência de execução será 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 em caso de falha, o AOSM reverte apenas o NfApp com falha, por meio dos parâmetros testOptions, installOptions ou upgradeOptions. Nenhuma ação é tomada em qualquer NfApp que siga a NfApp que falhou. Esse método permite que o usuário final solucione o problema do NfApp que falhou e, em seguida, 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.

Reverter em caso de falha

Para abordar o risco de versões de NfApp incompatíveis, o AOSM agora dá suporte a reversão em nível de NF em caso de falha. Com essa opção habilitada, se uma operação de NfApp falhar, tanto o NfApp que falhou quanto todos os NfApps anteriores concluídos podem ser revertidos para o estado da versão inicial. Esse método minimiza, ou elimina, o tempo em que o NF está exposto a incompatibilidades de versão dos NfApps. A reversão opcional no recurso de falha funciona da seguinte maneira:

  • Um usuário inicia uma operação de saída 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 executadas para reverter as ações concluídas com êxito.
    • Ação "helm install" em componentes excluídos,
    • Ação "helm rollback" em componentes atualizados,
    • Ação "helm delete" em componentes recém-instalados
  • Se ocorrer uma falha no NfApp, o AOSM restaura os NfApps para o estado da versão do instantâneo antes da atualização, revertendo primeiro as ações mais recentes.

Observação

  • O AOSM não criará um instantâneo se um usuário não habilitar a reversão em caso de falha.
  • Uma reversão em caso de falha só se aplica aos NFApps concluídos com êxito.
    • Use os parâmetros testOptions, installOptions ou upgradeOptions para controlar a reversão do NfApp que falhou.

O AOSM retorna o seguinte status operacional e mensagens, conforme os resultados respectivos:

  - 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 em caso de falha é estender um novo parâmetro do esquema de grupo de configuração (CGS), chamado 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"
      ]
    }
  }
}

Observação

  • Se a nfConfiguration não for fornecida através do parâmetro roleOverrideValues, por padrão a reversão estará desativada.

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 saída da NF.

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

Observação

  • Cada entrada em roleOverrideValues substitui o comportamento padrão dos NfApps.
  • Se várias entradas de nfConfiguration forem encontradas em roleOverrideValues, a saída da NF é retornada como um pedido inválido.

Como 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 de 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.
  • Em 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 enfrentando 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 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.