Изменить

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

Запуск контейнеров Windows в AKS

Шлюз приложений Azure
Реестр контейнеров Azure
Брандмауэр Azure
Служба Azure Kubernetes (AKS)
Управление доступом на основе ролей в Azure

Эта статья предназначена для расширения базовой архитектуры AKS, которая обеспечивает тщательную проверку рекомендуемых конфигураций для развертывания кластера AKS в рабочей среде. В этой статье рассматриваются рекомендации по развертыванию контейнеров Windows в AKS. Таким образом, в этой статье рассматриваются эти конфигурации, относящиеся к развертыванию Windows в AKS, и вы должны вернуться к документации по базовым планам AKS для конфигураций, уже описанных там.

Ознакомьтесь с проектом GitHub базового плана AKS Windows, чтобы просмотреть эталонную реализацию, связанную с этой эталонной архитектурой, включая пример кода развертывания.

Проектирование сети

Сетевая конструкция, используемая в этой архитектуре, основана на проектировании , используемом в базовой архитектуре AKS, и поэтому использует все основные компоненты, кроме следующих изменений.

  • Контроллеры домена Active Directory добавлены для поддержки рабочих нагрузок на основе Windows.
  • Решение для входящего трафика в этой архитектуре использует Azure Front Door (AFD) и прокси приложения Microsoft Entra, а не шлюз приложение Azure, который используется в базовой архитектуре AKS.

Примечание.

Перенос рабочих нагрузок Windows в AKS обычно не включает основные усилия по рефакторингу, а такие рабочие нагрузки могут использовать функции, которые были относительно легко реализовать локально, но представляют проблему в Azure. Одним из примеров будет приложение, использующее проверку подлинности gMSA и Kerberos. Это распространенный вариант использования, и, как правило, эта архитектура ведет к использованию с компонентами, которые соответствуют потребностям этих рабочих нагрузок. В частности, использование прокси приложения, интерфейсом AFD в рамках пути входящего трафика. Если рабочая нагрузка не нуждается в этой поддержке, вы можете выполнить те же инструкции , что и в базовом плане AKS для входящего трафика.

Дизайн входящего трафика

Компоненты:

  • Azure Front Door с WAF: AFD — это общедоступная точка входящего трафика для приложений, размещенных в кластере AKS. AFD Premium используется в этой структуре, так как она позволяет использовать Приватный канал, которая блокирует внутренний трафик приложения к частной сети, обеспечивая самый высокий уровень безопасности. Брандмауэр веб-приложений (WAF) защищает от распространенных эксплойтов и уязвимостей веб-приложений.
  • Прокси приложения Microsoft Entra: этот компонент служит второй точкой входящего трафика перед внутренней подсистемой балансировки нагрузки, управляемой AKS. Он включает идентификатор Microsoft Entra для предварительной проверки подлинности пользователей и использует политику условного доступа для предотвращения несанкционированного диапазона IP-адресов (прокси приложения видит исходный IP-адрес клиента, который он сравнивает с политикой условного доступа) и пользователей от доступа к сайту. Это единственный способ маршрутизации запросов проверки подлинности Kerberos при использовании службы Azure, поддерживающей WAF. Подробное описание предоставления единого входа в приложения, защищенные application Proxy, см. в статье Kerberos Constrained Delegation for single sign-on (SSO) для приложений с помощью Application Proxy
  • Внутренняя подсистема балансировки нагрузки: управляется AKS. Эта подсистема балансировки нагрузки предоставляет контроллер входящего трафика через частный статический IP-адрес. Он служит одной точкой контакта, которая получает входящий HTTP-запрос.
  • В этой архитектуре не используются контроллеры входящего трафика в кластере (например, Nginx).

Чтобы реализовать эту структуру, AFD необходимо настроить для использования URL-адреса прокси приложения, созданного при публикации приложения в этой службе. Эта конфигурация направляет входящий трафик к прокси-серверу и позволяет выполнять предварительную проверку подлинности.

Примечание.

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

Топология сети

На приведенной ниже схеме показана схема сети с концентраторами, используемая в этой архитектуре.

Схема, демонстрирующая структуру сетевой топологии для контейнеров Windows в эталонной архитектуре AKSСкачайте файл Visio для этой архитектуры.

Топология пула узлов

Эта архитектура использует три пула узлов: пул системных узлов под управлением Linux, пул узлов пользователей под управлением Linux и пул узлов пользователей под управлением Windows. Пулы узлов пользователей Windows и Linux используются для рабочих нагрузок, а пул системных узлов используется для всех конфигураций на уровне системы, таких как CoreDNS.

Поток трафика входящего трафика

Схема, показывающая поток трафика входящего трафика для контейнеров Windows в эталонной архитектуре AKS

  1. Клиент отправляет HTTPS-запрос на доменное имя: bicycle.contoso.com Это имя связано с записью DNS A для общедоступного IP-адреса Azure Front Door. Этот трафик шифруется, чтобы убедиться, что трафик между клиентским браузером и шлюзом не может быть проверен или изменен.
  2. Azure Front Door имеет интегрированный брандмауэр веб-приложения (WAF) и согласовывает подтверждение TLS для bicycle.contoso.com, позволяя только безопасные шифры. Шлюз Azure Front Door — это точка завершения TLS, так как она требуется для обработки правил проверки WAF и выполнения правил маршрутизации, перенаправляющих трафик в настроенную серверную часть. Сертификат TLS хранится в Azure Key Vault.
  3. AFD направляет запрос пользователя на прокси-сервер приложение Azure. AFD настроен для разрешения только трафика HTTPS. Пользователь должен пройти проверку подлинности с помощью идентификатора Microsoft Entra, если включена предварительная проверка подлинности.
  4. Прокси приложения направляет пользователя в контейнер серверного приложения через подсистему балансировки нагрузки AKS.

Примечание.

Вы можете применить сквозной трафик TLS на каждом прыжке в потоке, но рассмотрите возможность измерения производительности, задержки и оперативного влияния при принятии решения о защите трафика pod-to-pod. Для большинства кластеров с одним клиентом с правильным уровнем управления RBAC и зрелой практикой жизненного цикла разработки программного обеспечения достаточно принудительное шифрование до контроллера входящего трафика и защиты серверной части с помощью Брандмауэр веб-приложений (WAF). Эта конфигурация сведет к минимуму затраты на управление рабочими нагрузками и влияние на производительность сети. Требования к рабочей нагрузке и соответствию требованиям определяют, где выполняется завершение TLS.

Исходящий поток трафика

Все рекомендации, приведенные в статье "Базовые показатели AKS", применяются здесь с дополнительной рекомендацией для рабочих нагрузок Windows. Чтобы воспользоваться автоматическими обновлениями Windows Server, необходимо не блокировать необходимые полные доменные имена в наборе правил Брандмауэр Azure.

Примечание.

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

Планирование IP-адресов

В отличие от кластеров AKS с пулами узлов Linux, кластеры AKS с пулами узлов Windows требуют Azure CNI. Использование Azure CNI позволяет назначить ip-адрес pod из виртуальная сеть Azure. Затем модуль pod может взаимодействовать через Azure виртуальная сеть так же, как и любое другое устройство. Он может подключаться к другим модулям pod, к одноранговым сетям или локальным сетям посредством протоколов ExpressRoute или VPN или к другим службам Azure с помощью приватного канала.

Все рекомендации относительно планирования IP-адресов, предоставленных в статье о базовой архитектуре AKS, применяются здесь, с одной дополнительной рекомендацией: рассмотрите возможность подготовки выделенной подсети для контроллеров домена. В отношении пула узлов Windows рекомендуется разделять его от других пулов узлов логически с помощью отдельных подсетей.

Обновление пула узлов

Процесс обновления узлов Windows не отличается от рекомендаций, предоставленных в документации по обновлению образа узла Служба Azure Kubernetes (AKS), но следует учитывать следующие различия расписания, чтобы спланировать периодичность обновления.

Корпорация Майкрософт предоставляет новые образы Windows Server, включая актуальные исправления, для узлов ежемесячно и не выполняет никаких автоматических исправлений или обновлений. Таким образом, необходимо вручную или программно обновить узлы в соответствии с этим расписанием. Использование GitHub Actions для создания задания cron, которое выполняется по расписанию, позволяет программно планировать ежемесячные обновления. Инструкции, приведенные в документации, связанной выше, отражают процессы узлов Linux, но вы можете обновить yamL-файл, чтобы задать расписание cron для выполнения ежемесячно, а не двунаправленно. Кроме того, необходимо изменить параметр "запуски" в YAML-файле на "windows-latest", чтобы убедиться, что вы обновляетесь до последнего образа Windows Server.

Дополнительные рекомендации см. в руководстве оператора AKS по исправлению и обновлению рабочего узла.

Примечание.

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

Рекомендации по вычислениям

Для больших размеров образов, связанных с образами windows server, требуется развертывание дисков ОС соответствующего размера в пуле узлов. Использование временных дисков ОС по-прежнему рекомендуется для всех узлов, включая Windows, поэтому убедитесь, что требования к размеру должны соответствовать при планировании развертывания.

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

Контейнеры Windows не могут быть присоединены к домену, поэтому если требуется проверка подлинности и авторизация Active Directory, можно использовать управляемые группы учетные записи служб (gMSA). Чтобы использовать gMSA, необходимо включить профиль gMSA в кластере AKS под управлением узлов Windows. Ознакомьтесь с документацией по gMSA AKS для полной проверки архитектуры и руководства по включению профиля.

Масштабирование узлов и модулей pod

Руководство по автомасштабированию кластера не изменилось для контейнеров Windows. Дополнительные сведения см. в документации по автомасштабированию кластера.

В документации по базовому кластеру описываются подходы к масштабированию модулей pod вручную и автомасштабирования. Оба подхода доступны для кластеров под управлением контейнеров Windows, и рекомендации , приведенные в этой статье, как правило, применяются здесь.

Что отличается от контейнеров Linux и Windows в отношении операций масштабирования pod, это размер образа в большинстве случаев. Более крупные размеры образов контейнеров Windows, скорее всего, увеличат время завершения операций масштабирования и, следовательно, следует учитывать некоторые рекомендации по масштабированию. Этот сценарий распространен в устаревших приложениях .NET из-за размера среды выполнения .NET. Чтобы уменьшить задержки при извлечении изображения вниз во время масштабирования, можно использовать daemonSet для извлечения образа из ACR для кэширования на каждом узле Windows и, следовательно, спинирования модулей pod с предварительно загруженным изображением. С этого момента модули pod должны выполняться только в процессах конфигурации приложения, определенных для рабочей нагрузки, прежде чем переходить в интернет.

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

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

Наблюдение

Контейнеры под управлением Windows можно отслеживать с помощью Azure Monitor и Аналитики контейнеров, например контейнеров Linux. Таким образом, рекомендации, приведенные в статье "Базовые показатели AKS", применяются здесь, а также для большей части. Однако мониторинг Container Insights для кластера Windows Server имеет следующие ограничения:

  • Windows не имеет метрики RSS памяти. В результате он недоступен для узлов и контейнеров Windows. Доступна метрика рабочего набора
  • Сведения о емкости хранилища диска недоступны для узлов Windows.

Вы также можете комплиментировать Аналитику контейнеров с помощью правил сбора данных для сбора событий и счетчиков производительности из систем Windows Server.

Примечание.

Аналитика контейнеров для операционной системы Windows Server 2022 доступна в общедоступной предварительной версии.

Управление политикой

Все рекомендации по политике, найденные в базовой статье AKS, применяются для рабочих нагрузок Windows. Дополнительные политики windows, найденные в встроенных определениях Политика Azure для Служба Azure Kubernetes справочной статьи:

Начальная загрузка кластера

Как и в руководстве по начальной загрузке кластера, приведенному в статье "Базовые показатели AKS", операторы кластера также должны учитывать подход к загрузке рабочих нагрузок на основе Windows. Те же рекомендации, приведенные в статье "Базовые показатели AKS", также применяются здесь.

Управление затратами

Все рекомендации по оптимизации затрат, приведенные в статье "Базовые показатели AKS", применяются для рабочих нагрузок Windows. Другие рекомендации по затратам, которые следует учитывать, являются следующими:

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основные авторы:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

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