Архитектурные рекомендации по выбору службы контейнеров Azure

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

Обзор

Рекомендации в этой статье разделены на следующие четыре категории:

Рекомендации по архитектуре и сети

• Поддержка операционной системы (ОС)
• Сетевое адресное пространство
• Анализ потока трафика
• Планирование подсети
• Доступные IP-адреса входящего трафика
• Поддержка определяемых пользователем маршрутов и шлюзов NAT
• Интеграция с частными сетями
• Покрытие протокола
• Балансировка нагрузки
• Поиск сервисов
• Пользовательские домены и управляемая безопасность транспортного уровня (TLS)
• Взаимный TLS (mTLS)
• Расширенная сеть контейнеров для службы Azure Kubernetes (AKS)
• Основные понятия сети для конкретных служб Azure

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

• Политики сети для безопасности трафика внутри кластера
• Группы безопасности сети (НСГ)
• Интеграция Azure Key Vault
• Поддержка управляемого удостоверения
• Оценка угроз и уязвимостей с помощью Microsoft Defender для контейнеров
• Базовые показатели безопасности
• Azure Well-Architected Framework для обеспечения безопасности

Рекомендации по работе

• Обновления и исправления
• Обновления образа контейнера
• Масштабируемость вертикальной инфраструктуры
• Горизонтальное масштабирование инфраструктуры
• Масштабируемость приложений
• Наблюдаемость
• Well-Architected Framework для повышения эффективности работы

Рекомендации по надежности

• Соглашения об уровне обслуживания (SLA)
• Резервирование с использованием зон доступности
• Проверки работоспособности и самовосстановление
• Развертывания приложений без простоя
• Ограничения ресурсов
• Well-Architected Framework для обеспечения надежности

В этой статье рассматривается подмножество служб контейнеров Azure, которые предоставляют зрелый набор функций для веб-приложений и API, сети, наблюдаемости, средств разработчика и операций. К этим службам относятся AKS, AKS Automatic, Приложения контейнеров Azure и веб-приложение для контейнеров. Полный список служб контейнеров Azure см. в разделе "Службы контейнеров".

Рекомендации по архитектуре

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

Эти соображения не являются специфичными для основ Well-Architected Framework. Тем не менее, они требуют дополнительного контроля и оценки в отношении бизнес-требований при выборе службы контейнеров Azure.

Поддержка ОС

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

*Требуется отдельные планы службы приложений Azure для Windows и Linux

Рекомендации по работе с сетями

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

• Контейнерные приложения — это платформа как услуга (PaaS), которая предоставляет управляемые Azure сетевые функции, такие как обнаружение служб, внутренние управляемые домены и элементы управления виртуальной сетью.

• AKS является наиболее настраиваемым из трех служб и обеспечивает самый контроль над сетевым потоком. Например, AKS предоставляет пользовательские контроллеры входящего трафика и управление трафиком внутри кластера с помощью политик сети Kubernetes. Команды рабочей нагрузки могут воспользоваться различными сетевыми надстройками , управляемыми Azure, и устанавливать и работать с любыми надстройками из экосистемы Kubernetes.

• Веб-приложение для контейнеров — это функция службы приложений. Ее сетевая модель, особенно для интеграции частной сети, тесно соответствует архитектуре службы приложений. Эта архитектура знакома с командами рабочей нагрузки, используюющими службу приложений. Для команд без предварительного интерфейса службы приложений, которые предпочитают более обычную интеграцию виртуальной сети Azure, рекомендуется использовать контейнерные приложения.

Сеть — это базовый уровень инфраструктуры. Часто трудно вносить изменения в дизайн без повторного развертывания рабочей нагрузки, что может привести к простою. Если у рабочей нагрузки имеются определенные требования к сети, внимательно ознакомьтесь с этим разделом, прежде чем сузить выбор службы контейнеров Azure.

Сетевые адресные пространства

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

Требования AKS зависят от выбранного сетевого подключаемого модуля. Для некоторых сетевых плагинов для AKS требуются более широкие диапазоны IP-адресов. Эта информация выходит за рамки этой статьи. Дополнительные сведения см. в разделе "Сетевые концепции" для AKS.

Общие сведения о потоке трафика

Типы потока трафика, необходимые для решения, могут повлиять на структуру сети.

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

• Несколько коллокированных рабочих нагрузок

• Частный вход, общедоступный вход или оба

• Управляемый доступом поток восточно-западного трафика в кластере для Container Apps и AKS или внутри виртуальной сети для всех контейнерных сервисов Azure.

Планирование подсети

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

*Рекомендация, а не техническое ограничение

Для контейнерных приложений интеграция подсети применяется только к одной среде приложений контейнеров. Каждая среда контейнерных приложений ограничена одним IP-адресом входящего трафика, общедоступным или частным.

Каждая среда контейнерных приложений предназначена только для одной рабочей нагрузки, в которой совместно размещаются зависимые приложения. Поэтому необходимо ввести дополнительные сетевые устройства Azure для балансировки нагрузки входящего трафика, если требуется как общедоступный, так и частный входящий трафик. Примерами являются Шлюз приложений Azure и Azure Front Door. Если для нескольких рабочих нагрузок требуется разделение, необходимо создать дополнительные среды приложений контейнеров и выделить отдельную подсеть для каждой из них.

AKS предоставляет детализированное управление восточно-западным сетевым трафиком внутри кластера с помощью сетевых политик Kubernetes. Этот элемент управления потока позволяет сегментировать несколько рабочих нагрузок с разными границами безопасности сети в одном кластере.

Для веб-приложения для контейнеров нет ограничений на количество приложений, которые можно интегрировать с одной подсетью, если подсеть имеет достаточную емкость. Рекомендации по управлению доступом между веб-приложениями в одной виртуальной сети отсутствуют. Каждое веб-приложение независимо управляет доступом для восточного или северо-южного трафика из виртуальной сети или Интернета соответственно.

Доступность IP-адресов входящего трафика

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

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

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

Поддержка маршрутов, определяемых пользователем, и шлюза NAT

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

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

Интеграция с частными сетями

Для рабочих нагрузок, требующих строгих частных сетей уровня 4 как для ингресса, так и для эгресса, следует рассмотреть возможность использования Container Apps, AKS и одноарендной среды службы приложений SKU, где рабочие нагрузки развертываются в самоуправляемой виртуальной сети. Это развертывание предоставляет обычные детализированные элементы управления частной сетью.

Частная сеть с веб-приложением для контейнеров

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

• Приватные конечные точки
• Интеграция виртуальной сети

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

Покрытие протокола

Важным фактором для платформы размещения являются сетевые протоколы, поддерживаемые для входящих запросов приложений (входящего трафика). Веб-приложение для контейнеров является самым строгим вариантом и поддерживает только HTTP и HTTPS. Контейнерные приложения также допускают входящие подключения по протоколу управления передачей (TCP). AKS является наиболее гибким и поддерживает неограниченное использование протокола TCP и пользовательской диаграммы данных (UDP) на выделенных портах.

*В среде приложений-контейнеров http или HTTPS можно предоставлять на любом порту для взаимодействия внутри кластера. В этом сценарии встроенные функции HTTP контейнерных приложений, такие как общий доступ к ресурсам между источниками и сходство сеансов, не применяются.

Приложения контейнеров и веб-приложение для контейнеров поддерживают TLS 1.2 для встроенного входящего трафика HTTPS.

Балансировка нагрузки

Благодаря приложениям контейнеров и веб-приложению для контейнеров Azure полностью абстрагирует подсистемы балансировки нагрузки уровня 4 и уровня 7.

Напротив, AKS использует модель общей ответственности. В этой модели Azure управляет базовой инфраструктурой Azure, которую настраивает команда рабочей нагрузки, взаимодействуя с API Kubernetes. Для балансировки нагрузки уровня 7 в AKS можно выбрать управляемый Azure вариант, например надстройку маршрутизации управляемых AKS приложений, шлюз приложений для контейнеров или самостоятельное управление контроллером входящего трафика.

Расширенные контейнерные сетевые службы для AKS

Расширенные сетевые службы контейнеров (ACNS) оснащают AKS расширенными сетевыми возможностями, которые превосходят те, что доступны в приложениях для контейнеров или веб-приложениях для контейнеров. Эти возможности обеспечивают мощную наблюдаемость и улучшенную безопасность, предназначенную для динамических контейнерных сред.

• Наблюдаемость сети контейнеров:

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

• Безопасность сети контейнеров:

  Для кластеров, использующих сетевой интерфейс контейнеров Azure под управлением Cilium, ACNS предоставляет фильтрацию по полным доменным именам (FQDN). Вместо управления статическими политиками безопасности на основе IP-адресов можно определить политики на основе доменных имен. Этот динамический подход упрощает управление политиками, а также соответствует современным моделям безопасности нулевого доверия. Такой подход упрощает обеспечение надежной безопасности без постоянных обновлений вручную.

Дополнительные сведения см. в следующих ресурсах:

• Что такое наблюдаемость сети контейнеров?
• Что такое безопасность сети контейнеров?

Поиск сервисов

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

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

Контейнерные приложения также предоставляют общедоступные полные доменные имена (FQDN). Тем не менее, контейнерные приложения идут дальше, позволяя полному доменному имени приложения быть доступным и ограничивая трафик только в среде. Функция облегчает управление коммуникацией восток-запад и позволяет использовать такие компоненты, как Dapr.

Развертывания Kubernetes изначально не обнаруживаются как внутри, так и за пределами кластера. Чтобы обеспечить адресную доступность приложений в сети, необходимо определить и создать службы Kubernetes в соответствии с API Kubernetes.

Пользовательские домены и управляемый TLS

Как контейнерные приложения, так и веб-приложение для контейнеров предоставляют встроенные решения для пользовательских доменов и управления сертификатами.

Пользователи AKS отвечают за управление DNS, конфигурациями кластера и сертификатами TLS для своих пользовательских доменов. AKS не предоставляет управляемое TLS, но клиенты могут использовать программное обеспечение из экосистемы Kubernetes, например cert-manager, для управления сертификатами TLS.

mTLS

Другой альтернативой ограничению входящего трафика является mTLS. Этот протокол безопасности гарантирует проверку подлинности клиента и сервера в обмене данными. Для выполнения проверки подлинности обе стороны обмениваются и проверяют сертификаты перед передачей данных.

Веб-приложение для контейнеров имеет встроенную поддержку mTLS для входящих клиентских подключений. Однако приложению необходимо проверить сертификат путем доступа к заголовку HTTP, который перенаправит X-ARR-ClientCert платформа службы приложений.

Контейнерные приложения также имеют встроенную поддержку mTLS. Он перенаправит сертификат клиента в приложение в заголовке HTTP X-Forwarded-Client-Cert. Вы также можете легко включить автоматический MTLS для внутреннего взаимодействия между приложениями в одной среде.

MTLS можно реализовать в AKS с помощью сетки служб на основе Istio в качестве управляемой надстройки. Эта надстройка включает возможности mTLS для входящих клиентских подключений и взаимодействия между службами внутри кластера. Команды рабочей нагрузки также могут устанавливать и управлять другой сервисной сеткой из экосистемы Kubernetes. Эти параметры делают реализацию mTLS в Kubernetes наиболее гибкой.

Основные понятия сети для конкретной службы

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

• Сетевые возможности в контейнерных приложениях
• Сетевые функции службы приложений

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

Вопросы безопасности

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

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

Большинство служб Azure, включая контейнерные приложения, AKS и веб-приложение для контейнеров, интегрируются с ключевыми предложениями безопасности, включая Key Vault и управляемые удостоверения.

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

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

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

Безопасность плоскости управления Kubernetes

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

Безопасность на основе удостоверений

Вы несете ответственность за защиту доступа на основе удостоверений к API. Kubernetes предоставляет собственную систему управления проверкой подлинности и авторизацией. Эта система должна быть защищена с помощью элементов управления доступом.

Чтобы воспользоваться преимуществами единого уровня стекла для управления удостоверениями и доступом в Azure, рекомендуется отключить локальные учетные записи Kubernetes и вместо этого реализовать интеграцию Microsoft Entra с управлением AKS с управлением доступом на основе ролей Azure (Azure RBAC) для Kubernetes. Если вы реализуете эту рекомендацию, администраторы не должны выполнять управление удостоверениями и доступом на нескольких платформах.

У вас нет доступа к API Kubernetes, если вы используете контейнерные приложения. Корпорация Майкрософт обеспечивает безопасность для этого API.

Безопасность на основе сети

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

Существуют последствия для реализации доступа к API Kubernetes с ограниченным доступом к сети. В частности, управление можно выполнять только из частной сети. Как правило, необходимо развернуть локальные агенты для Azure DevOps или GitHub Actions. Дополнительные сведения о других ограничениях см. в документации по конкретным продуктам.

ACNS улучшает безопасность в плоскости передачи данных в AKS. Для кластеров, использующих сетевой интерфейс контейнеров Azure, управляемый Cilium, ACNS представляет безопасность сети контейнеров через фильтрацию FQDN. Вместо управления статическими политиками безопасности на основе IP-адресов можно определить динамические политики на основе полных доменных имен. Этот подход упрощает управление политиками, уменьшает административные издержки и поддерживает модель нулевого доверия, обеспечивая разрешение только трафика на доверенные домены.

Эти рекомендации не применяются к приложениям-контейнерам. Так как это PaaS, корпорация Майкрософт абстрагирует базовую инфраструктуру.

Безопасность сетевой плоскости передачи данных

Следующие сетевые функции можно использовать для контроля доступа к рабочей нагрузке, от неё и внутри неё.

Политики сети для безопасности трафика внутри кластера

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

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

Группы безопасности сети

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

Встроенные ограничения IP-адресов для входящего трафика

Контейнерные приложения и веб-приложения для контейнеров предоставляют встроенные ограничения на IP-адреса источников для входящего трафика отдельных приложений. AKS может обеспечить ту же функциональность, но требуется функциональность Kubernetes через api-ресурс службы Kubernetes, где можно задать значения для loadBalancerSourceRanges.

Безопасность на уровне приложения

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

Интеграция Key Vault

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

Интеграция Key Vault позволяет разработчикам приложений сосредоточиться на коде приложения. Все три службы контейнеров Azure, описанные в этой статье, могут автоматически синхронизировать секреты из службы Key Vault и предоставлять их приложению, как правило, как переменные среды или подключенные файлы.

Дополнительные сведения см. в следующих ресурсах:

• Управление секретами в приложениях-контейнерах
• Интеграция Key Vault с AKS
• Использование ссылок Key Vault в качестве параметров приложения в службе приложений

Поддержка управляемого удостоверения

Приложения могут использовать управляемые удостоверения для проверки подлинности в защищенных службах Microsoft Entra ID, не используя ключи или секреты. Контейнерные приложения и веб-приложение для контейнера обеспечивают встроенную поддержку управляемого удостоверения на уровне приложения Azure. Поддержка управляемых удостоверений на уровне приложения для AKS обеспечивается с помощью идентификатора рабочей нагрузки Microsoft Entra. AKS также требует управляемой идентификации, связанной с инфраструктурой, чтобы разрешить операции кластера для Kubelet, плоскости управления и различных дополнений AKS.

Дополнительные сведения см. в следующих ресурсах:

• Использование управляемого удостоверения в Azure Kubernetes Service (AKS)
• Идентификатор рабочей нагрузки с AKS
• Управляемые удостоверения в контейнерных приложениях
• Управляемые удостоверения для службы приложений

Оценка угроз и уязвимостей с помощью Defender для контейнеров

Защита от угроз, связанных с уязвимостями, также важна. Рекомендуется использовать Defender для контейнеров. Оценки уязвимостей поддерживаются в реестрах контейнеров Azure. В результате любая служба контейнеров Azure может использовать их, а не только те, которые описаны в этой статье. Однако защита среды выполнения с помощью Defender для контейнеров доступна только для AKS.

Так как AKS предоставляет собственный API Kubernetes, безопасность кластера также можно оценить с помощью средств безопасности Kubernetes из экосистемы Kubernetes.

Дополнительные сведения см. в таблице поддержки контейнеров в Microsoft Defender для Облака.

Оценки уязвимостей образа контейнера не являются проверками в режиме реального времени. Реестр контейнеров Azure сканируется через регулярные интервалы.

Базовые показатели безопасности

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

• Базовые показатели безопасности Azure для приложений-контейнеров
• Базовые показатели безопасности Azure для AKS
• Базовые показатели безопасности Azure для службы приложений

Well-Architected Framework для обеспечения безопасности

В этой статье рассматриваются основные различия между функциями службы контейнеров.

Для получения более полной информации о безопасности AKS см. рекомендации по лучшим практикам AKS.

Рекомендации по работе

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

Обновления и исправления

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

В качестве управляемой службы Kubernetes AKS предоставляет обновленные образы для узловой ОС и компонентов плоскости управления. Но команды рабочей нагрузки несут ответственность за применение обновлений к своим кластерам. Вы можете вручную активировать обновления или использовать каналы автоматического обновления кластеров, чтобы убедиться, что ваши кластеры актуальны. Для получения дополнительной информации о руководстве по операциям на втором этапе AKS см. раздел Обновление и исправление кластеров AKS.

Приложения контейнеров и веб-приложение для контейнеров — это решения PaaS. Azure отвечает за управление обновлениями и исправлениями, поэтому вы можете избежать сложности управления обновлениями AKS.

Обновления образа контейнера

Независимо от решения Azure для контейнеров, вы отвечаете за ваши контейнерные изображения. Если существуют исправления безопасности для базовых образов контейнеров, вы несете ответственность за их пересборку. Чтобы получить оповещения об этих уязвимостях, используйте Defender для контейнеров для контейнеров реестра контейнеров Azure.

Масштабируемость

Масштабирование используется для настройки емкости ресурсов в соответствии с требованиями. Он добавляет больше емкости для обеспечения производительности и удаления неиспользуемой емкости для экономии денег. При выборе решения контейнера необходимо учитывать ограничения инфраструктуры и стратегии масштабирования.

Масштабируемость вертикальной инфраструктуры

Вертикальное масштабирование относится к возможности увеличения или уменьшения существующей инфраструктуры, например вычислительных ЦП и памяти. Для разных рабочих нагрузок требуются разные объемы вычислительных ресурсов. При выборе решения контейнера Azure необходимо учитывать предложения SKU оборудования, доступные для определенной службы Azure. Эти предложения различаются и могут накладывать дополнительные ограничения.

Для AKS просмотрите размеры виртуальных машин в документации Azure и ограничения AKS для каждого региона.

В следующих статьях содержатся сведения о предложениях SKU для приложений контейнеров и службы приложений:

• Профили рабочей нагрузки в приложениях контейнеров
• Цены на службу приложений

Горизонтальное масштабирование инфраструктуры

Горизонтальное масштабирование относится к возможности увеличения или уменьшения емкости путем добавления или удаления компонентов инфраструктуры, таких как узлы виртуальной машины. При увеличении или уменьшении масштаба уровень потребления контейнерных приложений абстрагирует базовые виртуальные машины. Для оставшихся служб контейнеров Azure вы управляете стратегией горизонтального масштабирования с помощью стандартного API Resource Manager.

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

Масштабируемость приложений

Масштабирование инфраструктуры и приложений обычно активируется потреблением ресурсов, например ЦП и памятью. Некоторые решения контейнеров также могут масштабировать количество экземпляров контейнеров на основе метрик, относящихся к приложению, таких как HTTP-запросы. Например, AKS и приложения для контейнеров могут масштабировать экземпляры контейнеров на основе очередей сообщений с помощью автомасштабирования Kubernetes (KEDA), основанного на событиях, и множества других метрик с помощью масштабаторов. Эти возможности обеспечивают гибкость при выборе стратегии масштабируемости приложения. Веб-приложение для контейнеров зависит от параметров масштабируемости, которые предоставляет Azure. Веб-приложение для контейнеров не поддерживает пользовательские конфигурации масштабировщика, такие как KEDA.

AkS Automatic включает горизонтальное автомасштабирование pod, KEDA и автомасштабирование по вертикали pod по умолчанию.

Наблюдаемость

Мониторинг рабочей нагрузки

Сбор метрик для сложных или многоуровневых приложений может быть сложным. Чтобы получить метрики, можно интегрировать контейнерные рабочие нагрузки с Azure Monitor следующими способами:

• Автоматическое инструментирование: Никаких изменений кода не требуется

• Ручное инструментирование: Минимальные изменения кода, необходимые для интеграции и настройки пакета SDK и клиента

  Метод инструментирования	Контейнерные приложения	AKС	Веб-приложение для контейнеров
  Автоматическое инструментирование с помощью платформы	❌	❌	Частичная поддержка*
  Автоматическое инструментирование с помощью агента	❌	Частичная поддержка*	Недоступно
  Ручное управление инструментами	С помощью пакета SDK или OpenTelemetry	С помощью пакета SDK или OpenTelemetry	С помощью пакета SDK или OpenTelemetry

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

• Среды, языки и ресурсные поставщики, поддерживаемые для автоматического инструментирования
• Мониторинг приложений автоматического инструментирования для Kubernetes

Инструментирование в коде приложения — это ответственность разработчиков приложений, поэтому она не зависит от любого решения контейнера Azure. Используйте OpenTelemetry с Application Insights.

Журналы и метрики

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

Azure Monitor — это служба ведения журнала ключей и метрик в Azure, которая интегрируется с этими службами. Azure Monitor использует журналы ресурсов для разделения журналов из разных источников в категории и собирает метрики для предоставления аналитических сведений о производительности ресурсов. Один из способов определить, какие журналы и метрики доступны для каждой службы Azure, — проверить категории журналов ресурсов и доступные метрики для каждой службы.

Рассмотрим метрики и журналы для следующих служб:

• Контейнерные приложения абстрагируют все свои внутренние журналы Kubernetes в две категории: журналы консоли, содержащие журналы контейнеров рабочей нагрузки и системные журналы, содержащие все журналы, связанные с платформой. Для метрик контейнерные приложения интегрируются с Azure Monitor для сбора стандартных метрик и поддержки кастомных метрик через интеграцию Dapr для сложных сценариев.

• AKS предоставляет журналы, связанные с Kubernetes, и детальный контроль над тем, что регистрируется. AKS сохраняет полную совместимость с клиентскими средствами Kubernetes для потоковой передачи журналов, таких как kubectl. Для метрик AKS интегрируется с Azure Monitor для сбора метрик кластера и узлов. Вы можете собирать пользовательские метрики с помощью Prometheus и визуализировать их с помощью Grafana, но для этого действия требуется ручная настройка и настройка.

• AKS Automatic предварительно настроен с определенными средствами мониторинга. Он использует Managed Prometheus для сбора метрик и Managed Grafana для визуализации. Метрики кластера и приложений автоматически собираются и могут быть визуализированы. AKS Automatic также интегрируется с Azure Monitor для сбора журналов и метрик.

• Веб-приложение для контейнеров предоставляет несколько категорий журналов ресурсов, так как ее платформа (служба приложений) не является исключительно для рабочих нагрузок контейнеров. Для операций, относящихся к контейнеру, которые управляют внутренней платформой Docker, она предоставляет категорию AppServicePlatformLogs журнала. Другая важная категория — AppServiceEnvironmentPlatformLogsэто журнал событий, таких как масштабирование и изменение конфигурации. Метрики собираются с помощью Azure Monitor, что позволяет отслеживать производительность приложений и использование ресурсов.

Well-Architected Framework для повышения эффективности работы

В этой статье рассматриваются основные различия между функциями служб контейнеров. Ознакомьтесь с полным руководством по операционному превосходству для следующих служб:

• AKS
• Веб-приложение для контейнеров

Надёжность

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

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

Соглашения об уровне обслуживания

Надежность обычно измеряется метриками на основе бизнеса , такими как соглашения об уровне обслуживания или метрики восстановления, такие как цели времени восстановления.

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

Для соглашений об уровне обслуживания и подробных сведениях скачайте последний документ соглашения об уровне обслуживания для веб-служб Майкрософт. Чтобы узнать, как интерпретировать соглашения об уровне обслуживания и использовать их в качестве инженерных входных данных, ознакомьтесь с соглашением об уровне обслуживания.

Бесплатные уровни и платные уровни

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

Дополнительные факторы для AKS

AKS имеет разные соглашения об уровне обслуживания для различных компонентов и конфигураций:

• Control Plane: Сервер API Kubernetes имеет отдельное соглашение об уровне обслуживания (SLA).

• Плоскость данных: Группы узлов используют основные SLA для SKU виртуальных машин.

• Зоны доступности: Существуют разные соглашения об уровне обслуживания для двух плоскостей в зависимости от того, включены ли зоны доступности в кластере AKS и работают ли несколько экземпляров, распределённых между зонами доступности.

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

Резервирование с зонами доступности

Зоны доступности — это отдельные центры обработки данных с независимой электроэнергией и охлаждением в одном регионе. Результирующая избыточность увеличивает допустимость сбоев, не требуя реализации многорегионных архитектур.

Azure имеет зоны доступности в каждой стране или регионе, в котором она работает в регионе центра обработки данных. Чтобы разрешить нескольким экземплярам контейнеров пересекать зоны доступности, обязательно выберите SKU, уровни служб и регионы, обеспечивающие поддержку зон доступности.

Например, приложение или инфраструктура, настроенная для запуска одного экземпляра, становится недоступной, если проблема возникает в зоне доступности, в которой размещено оборудование. Чтобы в полной мере воспользоваться поддержкой зон доступности, разверните рабочие нагрузки с как минимум тремя экземплярами контейнеров, распределенными по зонам.

Проверки работоспособности и самовосстановление

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

Чтобы лучше понять типы проб работоспособности Kubernetes, рассмотрите следующие встроенные варианты:

• Запуск: Проверяет, успешно ли запускается приложение

• Готовность: Проверяет, готов ли приложение обрабатывать входящие запросы

• Проверка работоспособности: Проверяет, работает ли приложение и отвечает на запросы.

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

Большинство приложений поддерживают проверки работоспособности через протокол HTTP или HTTPS. Однако для выполнения этих проверок для некоторых приложений могут потребоваться другие протоколы, такие как TCP или gRPC. Помните об этом при разработке системы проверки работоспособности.

Проверки работоспособности легче всего реализовать в веб-приложении для контейнеров. Обратите внимание на следующие факторы:

• Стартовые пробники встроены и не могут быть изменены. Он отправляет HTTP-запрос на начальный порт контейнера. Любой ответ от вашего приложения считается успешным началом.

• Он не поддерживает пробы готовности. Если проба запуска выполнена успешно, экземпляр контейнера добавляется в пул здоровых экземпляров.

• Он отправляет проверку работоспособности с интервалом в одну минуту. Невозможно изменить интервал.

• Минимальное пороговое значение, которое можно задать для неработоспособного экземпляра, который будет удален из внутреннего механизма балансировки нагрузки, составляет две минуты. Неработоспособный экземпляр получает трафик в течение как минимум двух минут после неудачи проверки работоспособности. Значение по умолчанию для этого параметра составляет 10 минут.

Кроме того, приложения контейнеров и AKS являются гораздо более гибкими и предоставляют аналогичные варианты. С точки зрения конкретных различий AKS предоставляет следующие параметры для выполнения проверок работоспособности, которые недоступны в контейнерных приложениях:

• Поддержка gRPC
• Именованные порты
• Команды Exec

Автоматическое исцеление

Определение неисправного экземпляра контейнера и перекрытие трафика к нему является только началом. Следующий шаг — реализовать автоматическое исцеление. Автоматическое восстановление — это процесс перезапуска приложения, чтобы попытаться восстановиться после неработоспособного состояния. Рассмотрим, как сравниваются следующие службы контейнеров:

• В веб-приложении для контейнеров нет возможности перезапустить экземпляр контейнера сразу после сбоя проверки работоспособности . Если экземпляр продолжает давать сбой в течение одного часа, новый экземпляр заменяет его. Автоматическое восстановление отслеживает и перезапускает экземпляры. Это не связано напрямую с проверками состояния здоровья. Автоматическое восстановление использует различные метрики приложения, такие как ограничения памяти, длительность HTTP-запроса и коды состояния.

• Контейнерные приложения и AKS автоматически пытаются перезапустить экземпляр контейнера, если проверка на работоспособность достигает заданного порога отказа.

Развертывания приложений без простоя

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

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

Ограничения ресурсов

Еще одним важным компонентом надежной общей среды является контроль использования ресурсов, таких как ЦП или память контейнеров. Необходимо избежать сценариев, в которых одно приложение использует все ресурсы и оставляет другие приложения в плохом состоянии.

• Веб-приложение для контейнеров: В одном плане службы приложений можно разместить несколько приложений (контейнеров). Например, можно выделить план с двумя ядрами ЦП и 4 гибибайтами ОЗУ, в которых можно запускать несколько веб-приложений в контейнерах. Однако вы не можете ограничить один из приложений определенным объемом ЦП или памяти. Все они конкурируют за одни и те же ресурсы плана службы приложений. Если вы хотите изолировать ресурсы приложения, необходимо создать дополнительные планы службы приложений.

• Приложения-контейнеры: Вы можете задать ограничения ЦП и памяти для каждого приложения в вашей среде. Однако вы ограничены набором разрешенных сочетаний ЦП и памяти. Например, нельзя настроить один виртуальный ЦП и 1 ГиБ памяти, но можно настроить один виртуальный ЦП и 2 ГиБ памяти. Среда контейнерных приложений служит аналогичной цели пространству имен Кубернетес.

• AKS: Вы можете выбрать любое сочетание виртуальных ЦП и памяти , если на узлах есть оборудование для его поддержки. Вы также можете ограничить ресурсы на уровне пространства имен , если вы хотите сегментировать кластер таким образом.

Well-Architected Framework для обеспечения надежности

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

• проверка платформыWell-Architected для AKS
• Надежность в приложениях-контейнерах
• Служба приложений и надежность

Заключение

Хорошо спроектированные решения создают основу для успешных рабочих нагрузок. Решения по архитектуре могут изменяться по мере роста рабочих нагрузок и продвижения команд в их облачных путешествиях. Некоторые варианты, особенно связанные с сетью, трудно отменить без значительного простоя или повторного развертывания.

При сравнении служб контейнеров Azure возникает четкая тема. AKS предоставляет самую базовую инфраструктуру, которая обеспечивает максимальное управление и настройку. AKS балансирует контроль и простоту, автоматизируя многие операционные задачи.

Объем операционных накладных расходов и сложностей значительно варьируется для рабочих нагрузок AKS. Некоторые команды значительно сокращают нагрузку с помощью надстроек, управляемых Корпорацией Майкрософт, расширений и функций автоматического обновления. Другие команды предпочитают полный контроль кластера, чтобы воспользоваться полной расширяемостью Kubernetes и экосистемой CNCF. Например, в то время как Корпорация Майкрософт предоставляет Flux в качестве управляемого расширения GitOps, многие команды выбирают настройку и работу ArgoCD самостоятельно.

Команды рабочей нагрузки, которые не требуют приложений CNCF, имеют меньше опыта работы или предпочитают сосредоточиться на функциях приложений может предпочесть предложение PaaS. Мы рекомендуем им сначала рассмотреть контейнерные приложения.

Контейнерные приложения и веб-приложение для контейнеров — это предложения PaaS, обеспечивающие аналогичные уровни управляемой корпорацией Майкрософт инфраструктуры. Однако контейнерные приложения ближе к Kubernetes и предоставляют дополнительные облачные возможности для обнаружения служб, автомасштабирования на основе событий и интеграции Dapr . Команды, которые не нуждаются в этих функциях и знакомы с сетями и моделями развертывания службы приложений, могут предпочесть веб-приложение для контейнеров.

Обобщение может помочь сузить список служб контейнеров Azure для рассмотрения. Однако вы также должны проверить выбор, проверив отдельные требования подробно и сопоставив их с функциями конкретной службы.

Участники

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

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

• Андре Деуэс | Старший инженер клиента
• Xuhong Liu | Старший инженер службы
• Маркос Мартинес | Старший инженер службы
• Джули Нг | Старший инженер

Другие участники:

• Мартин Gjoшевски | Старший инженер клиента
• Don High | Главный инженер клиента
• Nelly Kiboi | Инженер службы
• Фейсал Мустафа | Старший инженер клиента
• Уолтер Майерс | Главный менеджер по проектированию клиентов
• Соналика Рой | Старший инженер клиента
• Паоло Сальватори | Главный инженер клиента
• Виктор Сантана | Главный инженер клиента

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

Дальнейшие действия

• Документация по AKS
• Документация по службе приложений
• Документация по контейнерным приложениям

Связанные ресурсы

• Развертывание микрослужб с помощью контейнерных приложений
• Планирование проектирования и операций