Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Приложения контейнеров Azure — это полностью управляемая служба размещения контейнеров без сервера для развертывания микрослужб и контейнерных приложений.
При использовании Azure надежность является общей ответственностью. Корпорация Майкрософт предоставляет ряд возможностей для поддержки устойчивости и восстановления. Вы несете ответственность за понимание того, как работают эти возможности во всех используемых вами службах, а также за выбор возможностей, необходимых для достижения бизнес-целей и целей бесперебойной работы.
В этой статье описывается, как сделать контейнерные приложения устойчивыми к различным потенциальным сбоям и проблемам, в том числе временным сбоям, сбоям зоны доступности, сбоям регионов и обслуживанию служб. В нем также описывается, как использовать резервные копии для восстановления из других типов проблем и выделяет ключевые сведения о соглашении об уровне обслуживания контейнерных приложений (SLA).
Рекомендации по развертыванию в производственной среде
Сведения о развертывании контейнерных приложений для поддержки требований к надежности решения и о том, как надежность влияет на другие аспекты архитектуры, см. в статье "Рекомендации по архитектуре для приложений контейнеров" в Azure Well-Architected Framework.
Обзор архитектуры надежности
При использовании контейнерных приложений вы развертываете среду , которая служит базовой единицей развертывания и определяет безопасную границу вокруг группы приложений-контейнеров. Среда позволяет настроить основные параметры, включая поддержку зоны доступности и конфигурацию сети. Два типа сред — это среды профилей рабочих нагрузок и среды, доступные только для использования. Дополнительные сведения см. в разделе "Структуры вычислений и выставления счетов" в контейнерных приложениях.
Вы можете развернуть несколько приложений в одной среде. Каждое приложение запускает один или несколько контейнеров. Среда также может выполнять одно или несколько заданий, представляющих неинтерактивные задачи. Дополнительные сведения см. в разделе "Контейнеры в контейнерных приложениях" и разделе "Задания в контейнерных приложениях".
Каждое приложение имеет одну или несколько реплик, представляющих запущенные экземпляры приложения. Вы можете управлять масштабированием приложения, включая минимальное и максимальное количество реплик и динамическое добавление и удаление реплик. Планировщик платформы обеспечивает оптимальное распределение между физическими узлами с учетом требований к минимальному количеству реплик. Дополнительные сведения см. в разделе "Настройка правил масштабирования в приложениях контейнеров".
Контейнерные приложения поддерживают надежность приложений с помощью различных возможностей:
Автоматический мониторинг работоспособности: Встроенный контроллер входящего трафика автоматически балансирует трафик между здоровыми репликами. Если реплика теряет работоспособность или ее базовая инфраструктура становится недоступной в течение длительного времени, служба автоматически перезапускает неисправные контейнеры или создает новые реплики. Он также перенаправляет трафик от неработоспособных реплик и управляет повторными попытками подключения в кластере. Этот процесс автоматического восстановления не требует вмешательства клиента и поддерживает указанное число реплик. Для получения дополнительной информации см. Зонды работоспособности.
Устойчивость приложений с помощью Dapr: Контейнерные приложения обеспечивают тесную интеграцию с Dapr, которая является платформой, поддерживающей микрослужбы производственного класса и контейнерные приложения. Dapr включает функции, которые помогают повысить устойчивость, включая обработку сбоев в других службах. Дополнительные сведения см. в разделе "Микрослужбы с контейнерными приложениями".
Устойчивость инфраструктуры для системных компонентов: Эта устойчивость включает плоскость управления, контроллеры входящего трафика и среду выполнения контейнера. В регионах с зонами доступности контейнерные приложения обеспечивают устойчивость к отказам в зоне. Дополнительные сведения см. в разделе "Устойчивость к сбоям зоны доступности".
Устойчивость к временным сбоям
Временные ошибки являются короткими, периодическими сбоями в компонентах. Они часто происходят в распределенной среде, такой как облачная платформа, и являются обычной частью операций. Временные ошибки исправляют себя через короткий период времени. Важно, чтобы приложения могли обрабатывать временные ошибки, обычно повторяя затронутые запросы.
Все облачные приложения должны следовать рекомендациям по обработке временных ошибок Azure при обмене данными с любыми размещенными в облаке API, базами данных и другими компонентами. Дополнительные сведения см. в Рекомендациях по обработке временных сбоев.
Контейнерные приложения автоматически обрабатывают множество временных сбоев с помощью механизмов повторных попыток на уровне платформы и мониторинга работоспособности. Чтобы обеспечить устойчивость приложений к временным сбоям, выполните следующие действия:
Настройте пробы работоспособности , позволяющие платформе обнаруживать и реагировать на условия сбоя для конкретного приложения. Задайте соответствующие пороговые значения сбоев и значения времени ожидания на основе характеристик запуска приложения. Например, чтобы избежать преждевременного перезапуска контейнера во время временных проблем, используйте порог сбоя 3 с периодом 10 секунд для проверок на жизнестойкость. Для получения дополнительной информации см. Зонды работоспособности.
Используйте политики устойчивости обнаружения служб (предварительная версия) для упреждающего предотвращения, обнаружения и восстановления от сбоев запросов службы. Например, при использовании политики устойчивости каждый входящий запрос к приложению может автоматически быть повторно выполнен, если возникает временный сбой, который предотвращает реагирование приложения. Дополнительные сведения см. в разделе "Устойчивость обнаружения служб" (предварительная версия).
Реализуйте логику повторных попыток в приложениях для вызовов внешних служб, подключений к базе данных и запросов API.
Если приложение использует Dapr для интеграции с облачными службами, используйте устойчивость компонентов Dapr (предварительная версия) для настройки повторных попыток, времени ожидания и разбиения цепи.
Для других зависимостей приложение должно обрабатывать временные ошибки. Используйте экспоненциальные стратегии обратной отработки и шаблоны разбиения цепи при вызове внешних служб, чтобы предотвратить каскадные сбои во время сбоев в подчиненных службах. Встроенные функции обнаружения и балансировки нагрузки контейнерных приложений автоматически направляют трафик в обход сбоев, но механизмы повторных попыток на уровне приложения гарантируют плавную и заботливую обработку временных проблем, прежде чем проверки состояния на уровне платформы приведут к перезапуску контейнера.
Проектируйте задания так, чтобы они были устойчивы к временным сбоям, включая сбои во время выполнения задания или в их зависимостях. Создайте задания так, чтобы они могли возобновить работу после перезапуска, или разработайте их с учетом идемпотентности, чтобы они могли безопасно запускаться повторно.
Устойчивость к сбоям зоны доступности
Зоны доступности — это физически отдельные группы центров обработки данных в регионе Azure. При сбое одной зоны службы могут переключиться на одну из оставшихся зон.
При создании среды "Приложения контейнеров" можно включить избыточность зоны для распределения базовой инфраструктуры между несколькими зонами доступности в выбранном регионе Azure. Приложения контейнеров автоматически распределяют реплики ваших приложений по зонам. Это распределение происходит прозрачно, что означает, что не нужно указывать размещение зоны для индивидуальных реплик.
Избыточность зоны повышает устойчивость приложения к сбоям уровня зоны, гарантируя, что реплики приложения-контейнера распределяются по нескольким зонам.
На следующей схеме показано контейнерное приложение с избыточностью между зонами и тремя репликами. Каждая реплика выполняется в отдельной зоне доступности.
Требования
Проверьте поддержку региона. Избыточность зон доступна во всех регионах, поддерживающих контейнерные приложения и зоны доступности.
Сведения о том, какие регионы поддерживают зоны доступности, см. в регионах Azure с поддержкой зон доступности.
Сведения о том, какие регионы поддерживают приложения-контейнеры, см. в разделе "Доступность продукта по регионам".
Используйте профили рабочей нагрузки. Зональная избыточность доступна всем планам контейнерных приложений, включая профили потребления и выделенные профили рабочей нагрузки.
Включите отказоустойчивость зоны во время создания среды. Этот параметр нельзя изменить после создания среды.
Развертывание среды приложений-контейнеров в виртуальной сети. Виртуальная сеть должна находиться в регионе, поддерживающем зоны доступности. Убедитесь, что виртуальная сеть имеет достаточно масштабную подсеть. Для сред потребления необходимо наличие подсети с диапазоном
/23маршрутизации без классов между доменами (CIDR) или большим, а в средах профиля рабочих нагрузок требуется диапазон/27CIDR или больше.Задайте минимальное число реплик как минимум два, чтобы обеспечить распределение между несколькими зонами доступности. Рекомендуется задать более высокое минимальное число реплик, если применяются какие-либо из следующих условий:
Ожидаемая пиковая нагрузка требует более двух реплик.
Вы должны быть устойчивыми к нескольким одновременным сбоям зон.
Вы хотите свести к минимуму время ожидания создания новых реплик в других зонах, когда происходит сбой в зоне.
Себестоимость
При включении зональной избыточности не взимается дополнительная плата сверх стандартных тарифов на контейнерные приложения. Вы платите те же тарифы за вычислительные ресурсы, запросы и секунды виртуальных ядер независимо от того, включена ли зональная избыточность. Дополнительные сведения см. в разделе "Цены на контейнерные приложения" и выставление счетов за контейнерные приложения.
Настройка поддержки зоны доступности
Создайте среду контейнерных приложений с зональной избыточностью. Инструкции по развертыванию для портала Azure, Azure CLI и Azure PowerShell см. в статье "Создание контейнерного приложения с зональной избыточностью".
Перенос на развертывание с зональной избыточностью. Нельзя включить зональную избыточность в существующей среде контейнерных приложений. Чтобы обновить существующие среды, которые не имеют зональной избыточности, создайте новую среду с включенной зональной избыточностью в поддерживаемом регионе. Затем повторно разверните приложения-контейнеры.
Отключите избыточность в зоне. Избыточность зоны не может быть отключена после того, как она была включена во время создания среды. Если вам нужно развертывание без избыточности по зонам, необходимо создать новую среду без включения параметра избыточности, или развернуть в регионе, который не поддерживает зоны доступности.
Проверка избыточности зоны. Вы можете использовать портал Azure, Azure CLI и Azure PowerShell для проверки состояния избыточности зоны среды.
Планирование ресурсов и управление ими
Если зона доступности оказывается недоступной, платформа контейнерных приложений использует правила масштабирования, чтобы решить, когда заменить любую потерянную реплику в этой зоне. Важно правильно настроить правила масштабирования, чтобы планировщик смог принять соответствующие решения по планированию.
Чтобы правильно настроить правила масштабирования, выполните следующие принципы:
Задайте минимальное количество реплик , которые может терпеть ваше приложение. Для замены потерянных реплик может потребоваться короткий промежуток времени, так как платформа должна обнаружить, что старые реплики исчезли. Затем новые реплики должны запускаться и возвращать положительный статус проверки готовности, прежде чем они смогут получать входящие запросы. Если вы не можете терпеть какой-либо период с меньшим количеством реплик, чем указано, рассмотрите избыточное резервирование для поддержания производительности вашего приложения, даже если одна из зон станет недоступной.
Задайте запросы ресурсов и ограничения , чтобы помочь планировщику приложений контейнеров принимать оптимальные решения по размещению в зонах. Недостаточно определенные требования к ресурсам могут привести к неравномерному распределению или неудачам размещения при высокой нагрузке.
Дополнительные сведения о параметрах конфигурации см. в разделе "Настройка правил масштабирования".
Поведение, когда все зоны работоспособны
В этом разделе описывается, чего ожидать, когда ресурсы контейнерных приложений настроены для зональной избыточности и все зоны доступности находятся в рабочем состоянии.
Маршрутизация трафика между зонами: При использовании контейнерных приложений с избыточностью между зонами платформа работает в активно-активной модели, где несколько реплик одновременно обслуживают трафик. Контроллер входящего трафика (Ingress Controller) распределяет входящие запросы по всем работоспособным репликам независимо от их зоны и использует балансировку нагрузки методом циклического перебора по умолчанию. Каждая зона обрабатывает запросы независимо, и платформа не определяет приоритеты какой-либо конкретной зоны для распределения трафика. Пробы работоспособности исходят из всех зон, чтобы обеспечить точную оценку работоспособности каждой реплики с различных точек зрения.
Репликация данных между зонами: Контейнерные приложения не реплицируют данные приложений между зонами, так как они предназначены для рабочих нагрузок без отслеживания состояния. Все данные, которые хранит ваше приложение в эфемерном хранилище, включая хранилище, связанное с контейнером, и хранилище, связанное с репликой, удаляются при выключении контейнера или реплики.
Для требований к данным с состоянием подключите файловое хранилище Azure Files, настроенное для хранилища с избыточностью между зонами, или используйте другие службы Azure, такие как Azure Cosmos DB или Azure SQL Database, которые предоставляют собственные возможности репликации между зонами.
Платформа реплицирует только метаданные уровня управления, включая конфигурации приложения, правила масштабирования и секреты в зонах для обеспечения высокой доступности. Образы контейнеров извлекаются из реестра контейнеров в каждую зону по мере необходимости при создании реплик.
Поведение во время сбоя зоны
В этом разделе описывается, что ожидать, когда ресурсы контейнерных приложений настроены для избыточности зоны и возникает сбой зоны доступности.
Обнаружение и ответ: Azure автоматически обнаруживает сбои зоны. Контейнерные приложения немедленно перестают планировать новые реплики в зону, где произошел сбой, и начинают перенаправлять трафик на здоровые реплики в остальных зонах. Платформа обрабатывает все операции переключения на резервный автоматически, не требуя вашего вмешательства.
Уведомление: Корпорация Майкрософт не уведомляет вас об отключении зоны. Однако вы можете использовать службу "Работоспособность служб Azure ", чтобы понять общую работоспособность службы, включая все сбои зоны, и вы можете настроить оповещения о работоспособности служб , чтобы уведомить вас о проблемах.
Вы также можете отслеживать работоспособность приложений с помощью метрик приложений-контейнеров в Azure Monitor. Настройте оповещения при уменьшении количества реплик и уровне сбоев запросов, чтобы получать немедленные уведомления о проблемах, связанных с зонами.
Активные запросы: Текущие запросы к репликам в зоне сбоя могут прерываться или сталкиваться с истечением времени ожидания или ошибками подключения. Все выполнения заданий, выполняемые в затронутой зоне, прерваны и помечены как неудачные.
Ожидаемая потеря данных: Потеря данных не возникает на уровне платформы контейнерных приложений, так как служба предназначена для рабочих нагрузок без отслеживания состояния. Все данные, хранящиеся в эфемерном хранилище в зоне доступности, теряются при завершении реплики, а временное хранилище должно использоваться только для временных данных.
Ожидаемое время простоя: Приложения переживают минимальное или отсутствие времени простоя при сбоях зоны. Фактическое влияние зависит от настроек проверки работоспособности вашего приложения и количества реплик в здоровых зонах. Убедитесь, что клиенты следуют рекомендациям по обработке временных ошибок , чтобы свести к минимуму любые последствия.
Все задания, выполняемые в затронутой зоне, прерваны и помечены как неудачные. Если необходимо, чтобы задание было устойчивым к сбою зоны, настройте повторные попытки или настройте параллелизм, чтобы задание выполнялось несколько копий одного и того же выполнения. Дополнительные сведения см. в разделе "Расширенная конфигурация задания".
Перенаправка трафика: Пробы работоспособности контроллера входящего трафика быстро обнаруживают недоступные реплики и удаляют их из пула балансировки нагрузки. В зависимости от конфигурации проверок работоспособности приложения, этот процесс переключения на резервный узел обычно занимает около 30 секунд. Последующий входящий трафик распределяется по оставшимся здоровым репликам. Это перенаправление трафика происходит прозрачно для клиентов, которые продолжают использовать тот же URL-адрес приложения.
Если включена сопоставление сеансов , а зона исчезает, клиенты, которые ранее были перенаправлены на реплики в этой зоне, направляются на новые реплики, так как предыдущие реплики больше не доступны. Любое состояние, связанное с предыдущими репликами, теряется.
Новые экземпляры заданий не будут запущены в неисправной зоне.
Управление экземплярами: Новые экземпляры реплики могут быть созданы в зонах с надлежащим состоянием, если активируются правила автоматического масштабирования на основе повышенной нагрузки.
Восстановление зоны
Когда зона доступности восстанавливается после сбоя, контейнерные приложения автоматически повторно интегрируют зону в активную работу, не требуя вашего вмешательства. Пробы работоспособности платформы определяют, когда инфраструктура в восстановленной зоне становится доступной, и контейнерные приложения начинают планировать новые реплики в этой зоне на основе конфигурации масштабирования. Существующие реплики в здоровых зонах продолжают обслуживать трафик во время процесса реинтеграции, что помогает предотвратить нарушение обслуживания.
Контейнерные приложения постепенно перебалансируют распределение реплик по всем доступным зонам в рамках стандартных операций масштабирования. Эта автоматическая перебалансировка возникает при создании реплик из-за масштабирования событий или при замене неработоспособных реплик. Платформа не принудительно распространяет существующие здоровые реплики, что предотвращает ненужные перезапуски контейнера и поддерживает стабильность приложений во время восстановления.
Тестирование на сбои в зоне
Платформа контейнерных приложений управляет маршрутизацией трафика, отработкой отказа и восстановлением после аварии для зонально-избыточных контейнерных приложений. Эта функция полностью управляется, поэтому не требуется инициировать или проверять процессы сбоя зоны доступности.
Чтобы проверить устойчивость приложения к сбоям зоны, имитируйте нарушения уровня зоны на уровне приложения с помощью контролируемых подходов к тестированию. Остановите или удалите реплики из определенных зон, уменьшая масштаб вашего приложения, и наблюдайте за тем, как оставшиеся реплики справляются с возросшей нагрузкой. Отслеживайте ключевые метрики во время тестирования устойчивости, включая количество реплик, частоту успешных запросов, время отклика и поведение автомасштабирования. Убедитесь, что минимальное число реплик поддерживает доступность службы при удалении реплик и убедитесь, что правила масштабирования могут обрабатывать повышенную нагрузку на оставшиеся реплики. Проверьте конфигурации проб работоспособности, намеренно вызвав сбой конечных точек работоспособности, чтобы убедиться, что платформа удаляет неработоспособные экземпляры из ротации в ожидаемые временные рамки.
Устойчивость к сбоям на уровне региона
Контейнерные приложения — это служба с одним регионом. Если регион становится недоступным, среда и приложения также недоступны.
Индивидуальные решения для нескольких регионов для повышения устойчивости
Чтобы снизить риск сбоя в одном регионе, влияющего на приложение, можно развертывать среды в нескольких регионах. Следующие шаги помогают укрепить устойчивость:
Разверните приложения в средах в каждом регионе. Для каждой среды требуется собственная конфигурация виртуальной сети, а требования к подсети применяются независимо к каждому региональному развертыванию. Образы контейнеров должны быть доступны во всех регионах, что можно обеспечить с помощью реестра контейнеров Azure с включенной георепликацией.
Настройте политики балансировки нагрузки и отказоустойчивости с помощью службы, например Azure Front Door или Azure Traffic Manager.
Реплицируйте данные в разных регионах, чтобы можно было восстановить последнее состояние приложения.
Резервное копирование и восстановление
Контейнерные приложения не предоставляют встроенные возможности резервного копирования для приложений или данных. Как платформа размещения контейнеров без отслеживания состояния, контейнерные приложения ожидают, что приложения будут управлять собственными стратегиями сохраняемости и восстановления данных через внешние службы. Контейнеры приложений и локальные файловые системы являются временными, и все данные, хранящиеся локально, теряются при перезапуске или перемещении реплик.
Устойчивость во время обновлений приложений
Используйте управление редакциями для развертывания обновлений в приложении без простоя. Вы можете создавать новые версии с обновленными образами контейнеров и выполнять переключение с помощью стратегии сине-зеленого развертывания или постепенно перемещать трафик с помощью правил разделения трафика. Во время обновлений приложений платформа поддерживает минимальное количество реплик, создавая новые контейнеры перед выводом старых, что помогает предотвратить нарушения работы служб.
Дополнительные сведения см. в разделе "Обновление и развертывание изменений в приложениях контейнеров".
Устойчивость к обслуживанию служб
Контейнерные приложения выполняют автоматическое обслуживание платформы для применения обновлений системы безопасности, развертывания новых функций и повышения надежности службы. Платформа использует последовательное обновление между доменами сбоя и зонами доступности, чтобы снизить нарушение работы приложений. Во время окон обслуживания контейнеры продолжают работать без прерывания, так как обновления к базовой инфраструктуре применяются поэтапно.
Вы можете указать собственные периоды обслуживания, во время которых необходимо проводить обслуживание ваших приложений. Помните, что критические обновления могут возникать за пределами периодов обслуживания. Дополнительные сведения см. в статье о плановом обслуживании контейнерных приложений.
Соглашение об уровне обслуживания
Соглашение об уровне обслуживания (SLA) для служб Azure описывает ожидаемую доступность каждой службы и условия, которые должно соответствовать вашему решению для достижения этого ожидания доступности. Для получения дополнительной информации см. Соглашения об уровне обслуживания для онлайн-сервисов.
Соглашение об уровне обслуживания доступности для контейнерных приложений основано на правилах масштабирования, заданных в приложениях.