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

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

Обзор приостановки при сбое

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

• Пользователь инициирует операцию SNS с включенной функцией паузы при сбое.
• nfApps обрабатываются в порядке updateDependsOn упорядочивания или в той последовательности, в которой они появляются.
• Если операция установки или обновления nfApp завершается сбоем, параметр атомарного отката для этой операции и nfApp учитывается.
• Завершенные NfApps больше не обрабатываются.
• Задача завершает выполнение и оставляет ресурс SNS в состоянии сбоя.

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

Обновление успешно

Обновление считается успешным, если все nfApps достигают требуемого целевого состояния, не приводя к сбоям при установке или обновлении helm. В таких условиях Диспетчер служб оператора Azure возвращает следующее рабочее состояние и сообщение:

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

Обновление неудачно

Обновление считается неудачным, если какая-либо nfApp вызывает сбой при установке или обновлении helm. В таких условиях Диспетчер служб оператора Azure возвращает следующее рабочее состояние и сообщение:

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

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

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

• Пользователь инициирует операцию SNS с откатом в случае сбоя.
• nfApps обрабатываются в порядке updateDependsOn упорядочивания или в той последовательности, в которой они появляются.
• Атомарный режим для всех NfApps установлен в true, любые значения, предоставленные оператором, игнорируются.
• Снимок текущих версий nfApp сохраняется.
• Моментальный снимок используется для определения отдельных действий nfApp, предпринятых для отмены успешно завершенных действий.
  • helm install действие в отношении удаленных компонентов,
  • helm rollback действие на обновленные компоненты,
  • helm delete действие с только что установленными компонентами
• Если операция установки или обновления nfApp завершается ошибкой, сначала выполняется атомарный процесс отката неудачной nfApp.
• После атомарного отката предыдущие завершенные NfApps восстанавливаются до исходной версии моментального снимка, при этом последние действия отменены в первую очередь.
• Задача завершает выполнение и оставляет ресурс SNS в состоянии сбоя.

Обновление успешно

Обновление считается успешным, если все nfApps достигают требуемого целевого состояния, не приводя к сбоям при установке или обновлении helm. В таких условиях Диспетчер служб оператора Azure возвращает следующее рабочее состояние и сообщение:

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

Откат выполнен успешно

Откат считается успешным, если все предыдущие завершенные NfApps достигли исходного состояния моментального снимка без возникновения сбоя отката Helm. В таких условиях Диспетчер служб оператора Azure возвращает следующее рабочее состояние и сообщение:

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

Откат не удался

Откат считается неудачным, если любые ранее завершенные nfApps не достигают исходного состояния моментального снимка и, вместо этого, происходит сбой отката helm. В таких условиях Диспетчер служб Оператора Azure прекращает обработку любых дополнительных nfApps, подлежащих откату, и завершается со следующим служебным статусом и сообщением:

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

Настройте откат в случае сбоя

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

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

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

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

Управление приложениями nfApps, которые не поддерживают откат

Почти у всех издателей есть некоторые nfApps (некоторые приложения), которые не совместимы с функцией отката helm. Эти nfApps могут быть получены от сторонних поставщиков, которые как правило, не обеспечивают строгие требования к резилиентности. Эти приложения nfApps могут быть базами данных с сложными требованиями к управлению схемами. При подключении служб с nfApps, которые не поддерживают откат, следует учитывать следующие ограничения.

• nfApps, которые не поддерживают откат, не могут быть пропущены.
• Порядок отката nfApp не может измениться.
• В этих ситуациях необходимо использовать подход Incremental-NFDV.

Выборочный откат с помощью инкрементных NFDV

Композиция сетевой функции может включать nfAppa, которая не поддерживает helm rollback. Известные примеры: Elastic и VoltDb. Попытка отката одного из этих nfApps сломает nfApp. Стремление к улучшениям в публикациях, чтобы эти nfApps соответствовали требованиям для отката, является наилучшим решением. Параметр для пропуска отката не поддерживается, так как это создает риск развернутого статуса, который не определен в NFDV. Это недетерминированное поведение значительно увеличивает область поверхности тестирования и подрывает гарантии надежности развертываний. Вместо этого инкрементный метод NFDV позволяет выборочно исполнять откат, обеспечивая при этом детерминированные состояния развертывания.

Инкрементальный подход NFDV

Рекомендуется, чтобы издатели использовали комбинацию конфигураций applicationEnablement, skipUpgrade и nfRollbackEnabled в CGVs, а также нескольких NFDVs, чтобы логически сегментировать nfApps на наборы на основе совместимости отката. Эта инкрементальная стратегия NFDV позволяет операторам разбить развертывания на несколько операций, обходя откат для выбранных диаграмм, сохраняя откат для остальных. Этот подход эффективно имитирует поведение отката для каждой диаграммы с использованием конструкций на уровне NFDV. Рассмотрим следующий пример, где сетевая функция состоит из 20 nfApps, из которых пять не поддерживают отмену изменений.

• NFDV1
  • Выполняет первоначальную установку версии 1.
    • Содержит все 20 nfApps в активированном состоянии.
  • В CGV1: rollbackEnabled: true.
    • При первой установке в случае сбоя диаграммы удаляются, и не выполняется откат изменений.
• NFDV2:
  • Выполняет первое обновление до версии 2.
    • Содержит все 20 nfApps, но включает только те пять из них, которые не имеют поддержки отката.
  • В CGV2:
    • Используйте skipUpgrade: true для 15 nfApps с поддержкой отмены изменений.
    • Задайте nfRollbackEnabled: false.
      • При успешном выполнении обновляется только пять nfApps.
      • При сбое откат не выполняется.
        • Из-за ограничений диаграммы рабочая нагрузка остается в недетерминированном состоянии. Откат не возможен. Для восстановления существует два варианта:
          • Исправьте NFDV2 и повторите попытку обновления.
          • Понижение до NFDV1 с skipUpgrade: false
• NFDV3:
  • Выполняет обновление до версии 2 на второй стадии
    • Содержит все 20 nfApps, но активирует только 15 nfApps с поддержкой отката.
  • В CGV3:
    • Используйте skipUpgrade: true для 5 nfApps, ранее обновленных с помощью NFDV2.
    • Задайте nfRollbackEnabled: true.
      • В случае успеха оставшиеся 15 nfApps будут обновлены
      • При сбое происходит откат для восстановления начального состояния.

Этот подход обеспечивает более чистое разделение и управляемость приложений, которые не поддерживают стандартные операции Helm. Поддерживает идемпотентность и состояние операции в кластере, отраженное последней операцией. NFDV 2/3 можно использовать напрямую для операций установки, а также в случаях, когда не требуется установка предыдущей версии, даже при различных состояниях цели. Общее время обновления и надежность развертывания остаются неизменными.

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

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

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

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

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

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

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

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

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

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

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

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