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

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

  • Статья

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

Заметка

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

Обзор

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

вопросы архитектуры и сети

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

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

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

операционные вопросы

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

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

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

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

Заметка

Некоторые разделы отличают AKS Standard от AKS Automatic. Если в разделе не делается различий между двумя, предполагается равенство функциональных возможностей.

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

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

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

Заметка

AKS Automatic — это более мнениее решение, чем AKS Standard. Некоторые встроенные функции не могут быть отключены. В этом руководстве эти особенности не упоминаются. Актуальная информация об этих ограничениях и сравнение функций "Стандартный" и "Автоматический" см. в статье сравнение автоматических и стандартных функций AKS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заметка

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

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

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

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

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

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

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

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

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

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

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

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

Контейнерные приложения 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 уровня 4 Управляемый Azure Общая ответственность Управляемый Azure
балансировщик нагрузки уровня 7 Управляемый Azure Общий или самоуправляемый Управляемый Azure

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

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

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

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

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

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

Важный

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

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

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

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

Пользователи AKS отвечают за управление DNS, конфигурациями кластера и сертификатами TLS для своих пользовательских доменов. Хотя AKS не предлагает управляемый TLS, клиенты могут использовать решения из экосистемы Kubernetes, например популярный cert-manager для управления сертификатами 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 или включить автоматическое обновление базовых узлов с помощью параметров конфигурации.

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

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

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

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

Важный

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Контейнерные приложения AKS Веб-приложение для контейнеров
встроенные ограничения IP-адресов входящего трафика ✅ ❌* ✅
потребление ресурсов - Использует ресурсы кластера -

Заметка

AKS предлагает ограничения ip-адресов входящего трафика, но это собственная функция Kubernetes, а не Azure Native, как и другие службы.

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

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

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

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

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

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

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

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

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

Контейнерные приложения AKS Веб-приложение для контейнеров
Поддержка управляемых удостоверений инфраструктуры N/A ✅ N/A
Поддержка управляемой удостоверенности для извлечения контейнеров ✅ ✅ ✅
Поддержка управляемых удостоверений приложений ✅ ✅ ✅

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

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

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

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

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

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

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

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

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

Заметка

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

Well-Architected Основы безопасности

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

Для получения более полного руководства по безопасности AKS см. Well-Architected обзор платформы AKS.

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

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

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

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

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

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

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

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

Независимо от решения на основе 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.

AKS Automatic по умолчанию включает горизонтальное автомасштабирование Pod (Horizontal Pod Autoscaler), автомасштабирование на основе событий в Kubernetes (KEDA) и вертикальное автомасштабирование Pod (VPA).

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

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

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

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

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

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

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

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

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

Контейнерные приложения AKS AKS Automatic Веб-приложение для контейнеров
поддержка потоковой передачи журналов ✅ ✅ ✅ ✅
Поддержка Azure Monitor ✅ ✅ ✅ ✅
журналы ресурсов Azure Monitor Console и Система сервер API Kubernetes, аудит, планировщик, автомасштабирование кластера и многое другое То же, что и AKS ConsoleLogs, HTTPLogs, EnvironmentPlatformLogs и многое другое
сбор метрик и мониторинг Метрики с помощью Azure Monitor; пользовательские метрики с помощью метрик Dapr Метрики с помощью Azure Monitor; пользовательские метрики с помощью Prometheus (требуется ручная настройка) Предварительно настроенный управляемый Prometheus для сбора метрик и управляемая Grafana для визуализации; метрики с помощью Azure Monitor Метрики с помощью Azure Monitor
предварительно настроены Prometheus и Grafana ❌ Требуется ручная настройка ✅ Managed Prometheus и Managed Grafana предварительно настроены по умолчанию. ❌

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

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

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

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

Well-Architected Модель для операционного совершенства

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

Надёжность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

контейнерные приложения AKS веб-приложение для контейнеров
пробы запуска ✅ ✅ Частичная поддержка
тесты готовности ✅ ✅ ❌
Зонд жизнеспособности ✅ ✅ ✅
гранулярность детализации интервала Секунды Секунды 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 ГиБ памяти. Среда Container Apps аналогична пространству имен Kubernetes.
  • ru-RU: AKS: вы можете выбрать любое сочетание vCPU и памяти, при условии, что у ваших узлов есть необходимое оборудование для этого. Вы также можете ограничить ресурсы на уровне пространства имен , если вы хотите сегментировать кластер таким образом.

Well-Architected Структура для надежности

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

Заключение

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

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

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

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

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

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

Участники

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

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

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

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

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