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

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

  • Статья

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

Примечание.

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

Обзор

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

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

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

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

  • Обеспечение безопасности для трафика внутри кластера с помощью политик сети
  • Группы безопасности сети
  • Интеграция с Azure Key Vault
  • Поддержка управляемых удостоверений
  • Оценка угроз и уязвимостей с помощью Defender для контейнеров
  • Базовые показатели безопасности
  • Хорошо разработанная платформа Azure для обеспечения безопасности

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

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

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

  • Соглашения об уровнях обслуживания
  • Избыточность через зоны доступности
  • Проверки работоспособности и самовосстановление
  • Развертывания приложений без простоя
  • Ограничения ресурсов
  • Хорошо разработанная платформа для надежности

Обратите внимание, что в этой статье рассматривается подмножество служб контейнеров Azure, которые предлагают зрелый набор функций для веб-приложений и API, сети, наблюдаемости, средств разработчика и операций: Служба Azure Kubernetes (AKS), приложений контейнеров Azure и веб-приложения для контейнеров. Полный список всех служб контейнеров Azure см . на странице категории продуктов служб контейнеров.

Примечание.

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

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

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

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

Поддержка операционных систем

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

Контейнеры приложений AKS Веб-приложение для контейнеров
Поддержка Linux ✅ ✅ ✅
Поддержка Windows ❌ ✅ ✅
Поддержка смешанной ОС ❌ ✅ ❌*

*Поддержка смешанной ОС для веб-приложения для контейнеров требует отдельных планов службы приложение Azure для Windows и Linux.

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

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

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

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

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

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

Контейнеры приложений AKS Веб-приложение для контейнеров
Выделенные подсети План потребления: необязательный
Выделенный план: обязательный		 Обязательное поле Необязательно
Требования к IP-адресу План потребления: см . среду только для потребления.
Выделенный план. См . среду профилей рабочей нагрузки.		 См. сведения о виртуальных сетях Azure для AKS. См. Служба приложений требования к подсети.

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

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

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

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

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

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

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

Контейнеры приложений AKS Веб-приложение для контейнеров
Поддержка совместно размещаемых рабочих нагрузок в подсети* ❌* ✅ Н/Д*

*Это описывает рекомендации, а не технические ограничения.

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

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

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

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

Примечание.

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

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

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

Контейнеры приложений AKS Веб-приложение для контейнеров
Количество IP-адресов входящего трафика Единица Много Среда службы приложений: один
Нет Среда службы приложений: многие

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

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

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

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

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

Контейнеры приложений AKS Веб-приложение для контейнеров
Поддержка UDR План только для потребления: ❌
План профиля рабочей нагрузки: ✅		 ✅ ✅
Поддержка шлюза NAT План только для потребления: ❌
План профиля рабочей нагрузки: ✅		 ✅ ✅

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

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

Контейнеры приложений AKS Веб-приложение для контейнеров
Частный вход в виртуальную сеть ✅ ✅ Через частную конечную точку
Частный исходящий трафик из виртуальной сети ✅ ✅ Интеграция виртуальной сети
Полностью отключенная общедоступная конечная точка ✅ ✅ только Среда службы приложений
Частная сеть с веб-приложением для контейнеров

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

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

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

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

Приложения-контейнеры AKS Веб-приложение для контейнеров
Поддержка протокола и портов HTTP (порт 80)*
HTTPS (порт 443)*
TCP (порты 1-65535, кроме 80 и 443)		 TCP (любой порт)
UDP (любой порт)		 HTTP (порт 80)
HTTPS (порт 443)
Поддержка WebSocket ✅ ✅ ✅
Поддержка HTTP/2 ✅ ✅ ✅

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

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

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

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

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

Контейнеры приложений AKS Веб-приложение для контейнеров
Подсистема балансировки нагрузки уровня 4 Управляемый Azure Общая ответственность Управляемый Azure
Подсистема балансировки нагрузки уровня 7 Управляемый Azure Общий или самоуправляемый Управляемый Azure

Обнаружение служб

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

Контейнеры приложений AKS Веб-приложение для контейнеров
Обнаружение служб Полное доменное имя, управляемое Azure Настраиваемая настройка Kubernetes Полное доменное имя, управляемое Azure

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

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

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

Внимание

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

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

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

Контейнеры приложений AKS Веб-приложение для контейнеров
Настройка пользовательских доменов Готовое BYO Готовое
Управляемый TLS для полных доменных имен Azure Готовое Н/П Готовое
Управляемый TLS для пользовательских доменов В предварительной версии BYO Вне поля или BYO

Пользователи AKS отвечают за управление DNS, конфигурациями кластера и сертификатами TLS для своих пользовательских доменов. Хотя AKS не предлагает управляемый ПРОТОКОЛ TLS, клиенты могут использовать программное обеспечение из экосистемы Kubernetes, например популярный диспетчер сертификатов для управления сертификатами TLS.

Взаимное TLS

Другой альтернативой ограничению входящего трафика является взаимное tls (mTLS). Взаимный ПРОТОКОЛ TLS — это протокол безопасности, обеспечивающий проверку подлинности клиента и сервера в обмене данными. Для выполнения проверки подлинности обе стороны обмениваются и проверяют сертификаты перед передачей данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внимание

Обратите внимание, что этот раздел не относится к веб-приложению для контейнеров, который использует API Azure Resource Manager в качестве уровня управления.

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

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

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

Контейнеры приложений AKS
Элементы управления доступом к API Kubernetes Нет доступа Полный доступ

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

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

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

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

Контейнеры приложений AKS
Сетевая безопасность API Kubernetes Не настраиваемая в PaaS Настраиваемый: общедоступный IP-адрес или частный IP-адрес

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

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

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

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

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

Контейнеры приложений AKS Веб-приложение для контейнеров
Политики сети План потребления: ❌
Выделенный план: ❌		 ✅ ❌

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

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

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

Контейнеры приложений AKS Веб-приложение для контейнеров
Группы безопасности сети План потребления: ✅
Выделенный план: ✅		 ✅ ✅ Приложения, интегрированные с виртуальной сетью: только исходящий трафик

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

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

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

Контейнеры приложений AKS Веб-приложение для контейнеров
Ограничения ip-адресов входящего трафика на уровне приложений Готовое Самостоятельное управление или с помощью управляемой надстройки Готовое
Потребление ресурсов - Использует ресурсы кластера -

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

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

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

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

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

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

Контейнеры приложений AKS Веб-приложение для контейнеров
Интеграция Key Vault ✅ ✅ ✅

Дополнительные сведения см. в разделе:

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

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

Контейнеры приложений AKS Веб-приложение для контейнеров
Поддержка управляемого удостоверения ✅ ✅ ✅

Дополнительные сведения см. в разделе:

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

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

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

Контейнеры приложений AKS Веб-приложение для контейнеров
Защита от угроз среды выполнения ❌ ✅ ❌

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

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

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

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

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

Хорошо разработанная платформа для обеспечения безопасности

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

Дополнительные сведения о безопасности AKS см. в статье "Хорошо архитекторированные платформы" — AKS.

Рабочие соображения

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

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

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

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

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

Контейнеры приложений AKS Веб-приложение для контейнеров
Обновления уровня управления Платформа Клиент Платформа
Обновления узлов и исправления Платформа Клиент Платформа
Обновления и исправления образов контейнеров Клиент Клиент Клиент

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

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

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

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

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

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

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

В этих статьях содержатся сведения о предложениях SKU для других двух служб:

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

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

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

Контейнеры приложений AKS Веб-приложение для контейнеров
Горизонтальное масштабирование инфраструктуры План потребления: N/A
Выделенный план: настраиваемый		 Конфигурируемый Конфигурируемый
Гибкая подготовка оборудования План потребления: N/A
Выделенный план: абстрагирован с профилями рабочей нагрузки		 Любой номер SKU виртуальной машины Рассеянный. См. Служба приложений план.

Внимание

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

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

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

Контейнеры приложений AKS Веб-приложение для контейнеров
Горизонтальное масштабирование контейнера HTTP, TCP или метрики (ЦП, память, управление событиями) На основе метрик (ЦП, памяти или пользовательского). Вручную, на основе метрик или автоматически (предварительная версия)
Масштабируемость на основе событий Да. Ориентированность на облако. Да. Ориентированность на облако. Требуется дополнительная конфигурация. Да. Конкретный ресурс Azure.

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

Инструментирование рабочей нагрузки

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

  • Автоматическое инструментирование. Не требует изменения кода.
  • Ручное инструментирование. Минимальные изменения кода, необходимые для интеграции и настройки пакета SDK и /или клиента.
Контейнеры приложений AKS Веб-приложение для контейнеров
Автоматическое инструментирование с помощью платформы ❌ ❌ Частичная поддержка*
Автоматическое инструментирование с помощью агента ❌ Частичная поддержка* Н/П
Инструментирование вручную С помощью пакета SDK или OpenTelemetry С помощью пакета SDK или OpenTelemetry С помощью пакета SDK или OpenTelemetry

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

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

Журналы

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

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

Контейнеры приложений AKS Веб-приложение для контейнеров
Поддержка потоковой передачи журналов (потоковая передача в режиме реального времени) ✅ ✅ ✅
Поддержка Azure Monitor ✅ ✅ ✅
Журналы ресурсов Azure Monitor Консоль и система Сервер API Kubernetes, аудит, планировщик, автомасштабирование кластера и многое другое ConsoleLogs, HTTPLogs, EnvironmentPlatformLogs и многое другое

Для подробного описания каждого журнала ресурсов в таблице выберите ссылки в таблице.

Ниже приведены краткие сведения о возможностях ведения журнала служб контейнеров:

  • Контейнерные приложения абстрагируют все внутренние журналы Kubernetes в две категории. Один из журналов консоли содержит журналы контейнеров рабочей нагрузки. Вторая категория системы содержит все журналы, связанные с платформой.
  • AKS предоставляет все журналы, связанные с Kubernetes, и детальный контроль над тем, что можно регистрироваться. Он также сохраняет полную совместимость с клиентскими средствами Kubernetes для потоковой передачи журналов, таких как kubectl.
  • Веб-приложение для контейнеров предоставляет множество категорий журналов ресурсов, так как ее платформа (Служба приложений) не является исключительно для рабочих нагрузок контейнеров. Для операций, относящихся к контейнеру, которые управляют внутренней платформой Docker, она предоставляет категорию журнала AppServicePlatformLogs. Еще одна важная категория — AppServiceEnvironmentPlatformLogs, которая регистрирует события, такие как масштабирование и изменения конфигурации.

Хорошо разработанная платформа для повышения эффективности работы

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

Надежность

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

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

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

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

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

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

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

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

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

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

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

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

Избыточность с зонами доступности

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

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

Функция Контейнеры приложений AKS Веб-приложение для контейнеров
Поддержка зоны доступности Полностью Полностью Полностью

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

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

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

Чтобы лучше различать типы проб работоспособности, ознакомьтесь со встроенными типами проб из Kubernetes:

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

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

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

Приложения-контейнеры AKS Веб-приложение для контейнеров
Пробы запуска ✅ ✅ Частичная поддержка
Пробы готовности ✅ ✅ ❌
Пробы liveness ✅ ✅ ✅
Степень детализации интервала сек. сек. 1 минута
Поддержка протоколов HTTP(S)
TCP		 HTTP(S)
TCP
gRPC;		 HTTP(S)

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

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

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

Автоматическое устранение неполадок

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

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

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

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

Контейнеры приложений AKS Веб-приложение для контейнеров
Стратегия нулевого простоя Последовательное обновление Последовательное обновление, а также все другие стратегии Kubernetes Слоты развертывания

Обратите внимание, что архитектуры приложений также должны поддерживать развертывание без простоя. Дополнительные сведения см. в статье Azure Well-Architected Framework .

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

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

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

Хорошо разработанная платформа для надежности

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

Заключение

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

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

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

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

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

Соавторы

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

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

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

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

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