Выбор службы контейнеров Azure
Azure предлагает ряд служб размещения контейнеров, предназначенных для удовлетворения различных рабочих нагрузок, архитектур и бизнес-требований. Это руководство по выбору службы контейнеров поможет вам понять, какую службу контейнеров Azure лучше всего подходит для сценариев и требований к рабочей нагрузке.
Примечание.
В этом руководстве термин рабочей нагрузки относится к коллекции ресурсов приложений, которые поддерживают бизнес-цель или выполнение бизнес-процесса. Рабочая нагрузка использует несколько служб, таких как API и хранилища данных, которые работают вместе для обеспечения конкретных комплексных функций.
Использование этого руководства
В этом руководстве содержатся две статьи: эта введение и другая статья о рекомендациях, которые используются для всех типов рабочих нагрузок.
Примечание.
Если вы еще не привержены контейнеризации, см. статью "Выбор вычислительной службы Azure" для получения сведений о других вариантах вычислений, которые можно использовать для размещения рабочей нагрузки.
В этой статье описывается службы контейнеров Azure, которые находятся в область для этого руководства, и как модели служб сравниваются с точки зрения компромиссов между настраиваемостью и мнением решений, таких как управляемые клиентом подходы и подходы, управляемые Корпорацией Майкрософт. После определения кандидатов служб на основе настроек модели службы следующим шагом является оценка параметров в соответствии с требованиями рабочей нагрузки, просмотрив статью о общих рекомендациях по работе с сетями, безопасностью, операциями и надежностью.
В этом руководстве учитываются компромиссы, которые могут потребоваться сделать на основе технических требований, размера и сложности рабочей нагрузки и опыта команды рабочей нагрузки.
Службы контейнеров Azure в область для этого руководства
В этом руководстве рассматривается подмножество служб контейнеров, которые в настоящее время предлагает Azure. Это подмножество предоставляет зрелый набор функций для веб-приложений и API, сети, наблюдаемости, средств разработчика и операций. Эти службы контейнеров сравниваются:
Приложения контейнеров Azure — это полностью управляемая платформа приложений На основе Kubernetes, которая помогает развертывать HTTP-приложения и приложения, отличные от HTTP, из кода или контейнеров без оркестрации инфраструктуры. Дополнительные сведения см . в документации по приложениям контейнеров Azure.
Служба Azure Kubernetes (AKS) — это управляемая служба Kubernetes для запуска контейнерных приложений. С помощью AKS вы можете воспользоваться преимуществами управляемых надстроек и расширений для дополнительных возможностей, сохраняя самый широкий уровень настройки. Дополнительные сведения см . в документации ПО AKS.
Веб-приложение для контейнеров — это функция службы приложение Azure, полностью управляемая служба для размещения веб-приложений на основе HTTP с встроенным обслуживанием инфраструктуры, исправлением безопасности, масштабированием и средствами диагностики. Дополнительные сведения см. в статье Документация по Службе приложений.
Полный список всех служб контейнеров Azure см . на странице категории продуктов служб контейнеров.
Рекомендации по модели службы
Модель службы предоставляет самые широкие сведения о уровне гибкости и контроле над тем, что любая служба контейнеров Azure предоставляет в обмен на общую простоту и простоту использования.
Общие сведения о терминологии и концепциях моделей служб, включая инфраструктуру как службу (IaaS) и платформу как службу (PaaS), см. в разделе "Общая ответственность" в облаке.
Сравнение моделей служб решений контейнеров Azure
AKS
Как гибрид IaaS и PaaS AKS определяет контроль над простотой. Хотя AKS упрощает управление базовой базовой инфраструктурой, эта платформа на основе виртуальных машин по-прежнему предоставляется вашим приложениям и требует соответствующих параметров защиты и процессов, таких как исправление, для обеспечения безопасности и непрерывности бизнес-процессов. Инфраструктура вычислений поддерживается дополнительными ресурсами Azure, размещенными непосредственно в подписке, например подсистемами балансировки нагрузки Azure.
AKS также предоставляет доступ к серверу API Kubernetes, что позволяет настраивать оркестрацию контейнеров и развертывать проекты из Cloud Native Computing Foundation (CNCF). Следовательно, существует значительная кривая обучения для рабочих нагрузок, которые являются новыми для Kubernetes. Если вы не знакомы с контейнерными решениями, эта кривая обучения может быть сдерживающим фактором. Следующие решения PaaS предлагают более низкий барьер для входа. Вы можете перейти в Kubernetes, когда требования диктуют этот шаг.
Приложения-контейнеры Azure
Контейнерные приложения, предложение PaaS, балансирует управление простотой. Он предлагает бессерверные и выделенные параметры вычислений, которые абстрагируют необходимость исправления операционной системы или защиты сборки вокруг приложений относительно операционной системы. Контейнерные приложения также полностью абстрагируют API оркестрации контейнеров и предоставляют подмножество своих ключевых функций через API Azure, с которыми ваша команда уже знакома. Кроме того, уровень 7 входящего трафика, разделение трафика, тестирование A/B и управление жизненным циклом приложений полностью доступны из поля.
Веб-приложение для контейнеров
Веб-приложение для контейнеров также является предложением PaaS, но обеспечивает большую простоту и меньше контроля, чем контейнерные приложения. Он абстрагирует оркестрацию контейнеров, но по-прежнему обеспечивает соответствующее масштабирование, управление жизненным циклом приложений, разделение трафика, интеграцию сети и наблюдаемость.
Рекомендации по модели размещения
Ресурсы Azure, такие как кластеры AKS, можно использовать для размещения нескольких рабочих нагрузок. Это позволяет оптимизировать операции и тем самым снизить общую стоимость. Если вы выберете этот путь, ниже приведены некоторые важные аспекты.
AKS обычно используется для размещения нескольких рабочих нагрузок или разрозненных компонентов рабочей нагрузки. Эти рабочие нагрузки и компоненты можно изолировать с помощью собственных функций Kubernetes, таких как пространства имен, элементы управления доступом и сетевые элементы управления, чтобы соответствовать требованиям безопасности.
Вы также можете использовать AKS в сценариях с одной рабочей нагрузкой, если требуется дополнительная функциональность, которую предоставляет API Kubernetes, и ваша группа рабочей нагрузки имеет достаточно опыта работы с кластером Kubernetes. Teams с меньшим опытом Kubernetes по-прежнему могут успешно работать с собственными кластерами, используя преимущества управляемых надстроек и функций Azure, таких как автоматическое обновление кластера, чтобы снизить операционные издержки.
Приложения-контейнеры должны использоваться для размещения одной рабочей нагрузки с общей границей безопасности. Контейнерные приложения имеют одну логическую границу верхнего уровня, называемую средой "Приложения контейнеров", которая также служит границей повышенной безопасности. Нет механизмов для дополнительного детального контроля доступа. Например, взаимодействие между средами неограниченно, а все приложения совместно используют одну рабочую область Log Analytics.
Если рабочая нагрузка имеет несколько компонентов и несколько границ безопасности, разверните несколько сред контейнеров или рассмотрите возможность использования AKS.
Веб-приложение для контейнеров — это функция Служба приложений. Служба приложений группируйте приложения в границу выставления счетов, называемую планом Служба приложений. Так как вы можете область управление доступом на основе ролей (RBAC) на уровне приложения, это может оказаться заманчивым для размещения нескольких рабочих нагрузок в одном плане. Однако рекомендуется разместить одну рабочую нагрузку на план, чтобы избежать проблемы с шумным соседом. Все приложения в одном плане Служба приложений используют одинаковые выделенные вычислительные ресурсы, память и хранилище.
При рассмотрении изоляции оборудования необходимо помнить, что Служба приложений планов обычно выполняются в инфраструктуре, которая предоставляется другим клиентам Azure. Вы можете выбрать выделенные уровни для выделенных виртуальных машин или изолированных уровней для выделенных виртуальных машин в выделенной виртуальной сети.
Как правило, все службы контейнеров Azure могут размещать несколько приложений с несколькими компонентами. Однако контейнерные приложения и веб-приложение для контейнеров лучше подходят для одного компонента рабочей нагрузки или нескольких компонентов рабочей нагрузки с высоким уровнем связи, использующих аналогичный жизненный цикл, где одна команда владеет и запускает приложения.
Если необходимо разместить разрозненные компоненты приложения или рабочие нагрузки на одном узле, рассмотрите возможность использования AKS.
Компромисс между контролем и простотой использования
AKS обеспечивает наиболее настраиваемую возможность, но эта настраиваемость приходится за счет увеличения эксплуатационных накладных расходов по сравнению с другими службами. Хотя контейнерные приложения и веб-приложение для контейнеров являются службами PaaS, которые имеют аналогичные уровни функций, управляемых Корпорацией Майкрософт, веб-приложение для контейнеров подчеркивает простоту для удовлетворения целевой аудитории: существующих клиентов Azure PaaS, которые находят интерфейс знакомым.
Правило отпечатка
Как правило, службы, которые предлагают большую простоту, как правило, подходят для клиентов, которые предпочитают сосредоточиться больше на разработке функций и меньше на инфраструктуре. Службы, которые предлагают больше контроля, как правило, подходят для клиентов, которым нужна более настраиваемая возможность и имеют навыки, ресурсы и бизнес-обоснование, необходимые для управления собственной инфраструктурой.
Общие рекомендации для всех рабочих нагрузок
Хотя команда рабочей нагрузки может предпочесть определенную модель службы, эта модель может не соответствовать требованиям организации в целом. Например, разработчики могут предпочесть меньше операционных накладных расходов, но группы безопасности могут рассмотреть этот тип накладных расходов, необходимых для соответствия требованиям. Teams должны сотрудничать, чтобы сделать соответствующие компромиссы.
Помните, что общие рекомендации являются широкими. Только подмножество может иметь отношение к вам, в зависимости от типа рабочей нагрузки, а также от вашей роли в организации.
В следующей таблице представлен общий обзор рекомендаций, включая сравнение функций службы. Просмотрите рекомендации в каждой категории и сравните их с требованиями рабочей нагрузки.
| Категория | Обзор |
|---|---|
| Рекомендации по работе с сетями | Сеть в службах контейнеров Azure зависит от вашего предпочтения простоты и настройки. AKS очень настраивается, обеспечивая широкий контроль над сетевым потоком, но требует более оперативной работы. Контейнерные приложения предлагают функции сети, управляемые Azure. Это средний уровень между AKS и веб-приложением для контейнеров, который предназначен для клиентов, знакомых с Служба приложений. Важно, что решения по проектированию сети могут иметь долгосрочные последствия из-за проблем, возникающих при их изменении без повторного развертывания рабочих нагрузок. Несколько факторов, таких как планирование IP-адресов, балансировка нагрузки, методы обнаружения служб и возможности частной сети, отличаются между этими службами. Необходимо тщательно проверить, как службы соответствуют конкретным требованиям к сети. |
| Вопросы безопасности | Контейнерные приложения, AKS и веб-приложение для контейнеров обеспечивают интеграцию с ключевыми предложениями безопасности Azure, такими как Azure Key Vault и управляемые удостоверения. AKS предлагает дополнительные функции, такие как защита от угроз среды выполнения и политики сети. Хотя может показаться, что службы PaaS, такие как контейнерные приложения, предлагают меньше функций безопасности, это частично связано с тем, что больше базовых компонентов инфраструктуры управляются Azure и не подвержены клиентам, что снижает риск. |
| Рекомендации по работе | Хотя AKS предлагает большую настройку, он требует больше рабочего ввода. В отличие от этого, решения PaaS, такие как контейнерные приложения и веб-приложение для контейнеров, позволяют Azure обрабатывать такие задачи, как обновления ОС. Гибкость масштабируемости и аппаратного SKU имеют решающее значение. AKS предоставляет гибкие варианты оборудования, в то время как контейнерные приложения и веб-приложение для контейнеров предоставляют конфигурации наборов. Масштабируемость приложений в AKS является единственной ответственностью клиента. Контейнерные приложения и веб-приложение для контейнеров предлагают более упрощенные подходы. |
| Рекомендации по надежности | Конфигурации проб работоспособности веб-приложений для контейнеров и контейнерных приложений упрощаются, чем в AKS, учитывая, что они используют знакомый API Azure Resource Manager. AKS требует использования API Kubernetes. Кроме того, необходимо взять на себя дополнительную ответственность за управление масштабируемостью пула узлов Kubernetes и доступностью, чтобы правильно запланировать экземпляры приложений. Эти требования приводят к дополнительным издержкам для AKS. Кроме того, соглашения об уровне обслуживания для контейнерных приложений и веб-приложения для контейнеров более просты, чем akS, для которых пулы элементов управления и пулы узлов имеют собственные соглашения об уровне обслуживания и должны быть обучены соответствующим образом. Все службы обеспечивают избыточность зоны в центрах обработки данных, которые предлагают его. |
После просмотра предыдущих рекомендаций, возможно, вы еще не нашли идеальное соответствие. Это совершенно нормально.
Оценка компромиссов
Выбор облачной службы не является простым упражнением. Учитывая сложность облачных вычислений, совместная работа между многими командами и ограничениями ресурсов с участием людей, бюджетов и времени, каждое решение имеет компромиссы.
Помните, что для любой конкретной рабочей нагрузки некоторые требования могут быть более важными, чем другие. Например, команда приложений может предпочесть решение PaaS, например контейнерные приложения, но выбрать AKS, так как для команды безопасности требуется запретить сетевые элементы управления по умолчанию между совместно используемыми компонентами рабочей нагрузки, которая является функцией только AKS, используюющей сетевые политики Kubernetes.
Наконец, обратите внимание, что предыдущие общие рекомендации включают наиболее распространенные требования, но не являются исчерпывающими. Перед подтверждением решения команда рабочей нагрузки несет ответственность за изучение каждого требования к набору функций предпочтительной службы.
Заключение
В этом руководстве описаны наиболее распространенные аспекты, с которыми вы сталкиваетесь при выборе службы контейнеров Azure. Она предназначена для руководства командам рабочей нагрузки в принятии обоснованных решений. Процесс начинается с выбора модели облачной службы, которая включает определение требуемого уровня управления. Контроль приходит за счет простоты. Другими словами, это процесс поиска правильного баланса между самоуправляемой инфраструктурой и управляемой корпорацией Майкрософт.
Многие команды рабочей нагрузки могут выбирать службу контейнеров Azure исключительно на основе предпочтительной модели службы: PaaS и IaaS. Другие команды должны изучить дополнительные сведения о том, как функции, относящиеся к службам, относятся к рабочей нагрузке или требованиям организации.
Все команды рабочей нагрузки должны использовать это руководство в дополнение к включению должной проверки, чтобы избежать сложных решений. Помните, однако, что решение не подтверждается, пока разработчики не пытаются попробовать службу и решить на основе опыта, а не теории.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.
Основные авторы:
- Андре Деуэс | Старший инженер клиента
- Маркос Мартинес | Старший инженер службы
- Джули Нг | Старший инженер
Другие участник:
- Мик Альбертс | Технический писатель
- Мартин Gjoшевски | Старший инженер клиента
- Don High | Главный инженер клиента
- Nelly Kiboi | Инженер службы
- Xuhong Liu | Старший инженер службы
- Фейсал Мустафа | Старший инженер клиента
- Уолтер Майерс | Главный менеджер по проектированию клиентов
- Соналика Рой | Старший инженер клиента
- Паоло Сальватори | Главный инженер клиента
- Виктор Сантана | Главный инженер клиента
Следующий шаг
Дополнительные сведения об общих архитектурных рекомендациях для служб, упоминание в этой статье.