Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Приложения контейнеров Azure выполняются в контексте среды с собственной виртуальной сетью. Эта VNet создает безопасную границу вокруг вашей среды Azure Container Apps.
Конфигурация входящего трафика в приложениях контейнеров Azure определяет, как внешний сетевой трафик достигает ваших приложений. Настройка входящего трафика позволяет управлять маршрутизацией трафика, повысить производительность приложения и реализовать расширенные стратегии развертывания. В этой статье описаны параметры конфигурации входящего трафика, доступные в приложениях контейнеров Azure, и вы можете выбрать правильные параметры для рабочих нагрузок.
Среда приложений контейнеров Azure включает масштабируемый прокси-сервер входящего трафика, отвечающий за следующие функции:
Завершение протокола TLS, расшифровывающее трафик TLS при входе в среду. Эта операция перемещает работу расшифровки из приложений-контейнеров, уменьшая потребление ресурсов и повышая их производительность.
Балансировка нагрузки и разделение трафика между активными редакциями приложения-контейнера. Управление тем, где вы направляете входящий трафик, позволяет реализовать такие шаблоны, как сине-зеленое развертывание и проводить тестирование A/B.
Связь сеансов, которая помогает создавать приложения с сохранением состояния, для которых требуется постоянное подключение к одной и той же реплике контейнерного приложения.
На следующей диаграмме показана примерная среда, где входящий прокси-сервер направляет трафик к двум контейнерным приложениям.
По умолчанию приложения контейнеров Azure создают среду приложения-контейнера с режимом входящего трафика по умолчанию. Если вашему приложению требуется работать на высоких масштабах, можно задать режим работы приложений как премиальный.
Режим входящего трафика по умолчанию
В режиме входящего трафика по умолчанию среда "Приложения контейнеров" имеет два экземпляра прокси-сервера входящего трафика. При необходимости контейнерные приложения создают больше экземпляров, до максимума в 10. Каждому экземпляру выделяется до 1 ядра виртуального процессора и 2 ГБ памяти.
В режиме входящего трафика по умолчанию выставление счетов не применяется для масштабирования прокси-сервера входящего трафика или для ядер виртуального ЦП и выделенной памяти.
Премиум режим доступа
Режим входящего трафика по умолчанию может стать узким местом в высокомасштабируемых средах. В качестве альтернативы, премиальный режим входа включает расширенные функции, чтобы обеспечить соответствие требованиям трафика.
К этим функциям относятся:
Поддержка профиля рабочей нагрузки: экземпляры прокси-сервера Ingress выполняются в выбранном профиле рабочей нагрузки . Вы контролируете количество ядер виртуальных ЦП и ресурсов памяти, доступных прокси-серверу.
Настраиваемые правила диапазона масштабирования: правила диапазона масштабирования прокси можно настроить, чтобы убедиться, что у вас есть столько экземпляров, сколько требуется приложению.
Дополнительные параметры: Можно настроить такие дополнительные параметры, как таймауты простоя для экземпляров прокси-сервера входящего трафика.
Чтобы решить, использовать ли стандартный или премиальный режим входящего трафика, вы оцениваете ресурсы, потребляемые экземпляром прокси-сервера, с учётом обслуживаемых запросов. Начните с просмотра ядер виртуальных ЦП и ресурсов памяти, потребляемых экземпляром прокси-сервера. Если ваша среда поддерживает максимальное число прокси-серверов входящего трафика (по умолчанию 10) в течение любого длительного периода, попробуйте перейти на режим входящего трафика класса Premium. Дополнительные сведения см. в разделе метрик. Сведения о настройке режима входящего трафика уровня "Премиум" см. в разделе "Использование входящего трафика класса "Премиум" в приложениях контейнеров Azure.
Профиль рабочей нагрузки
Вы можете выбрать профиль рабочей нагрузки, чтобы предоставить выделенные узлы для экземпляров входящего прокси, которые масштабируются в соответствии с вашими потребностями. Рекомендуется использовать типы профилей рабочих нагрузок D4-D32. Каждый экземпляр входящего прокси-сервера получает 1 ядро vCPU. Дополнительные сведения см. в разделе "Профили рабочей нагрузки" в приложениях контейнеров Azure.
Профиль рабочей нагрузки:
- Не должно быть профилем нагрузки на потребление.
- Нельзя предоставлять общий доступ к приложениям или заданиям контейнеров.
- Не следует удалять, если используется для прокси-сервера входящего трафика.
За выполнение прокси-сервера входящего трафика в рамках профиля рабочей нагрузки взимается плата по ставке для этого профиля. Дополнительные сведения см. в разделе о выставлении счетов.
Можно также настроить количество узлов профиля рабочей нагрузки. Профиль рабочей нагрузки — это масштабируемый пул узлов. Каждый узел содержит несколько экземпляров прокси-сервера входящего трафика. Количество узлов масштабируется в зависимости от загрузки виртуальных процессоров и памяти. Минимальное количество экземпляров узлов — два.
Масштабирование
Входящий прокси-сервер масштабируется независимо от масштабирования контейнерного приложения.
Когда прокси-сервер входящего трафика достигает высокого уровня использования виртуального ЦП или памяти, контейнерные приложения создают больше экземпляров прокси-сервера входящего трафика. При снижении загруженности удаляются дополнительные входящие прокси-серверы.
Минимальные и максимальные инстансы прокси-сервера для входящего трафика определяются следующим образом:
Минимальное значение. Существует не менее двух экземпляров узлов.
Максимальное значение: количество экземпляров узлов, умноженное на число ядер виртуальных ЦП. Например, если у вас есть максимум 50 экземпляров узлов и 4 ядра виртуальных ЦП, у вас максимум 200 экземпляров прокси-сервера входящего трафика.
Экземпляры прокси-сервера входящего трафика распределяются между доступными узлами профиля рабочей нагрузки.
Расширенные настройки входа
С включенным режимом входящего трафика класса "Премиум" можно также настроить следующие параметры:
| Настройки | Описание | Минимум | Максимум | По умолчанию |
|---|---|---|---|---|
| Льготный период прекращения | Время (в секундах), в течение которого приложение-контейнер должно завершить обработку запросов, прежде чем они будут отменены во время завершения работы. | 0 | 3600 | 500 |
| Тайм-аут ожидания ответа запроса | Время простоя ожидания запроса в минутах. | 4 | 30 | 4 |
| Количество заголовков запросов | Увеличьте этот параметр, если у вас есть клиенты, отправляющие большое количество заголовков запросов. | 1 | Не применимо | 100 |
Эти параметры следует увеличить только по мере необходимости, так как повышение их может привести к тому, что экземпляры прокси-сервера входящего трафика используют больше ресурсов в течение более длительного периода времени, что становится более уязвимым к исчерпанию ресурсов и атакам типа "отказ в обслуживании".
Настройка входного трафика
После создания среды можно настроить входные настройки.
Перейдите к вашей среде на портале Azure.
Выберите Сети.
Выберите настройки входа.
Настройте параметры входящего трафика следующим образом.
Настройки Ценность Режим входа Выберите "По умолчанию " или "Премиум". Размер профиля рабочей нагрузки Выберите размер от D4 до D32. Минимальные инстанции узлов Введите минимальные экземпляры узлов профиля рабочей нагрузки. Максимальное количество экземпляров узлов Введите экземпляры узлов профиля рабочей нагрузки максимума. Льготный период прекращения Введите льготный период окончания в минутах. Тайм-аут ожидания ответа запроса Введите время ожидания для неактивных запросов в минутах. Количество заголовков запросов Введите число заголовков запроса. Нажмите кнопку "Применить".
Маршрутизация на основе правил
При маршрутизации на основе правил вы создаете полное доменное имя (FQDN) в среде приложений контейнеров. Затем вы используете правила для маршрутизации запросов в это полное доменное имя в разные приложения-контейнеры в зависимости от пути каждого запроса. Это дает следующие преимущества.
Изоляция: путем маршрутизации разных путей к разным приложениям-контейнерам можно развертывать и обновлять отдельные компоненты, не затрагивая все приложение.
Масштабируемость. С помощью маршрутизации на основе правил можно масштабировать отдельные приложения контейнеров независимо на основе трафика, получаемого каждым приложением контейнера.
Пользовательские правила маршрутизации. Например, можно перенаправить пользователей на разные версии приложения или реализовать тестирование A/B.
Безопасность. Вы можете реализовать меры безопасности, адаптированные для каждого приложения контейнера. Это помогает уменьшить область атаки приложения.
Сведения о настройке маршрутизации на основе правил в среде приложений контейнеров см. в статье "Использование маршрутизации на основе правил".
Шифрование типа «точка-точка» в среде "Приложения контейнеров Azure"
Приложения контейнеров Azure поддерживают одноранговое шифрование TLS внутри среды. Включение этой функции шифрует весь сетевой трафик в среде с частным сертификатом, допустимым в области среды приложений контейнеров Azure. Приложения контейнеров Azure автоматически управляют этими сертификатами.
Замечание
По умолчанию шифрование однорангового подключения отключено. Включение однорангового шифрования для приложений может увеличить задержку отклика и уменьшить максимальную пропускную способность в сценариях высокой нагрузки.
В следующем примере показана среда с включенным одноранговым шифрованием.
1 Входящий трафик TLS завершается на прокси-сервере входящего трафика на границе среды.
2 Трафик в и из входного прокси-сервера в данной среде шифруется с помощью закрытого сертификата и расшифровывается получателем.
3 Вызовы, сделанные из приложения A в полное доменное имя приложения B, сначала отправляются на пограничный прокси-сервер входящего трафика и шифруются TLS.
4 Вызова, сделанные из приложения A в приложение B с использованием имени приложения B, отправляются непосредственно в приложение B и шифруются TLS. Вызовы между приложениями и компонентами Java обрабатываются так же, как связь между приложениями, и шифруются с использованием TLS.
Приложения в среде контейнерных приложений автоматически проходят проверку подлинности. Однако среда выполнения контейнерных приложений не поддерживает авторизацию для управления доступом между приложениями с помощью встроенного однорангового шифрования.
Когда приложения взаимодействуют с клиентом за пределами среды, поддерживается двусторонняя проверка подлинности с помощью MTLS. Дополнительные сведения см. в статье о настройке сертификатов клиента.
Вы можете включить одноранговую шифрование с помощью следующих команд.
При создании:
az containerapp env create \
--name <ENVIRONMENT_NAME> \
--resource-group <RESOURCE_GROUP> \
--location <LOCATION> \
--enable-peer-to-peer-encryption
Для существующего приложения-контейнера:
az containerapp env update \
--name <ENVIRONMENT_NAME> \
--resource-group <RESOURCE_GROUP> \
--enable-peer-to-peer-encryption