Рекомендации по использованию приложений контейнеров Azure в мультитенантном решении

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

Модели изоляции

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

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

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

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

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

Приложения общего контейнера

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

На изображении показаны арендатор A, арендатор B и арендатор C. Три стрелки направлены от каждого из этих арендаторов к разделу среды "Общие контейнерные приложения", содержащему текст "Арендаторы A, B, C".

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

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

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

Замечание

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

Приложения контейнеров для конкретного арендатора

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

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

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

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

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

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

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

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

Замечание

Не используйте редакции для создания разных версий приложения для разных клиентов. Редакции не обеспечивают изоляцию ресурсов. Они предназначены для сценариев развертывания, в которых во время развертывания обновления должно выполняться несколько версий приложения. Этот подход включает стратегии, такие как сине-зеленые развертывания и тестирование A/B.

Одна среда для каждого клиента

Рассмотрите возможность развертывания одной среды контейнерных приложений для каждого клиента. Среда "Приложения контейнеров" — это граница изоляции для группы приложений-контейнеров. Среда обеспечивает вычисление и сетевую изоляцию на плоскости данных. Каждая среда развертывается в собственной виртуальной сети. Все приложения в среде совместно используют эту виртуальную сеть. Каждая среда имеет собственную конфигурацию Dapr и мониторинга.

Изображение содержит значки, представляющие клиента A, клиента B и клиента C. Стрелки указывают от этих значков на соответствующие индивидуальные среды контейнерных приложений. Три среды клиента: Tenant A, Tenant B и Tenant C.

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

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

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

Функции контейнеров, поддерживающие мультитенантность

Индивидуальные доменные имена

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

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

Запрос проверки подлинности и авторизации

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

Если клиенты используют идентификатор Microsoft Entra в качестве поставщика удостоверений, вы можете настроить контейнерные приложения для проверки маркеров пользователей с помощью /common endpoint . Этот подход гарантирует, что токены пользователей проверяются и принимаются независимо от тенанта Microsoft Entra пользователя.

Вы также можете интегрировать контейнерные приложения с внешним идентификатором Microsoft Entra для проверки подлинности пользователей с помощью поставщиков удостоверений партнеров.

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

• Авторизация контейнерных приложений
• Включение проверки подлинности и авторизации в приложениях контейнеров с помощью идентификатора Microsoft Entra

Замечание

Функции проверки подлинности и авторизации в контейнерных приложениях аналогичны функциям в Службе приложений Azure. Однако существуют некоторые различия. Дополнительные сведения см. в статье "Рекомендации по использованию встроенной проверки подлинности".

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

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

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

Дополнительные сведения см. в разделе «Управляемые удостоверения в контейнерных приложениях».

Профили рабочей нагрузки для выделенных вычислений

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

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

Маршрутизация на основе правил

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

Дополнительные сведения см. в разделе «Использование маршрутизации на основе правил» для контейнерных приложений.

Соавторы

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

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

• Даниэль Ларсен | Главный инженер клиента, FastTrack для Azure
• Уилл Велида | Инженер по работе с клиентами 2, FastTrack для Azure

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

• Джон Даунс | Главный инженер по программному обеспечению, шаблоны и практики Azure
• Чад Киттель | Главный инженер по программному обеспечению, шаблоны и практики Azure
• Xuhong Liu | Старший инженер службы, FastTrack для Azure
• Аартхи Муруган | Старший руководитель программы, CS Tech Strategy App Innovation
• Кендалл Роден | Старший менеджер программ, приложения контейнеров
• Паоло Сальватори | Главный инженер клиента, FastTrack для Azure
• Даниэль Скотт-Райнсфорд | Архитектор решений партнеров, данные и ИИ
• Арсен Владимирский | Главный инженер по работе с клиентами, FastTrack для Azure

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

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

• Общие сведения о продукте "Приложения контейнеров"
• Документация по контейнерным приложениям

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

• Ресурсы для архитекторов и разработчиков мультитенантных решений
• Проектирование мультитенантных решений в Azure
• Контрольный список для проектирования и создания мультитенантных решений в Azure