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

Пробы работоспособности в Контейнерах приложений Azure

Пробы работоспособности приложений контейнеров Azure позволяют среде выполнения контейнерных приложений регулярно проверять состояние приложений контейнеров.

Пробы можно настроить исключительно с помощью TCP или HTTP(S).

Приложения контейнеров Azure поддерживают следующие пробы:

Проба Description
Запуск Проверяет, успешно ли запускается приложение. Эта проверка отличается от пробы активности и выполняется во время начального этапа запуска приложения.
Живость Проверяет, работает ли ваше приложение и реагирует.
Готовность Проверяет, готова ли реплика обрабатывать входящие запросы.

Полный список спецификаций проб, поддерживаемых в приложениях контейнеров Azure, см. в спецификациях REST API Azure.

Пробы HTTP

Проверки HTTP позволяют реализовать пользовательскую логику для оценки состояния зависящих компонентов приложения перед сообщением о работоспособном состоянии.

Настройте конечные точки пробы работоспособности для ответа с кодом состояния HTTP, большим или равным 200 и меньшим 400, для указания успешного выполнения. Любой другой код ответа за пределами этого диапазона указывает на сбой.

В следующем примере показано, как реализовать конечную точку liveness в JavaScript.

const express = require('express');
const app = express();

app.get('/liveness', (req, res) => {
  let isSystemStable = false;
  
  // check for database availability
  // check filesystem structure
  //  etc.

  // set isSystemStable to true if all checks pass

  if (isSystemStable) {
    res.status(200); // Success
  } else {
    res.status(503); // Service unavailable
  }
})

Пробы TCP

Проверки TCP ожидают установления соединения с сервером, чтобы указать успешность. Проверка завершается ошибкой, если не удается установить подключение к приложению.

Ограничения

  • Для каждого контейнера можно добавить только один из типов проб.
  • Пробы exec не поддерживаются.
  • Значения портов должны быть целыми числами; именованные порты не поддерживаются.
  • gRPC не поддерживается.

Примеры

В следующем листинге кода показано, как определять пробы работоспособности для контейнеров.

Заполнители ... обозначают пропущенный код. Для получения полной информации о шаблоне ARM смотрите спецификацию API шаблона ARM для Container Apps.

{
  ...
  "containers":[
    {
      "image":"nginx",
      "name":"web",
      "probes": [
        {
          "type": "Liveness",
          "httpGet": {
            "path": "/health",
            "port": 8080,
            "httpHeaders": [
              {
                "name": "Custom-Header",
                "value": "liveness probe"
              }]
          },
          "initialDelaySeconds": 7,
          "periodSeconds": 3
        },
        {
          "type": "Readiness",
          "tcpSocket": {
            "port": 8081
          },
          "initialDelaySeconds": 10,
          "periodSeconds": 3
        },
        {
          "type": "Startup",
          "httpGet": {
            "path": "/startup",
            "port": 8080,
            "httpHeaders": [
              {
                "name": "Custom-Header",
                "value": "startup probe"
              }]
          },
          "initialDelaySeconds": 3,
          "periodSeconds": 3
        }]
    }]
  ...
}

Необязательный failureThreshold параметр определяет количество попыток, когда приложения-контейнеры пытаются выполнить пробу, если выполнение завершается ошибкой. Попытки, превышающие failureThreshold объем, вызывают разные результаты для каждого типа пробы.

Конфигурация по умолчанию

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

Тип пробы Значения по умолчанию
Запуск Протокол: TCP
Порт: целевой порт входящего трафика
Время ожидания: 3 секунды
Период: 1 секунда
Начальная задержка: 1 секунда
Порог успешного выполнения: один
Порог сбоя: 240
Живость Протокол: TCP
Порт: целевой порт входящего трафика
Готовность Протокол: TCP
Порт: целевой порт входящего трафика
Время ожидания: 5 секунд
Период: 5 секунд
Начальная задержка: 3 секунды
Порог успешного выполнения: один
Порог сбоя: 48

Если вы запускаете приложение контейнера в режиме нескольких ревизий, после развертывания ревизии дождитесь завершения проверки готовности, прежде чем переключить трафик на эту ревизию. В режиме единственной версии трафик переключается автоматически после того, как проверка готовности сигнализирует о готовности.

Состояние редакции появляется как неработоспособное, если какая-либо из его реплик завершает проверку готовности, даже если все остальные реплики в редакции работоспособны. Приложения-контейнеры перезапускают реплику, о которой идет речь, пока она снова не станет работоспособной или не будет превышен порог сбоев. Если порог сбоя превышен, попробуйте перезапустить редакцию, но это может означать, что редакция настроена неправильно.

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

В следующем примере показано, как настроить пробы активности и готовности для расширения времени запуска.

"probes": [
       {
        "type": "Liveness",
        "failureThreshold": 3,
        "periodSeconds": 10,
        "successThreshold": 1,
        "tcpSocket": {
          "port": 80
        },
        "timeoutSeconds": 1
       },
       {
         "type": "Readiness",
         "failureThreshold": 48,
         "initialDelaySeconds": 3,
         "periodSeconds": 5,
         "successThreshold": 1,
         "tcpSocket": {
           "port": 80
          },
          "timeoutSeconds": 5
       }]

Следующие шаги

Ведение журнала приложений

  • Last updated on