Поделиться через

Управление поведением сбоя обновления

  • Статья

Обзор

В этом руководстве описаны функции поведения сбоя обновления Оператора Azure Service Manager (AOSM) для сетевых функций контейнеров (CNFs). Эти функции, как часть инициативы по безопасному обновлению AOSM, предлагают выбор между более быстрыми повторными попытками, приостанавливая сбой, а не возвращаясь к начальной точке, с откатом при сбое.

Приостановка сбоя

Любое обновление с помощью AOSM начинается с репозитория сетевой службы сайта (SNS). Операция повторного использования обрабатывает приложения сетевой функции (NfApps), найденные в версии проектирования сетевой функции (NFDV). Операция репозитория реализует следующую логику по умолчанию:

  • NfApps обрабатываются в соответствии с порядком updateDependsOn или в последовательном порядке, который они отображаются.
  • NfApps с параметром applicationEnabled, установленным для отключения, пропускаются.
  • NFApps присутствует, но не ссылается на новый NFDV.
  • Последовательность выполнения приостановлена, если какой-либо из обновлений NfApp завершается сбоем, а откат считается откатом.
  • Сбой оставляет ресурс NF в состоянии сбоя.

При приостановке при сбое AOSM откатывает только неудачный NfApp, используя параметры testOptions, installOptions или upgradeOptions. Никаких действий не выполняется для любых NfApps, которые продолжают неудачный NfApp. Этот метод позволяет конечному пользователю устранять неполадки сбоем NfApp, а затем перезапустить обновление с этого момента. Как поведение по умолчанию, этот метод является наиболее эффективным методом, но может привести к несоответствиям сетевой функции (NF) в то время как в смешанном состоянии версии.

Откат при сбое

Чтобы устранить риск несоответствия версий NfApp, AOSM теперь поддерживает откат уровня NF при сбое. Если этот параметр включен, если операция NfApp завершается сбоем, можно выполнить откат до начального состояния версии NfApp и всех предыдущих завершенных NfApps. Этот метод сводит к минимуму или исключает время, когда NF предоставляется несоответствия версии NfApp. Необязательный откат функции сбоя работает следующим образом:

  • Пользователь инициирует операцию репозитория sSNS и включает откат при сбое.
  • Моментальный снимок текущих версий NfApp записывается и сохраняется.
  • Моментальный снимок используется для определения отдельных действий NfApp, выполненных для выполнения обратных действий, которые успешно завершены.
    • Действие "helm install" для удаленных компонентов,
    • Действие "откат helm" для обновленных компонентов,
    • Действие "helm delete" для только что установленных компонентов
  • Сбой NfApp происходит, AOSM восстанавливает NfApps в состояние версии моментального снимка до обновления, при этом последние действия прерваны сначала.

Примечание.

  • AOSM не создает моментальный снимок, если пользователь не включает откат при сбое.
  • Откат при сбое применяется только к успешно завершенным приложениям NFApps.
    • Используйте параметры testOptions, installOptions или upgradeOptions для управления откатом неудачного NfApp.

AOSM возвращает следующее рабочее состояние и сообщения, учитывая соответствующие результаты:

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

Настройка отката при сбое

Наиболее гибким способом управления поведением сбоя является расширение нового параметра схемы группы конфигурации (CGS), откатEnabled, чтобы разрешить управление значением группы конфигурации (CGV) с помощью roleOverrideValues в полезных данных NF. Сначала определите параметр CGS:

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

Примечание.

  • Если nfConfiguration не предоставляется с помощью параметра roleOverrideValues, по умолчанию откат отключен.

При определении нового параметра rollbackEnable оператор теперь может предоставить значение времени выполнения в разделе roleOverrideValues в рамках полезных данных NF.

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

Примечание.

  • Каждая запись roleOverrideValues переопределяет поведение NfAapps по умолчанию.
  • Если несколько записей nfConfiguration находятся в roleOverrideValues, репозиторий NF возвращается в качестве плохого запроса.

Устранение неполадок отката при сбое

Общие сведения о состояниях pod

Понимание различных состояний pod имеет решающее значение для эффективного устранения неполадок. Ниже приведены наиболее распространенные состояния pod:

  • Ожидание: планирование pod выполняется Kubernetes.
  • Выполнение: все контейнеры в модуле pod работают и работают.
  • Сбой. Один или несколько контейнеров в модуле pod завершаются с кодом выхода, отличного от нуля.
  • CrashLoopBackOff: контейнер в модуле pod многократно завершается сбоем, и Kubernetes не может перезапустить его.
  • ContainerCreating: создание контейнера выполняется средой выполнения контейнера.

Проверка состояния и журналов pod

Сначала проверьте состояние и журналы pod с помощью команды kubectl:

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

Команда get pods перечисляет все модули pod в текущем пространстве имен, а также их текущее состояние. Команда журналов извлекает журналы для определенного модуля pod, что позволяет проверять любые ошибки или исключения. Чтобы устранить неполадки в сети, используйте следующие команды:

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

Команда get services отображает все службы в текущем пространстве имен. Эта команда содержит сведения о конкретной службе, включая связанные конечные точки и все соответствующие сообщения об ошибках. Если у вас возникли проблемы с PVCs, для их отладки можно использовать следующие команды:

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

Команда get persistentvolumeclaims перечисляет все pvCs в текущем пространстве имен. Команда описания содержит подробные сведения о конкретном ПВХ, включая состояние, связанный класс хранения и любые соответствующие события или ошибки.