Использование службы Azure Kubernetes (AKS) в мультитенантном решении

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

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

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

Типы мультитенантности

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

Несколько команд

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

В этом сценарии члены группы получают доступ к ресурсам Kubernetes одним из следующих способов:

• Непосредственно с помощью таких средств, как kubectl

• Косвенно через контроллеры GitOps, такие как Flux и Argo CD

• С помощью других средств автоматизации выпусков

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

Несколько клиентов

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

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

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

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

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

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

Мультитенантность имеет две категории на основе уровня изоляции и доверия:

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

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

При планировании создания мультитенантного кластера AKS рассмотрите следующие уровни изоляции Kubernetes :

• Cluster
• Namespace
• Пул узлов или узел
• Объект pod
• Контейнер

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

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

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

Изоляция плоскости управления

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

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

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

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

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

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

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

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

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

• Namespaces
• Средства управления доступом
• Quotas

Изоляция плоскости данных

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

Сетевая изоляция

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

AKS предоставляет следующие способы реализации политик сети:

• Политики сети Azure: Собственная реализация Azure для политик сети.

• Политики сети Calico: решение для сети и сетевой безопасности с открытым исходным кодом от Tigera.

• Azure CNI с помощью Cilium: Расширенное сетевое решение на основе фильтра пакетов Berkeley (eBPF), которое обеспечивает улучшенную производительность политики сети и расширенные возможности, включая фильтрацию уровня 7. Для этого подхода требуется Kubernetes 1.29 или более поздней версии.

Политики сети Azure и политики сети Calico используют iptableы Linux по умолчанию для применения политик. Эти реализации преобразуют политики сети в наборы разрешенных и запрещенных пар IP-адресов, а затем программируют их как правила фильтрации iptable. Azure CNI Powered by Cilium использует программы eBPF, загруженные в ядро Linux для применения политик, что повышает производительность и устраняет затраты на iptables и kube-proxy. Вы также можете настроить поддержку eBPF для Calico. Все три варианта поддерживают как сетевой плагин Azure CNI, так и режим наложения Azure CNI Overlay.

Дополнительные сведения см. в статьях "Безопасное соединение между pod с использованием сетевых политик в AKS" и "Сетевая изоляция".

Сервисная сетка

Сетки служб предоставляют расширенные возможности управления трафиком, безопасности и наблюдаемости для взаимодействия микрослужб в мультитенантных кластерах AKS. Сетки служб работают на уровне 7. Они обеспечивают точный контроль над обменом данными между службами за пределами политик сети, предоставляемых на уровнях 3 и 4.

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

• Удостоверение и проверка подлинности: Сетки служб предоставляют взаимный ПРОТОКОЛ TLS (mTLS) для автоматического шифрования и проверки подлинности связи между службами. Каждая служба получает криптографическое удостоверение на основе своего пространства имен и учетной записи сервиса, что обеспечивает основу для принудительного применения границ арендатора.

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

• Управление трафиком: Сетки служб предоставляют расширенные возможности маршрутизации трафика, поддерживающие мультитенантные развертывания:

  • Canary deployments и A/B тестирование

  • Разделение трафика для постепенного развертывания обновлений для определенных пространств имен клиента

  • Маршрутизация запросов на основе заголовков или других атрибутов для прямого трафика клиента

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

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

  • Изолируйте арендаторов в отдельных пространствах имен.

  • Применение согласованных стратегий маркировки.

  • Настройте правила маршрутизации, основанные на пути или хосте.

  • При необходимости разверните отдельные шлюзы входящего трафика для каждого клиента.

  • Создайте явные политики маршрутизации, предназначенные для определенных пространств имен клиента или меток.

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

• Политики безопасности уровня 7: Сетки служб применяют политики на основе методов HTTP, путей и заголовков, в отличие от политик сети, работающих только на IP-адресах и портах. Например, ограничьте службы клиентов только запросами GET к определенным конечным точкам API.

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

• Запланируйте нагрузку на ресурсы, которую сервисные сетки добавляют к каждому контейнеру под из-за боковых прокси-серверов. Измените размер узлов и установите квоты на ресурсы для пространств имен арендаторов соответствующим образом.

• Примените политики авторизации Istio на уровне пространства имен, чтобы применить границы изоляции клиента.

• Настройте явные политики авторизации с отказом по умолчанию, чтобы обеспечить изоляцию клиента. По умолчанию разрешен весь трафик.

• Используйте отдельные шлюзы Istio ingress на уровне клиента (базовый, стандартный, премиум), чтобы обеспечить различные уровни управления трафиком и безопасности.

Дополнительные сведения см. в разделе "Развертывание функции сетки служб на основе Istio" для AKS.

Изоляция хранилища

Azure предоставляет управляемые репозитории данных PaaS, такие как База данных SQL Azure и Azure Cosmos DB, а также другие службы хранилища, которые можно использовать в качестве постоянных томов для рабочих нагрузок. Приложения клиента, работающие в общем кластере AKS, могут совместно использовать базу данных или хранилище файлов или использовать выделенные репозитории данных и ресурсы хранилища. Дополнительные сведения см. в разделе "Архитектурные подходы к хранилищу и данным" в мультитенантных решениях.

Рабочие нагрузки AKS могут использовать постоянные тома для хранения данных. Постоянные тома можно создавать в качестве ресурсов Kubernetes, поддерживаемых службой хранилища Azure. Вручную создайте и назначьте тома данных pods напрямую или позволяйте AKS автоматически создавать их с помощью запросов на постоянный том. AKS включает встроенные классы хранилища для создания постоянных томов, которые поддерживают управляемые диски Azure, файлы Azure и Azure NetApp Files . Дополнительные сведения см. в статье о возможности хранения данных приложений в AKS. Избегайте использования локального хранилища на узлах агента с помощью emptyDir и hostPath по соображениям безопасности и устойчивости.

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

Например, создайте пользовательский класс хранилища для каждого клиента и используйте его для применения тегов к постоянным томам в своих пространствах имен для возврата затрат. Дополнительные сведения см. в статье Использование тегов Azure вAKS.

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

Изоляция узлов

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

Чтобы ограничить модули pod клиента определенными узлами или пулами узлов, используйте таинты и терпимости, метки узлов, селекторы узлов и сходство узлов.

AKS обеспечивает изоляцию рабочей нагрузки на нескольких уровнях:

• Уровень ядра: AKS может запускать рабочие нагрузки клиента на упрощенных виртуальных машинах (виртуальных машинах) на узлах общего агента и с помощью песочницы pod на основе контейнеров Kata.

• Физический уровень: Вы можете размещать приложения клиента в выделенных кластерах или пулах узлов.

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

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

Используйте изоляцию узлов для легкого связывания и оплаты стоимости набора узлов или пула узлов с одним клиентом. Выбор зависит от модели аренды решения. Дополнительные сведения см. в разделе "Изоляция узлов".

Модели аренды

AKS предоставляет различные типы моделей изоляции узлов и аренды.

Автоматизированные развертывания с одним клиентом

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

Каждая рабочая нагрузка клиента выполняется в выделенном кластере AKS и обращается к отдельному набору ресурсов Azure. Эта модель обычно использует средства инфраструктуры как кода (IaC). Чтобы автоматизировать развертывание выделенных клиентом ресурсов, используйте Bicep, Azure Resource Manager, Terraform или REST API Resource Manager. Используйте этот подход, когда необходимо подготовить отдельную инфраструктуру для каждого клиента. При планировании развертывания рассмотрите шаблон меток развертывания.

Этот подход обеспечивает следующие преимущества:

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

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

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

• Использование наложения Azure CNI во всех кластерах клиентов упрощает планирование IP-адресов и позволяет повторно использовать одно и то же пространство POD CIDR в нескольких изолированных кластерах.

Этот подход имеет следующие риски:

• Каждый клиент использует выделенные ресурсы, что увеличивает затраты.

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

Полностью мультитенантные развертывания

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

Этот подход обеспечивает следующие преимущества:

• Снижение операционных затрат от общих компонентов. Чтобы обрабатывать трафик, создаваемый всеми клиентами, может потребоваться развернуть более крупный кластер AKS и использовать более высокий номер SKU для общих репозиториев данных.

Этот подход имеет следующие риски:

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

• Для сильно изменяющегося трафика требуется автомасштабирование кластера. Настройте автомасштабирование кластера AKS, чтобы изменить количество подов и узлов агентов на основе использования системных ресурсов, таких как ЦП и память. Кроме того, масштабируйте pod и узлы кластера на основе пользовательских метрик, например, количества ожидающих запросов или метрик из внешней системы обмена сообщениями с использованием Kuberntes-based Event Driven Autoscaler (KEDA).

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

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

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

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

Горизонтально секционированные развертывания

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

Этот подход обеспечивает следующие преимущества:

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

Этот подход имеет следующие риски:

• Необходимо автоматизировать развертывание и управление компонентами, особенно компонентами, которые использует один клиент.

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

Развертывания с вертикальной секционированием

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

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

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

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

• Базовый уровень: Одно общее мультитенантное приложение Kubernetes обслуживает все запросы клиента. Все клиенты уровня "Базовый" совместно используют одну или несколько баз данных.

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

• Уровень "Премиум": Каждое приложение клиента выполняется в выделенном пуле узлов или кластере AKS. Такой подход гарантирует более высокий уровень обслуживания, более высокую производительность и более высокую изоляцию. Затраты основаны на количестве и SKU агентских узлов, в которых размещается арендованное приложение. Чтобы изолировать отдельные рабочие нагрузки клиента, песочница pod предоставляет альтернативу выделенным кластерам или пулам узлов.

На следующей схеме показан сценарий, в котором арендаторы A и B работают на общем кластере AKS, а арендатор C работает на отдельном кластере AKS.

На следующей схеме показан сценарий, в котором клиенты A и B выполняются в одном пуле узлов, а клиент C выполняется в выделенном пуле узлов.

Эта модель также может предоставлять различные соглашения об уровне обслуживания для разных уровней. Например, уровень "Базовый" может предоставлять 99,90% время простоя, уровень "Стандартный" может предоставлять 99,95% время простоя, а уровень "Премиум" может предоставлять 99,99% время простоя. Владелец приложения определяет и владеет этими соглашениями об уровне обслуживания. Чтобы реализовать более высокое соглашение об уровне обслуживания, используйте службы и функции, обеспечивающие более высокие целевые показатели доступности.

Этот подход обеспечивает следующие преимущества:

• Общая инфраструктура снижает затраты. Развертывание общих кластеров и пулов узлов для клиентов уровня "Базовый" и "Стандартный". Этот подход использует размеры виртуальных машин с более низкой стоимостью для агентных узлов и обеспечивает более высокую плотность ресурсов. Для клиентов уровня "Премиум" можно развернуть кластеры и пулы узлов AKS с более высоким размером виртуальной машины и максимальным количеством реплик и узлов pod по более высокой цене.

• Изоляция системных служб в пулах выделенных узлов. Запустите системные службы, такие как CoreDNS, Konnectivity или контроллер входящего трафика Шлюза приложений Azure (AGIC) в пулах узлов в режиме системы. Чтобы запустить приложения арендатора в одном или нескольких пулах узлов в пользовательском режиме, используйте таинты и терпимости, метки узлов, селекторы узлов и предпочтения узлов.

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

Этот подход имеет следующие риски:

• Приложение Kubernetes должно поддерживать как мультитенантные, так и однотенантные развертывания.

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

• Для управления и мониторинга нескольких кластеров AKS требуется централизованный мониторинг и согласованная стратегия.

Autoscaling

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

• Нагрузка на трафик увеличивается в течение определенных рабочих часов или периодов.

• Рабочие нагрузки арендатора или интенсивные общие нагрузки развертываются в кластере.

• Узлы агента становятся недоступными из-за сбоев зоны доступности.

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

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

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

Автомасштабирование подов автоматически регулирует их количество на основе требований к ресурсам. HorizontalPodAutoscaler масштабирует реплики pod на основе ЦП, памяти или пользовательских метрик. KEDA масштабирует контейнеры на основе событий из внешних систем, использующих приложения клиента, такие как Центры событий Azure или служебная шина Azure.

Вертикальный модуль автомасштабирования pod (VPA) настраивает ЦП и память, выделенные для модулей pod, что сокращает количество узлов, необходимых для запуска приложений клиента. Меньше узлов снижает общую стоимость и помогает избежать шумных проблем соседей.

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

Maintenance

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

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

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

Доступ к кластеру

При совместном использовании кластера AKS между несколькими командами в организации реализуйте принцип наименьшей привилегии для изоляции разных клиентов друг от друга. Предоставление пользователям доступа только к пространствам имен Kubernetes и ресурсам при использовании таких средств, как kubectl, Helm, Flux или Argo CD.

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

• параметры доступа и удостоверения для AKS
• интеграции с Microsoft Entra, управляемой AKS,
• Kubernetes RBAC с идентификатором Microsoft Entra в AKS

Идентификация рабочей нагрузки

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

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

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

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

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

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

Дополнительные сведения о шагах реализации и примерах кода см. в статье Использование идентификатора рабочей нагрузки Microsoft Entra с AKS и развертыванием и настройкой идентификатора рабочей нагрузки в AKS.

Песочница Pod

Песочница pod AKS обеспечивает границу изоляции между приложениями-контейнерами и общим ядром и вычислительными ресурсами узла контейнера, такими как ЦП, память и сеть. Подсистема песочницы Pod дополняет другие меры безопасности и контроль защиты данных, чтобы помочь арендаторам обеспечить безопасность конфиденциальной информации и соответствие требованиям нормативных, индустриальных стандартов и управления, таким как Стандарт безопасности данных индустрии платёжных карт (PCI DSS), Международный стандарт ISO 27001 и Закон о переносимости и подотчетности медицинской информации (HIPAA).

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

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

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

Рассмотрим следующие ограничения песочницы pod в AKS:

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

• Контейнеры Kata могут не достичь той же производительности входных и выходных операций в секунду (IOPS), что и традиционные контейнеры в файлах Azure и высокопроизводительные локальные твердотельные накопители (SSD).

• Microsoft Defender для контейнеров не поддерживает проведение оценок безопасности pod'ов среды выполнения Kata.

• Доступ к сети узла не поддерживается.

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

• Песочница Pod с помощью AKS
• Поддержка изолированных контейнеров Kata VM в AKS для ограничения подов

Выделенный узел Azure

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

Выделенный сервер с AKS обеспечивает следующие преимущества:

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

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

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

Автоподготовка узла

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

Автопровизирование узлов улучшает работу многопользовательского кластера следующим образом:

• Динамические типы узлов для конкретного клиента: Автоматическая подготовка узла подготавливает соответствующий размер виртуальной машины для требований к рабочей нагрузке каждого клиента. Например, если клиент A разворачивает рабочие нагрузки, интенсивно использующие GPU, а клиент B запускает приложения, интенсивно использующие память, автоматическое создание узлов создаст узлы, оптимизированные под GPU для клиента A, и узлы, оптимизированные под память для клиента B.

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

• Размещение зоны доступности: Автоматическая подготовка узлов может подготавливать узлы в определенных зонах доступности для удовлетворения требований к задержке клиента или месту размещения данных на основе ограничений топологии pod.

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

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

Чтобы включить автоматическое подключение узлов в вашем кластере AKS и определить требования к рабочей нагрузке, используйте следующие нативные для Kubernetes конфигурации:

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

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

• Используйте ограничения распространения топологии для управления распределением pod по зонам доступности.

• Примените таинты и толерантности, чтобы направить рабочие нагрузки на правильно подготовленные узлы.

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

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

Конфиденциальные виртуальные машины

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

Конфиденциальные виртуальные машины AMD Secure Encrypted Virtualization-Secure Вложенное отображение страниц (SEV-SNP) запрещают гипервизору и другому коду управления узлами доступ к памяти и состоянию виртуальной машины, что добавляет уровень и глубину защиты от доступа оператора. Дополнительные сведения см. в статье Использование конфиденциальных виртуальных машин в кластере AKS.

FIPS (Федеральные стандарты обработки информации)

FIPS 140-3 — это стандарт для государственных организаций США, определяющий минимальные требования к безопасности для криптографических модулей в продуктах и системах ит-технологий. Соответствие FIPS обеспечивает использование проверенных криптографических модулей для шифрования, хэширования и других операций, связанных с безопасностью.

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

Использование собственного ключа (BYOK - Bring Your Own Key) для дисков Azure

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

• BYOK для управляемых дисков Azure в AKS
• Шифрование управляемых дисков Azure на стороне сервера

Шифрование на основе узла

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

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

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

• шифрование на основе узла в AKS
• BYOK с дисками Azure в AKS
• Шифрование управляемых дисков Azure на стороне сервера

Нетворкинг

В следующих разделах описаны рекомендации по работе с сетями для мультитенантных решений AKS.

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

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

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

Используйте Azure CNI Standard для мультитенантных сценариев в следующих случаях:

• Внешние системы нуждаются в прямом маршрутизируемом доступе к IP-адресам подов (что редко встречается у большинства шаблонов многопользовательских SaaS).

• Вы используете расширенные функции AKS, которые не поддерживают режим наложения.

• Виртуальная сеть имеет достаточное пространство IP-адресов, и у вас есть небольшое количество кластеров арендаторов.

Используйте наложение Azure CNI для мультитенантных сценариев в следующих случаях:

• Вы развертываете несколько выделенных кластеров (по одному на клиента или на категорию клиента).

• Развертывание нескольких кластеров AKS в одной виртуальной сети (обычно для моделей одного кластера на клиента или для модели раздельных уровней).

• В общих кластерах с большим количеством многопользовательских пространств имен используется высокая плотность pod.

• Вы развертываете несколько сред (разработка, тестирование, продакшн) для каждого арендатора.

• Пространство IP-адресов ограничено или необходимо зарезервировать IP-адреса виртуальной сети для других ресурсов Azure.

• Необходимо стандартизировать шаблоны инфраструктуры во многих развертываниях клиента.

При развертывании модели автоматического развертывания с одним клиентом (выделенного кластера для каждого клиента) Azure CNI Overlay позволяет повторно использовать один и тот же модуль CIDR pod (например, 10.244.0.0/16) в нескольких кластерах клиентов. Этот подход устраняет необходимость планирования, выделения и отслеживания уникальных идентификаторов CIDR pod для каждого клиента. Вы можете стандартизировать шаблоны IaC во всех клиентах. Подключение арендатора происходит быстрее, потому что вам не нужно координировать назначения CIDR. Эта согласованная конфигурация также упрощает устранение неполадок и уменьшает ошибки конфигурации.

Наложение Azure CNI обеспечивает ту же изоляцию клиента, что и Azure CNI Standard. Обе топологии поддерживают все три подсистемы сетевой политики: политики сети Azure, Calico и Azure CNI с помощью Cilium. Вы можете применить сетевую изоляцию на уровне пространства имен между клиентами с помощью любого варианта.

Azure CNI Overlay использует преобразование сетевых адресов источника (SNAT) для преобразования IP-адресов pod клиента в IP-адрес узла при выходе трафика из кластера. Если необходимо определить трафик по клиенту для внешних систем или правил брандмауэра, используйте следующие методы для реализации элементов управления исходящего трафика для конкретного клиента:

• Создайте выделенные пулы узлов для каждого клиента и используйте определенные метки узлов.

• Разверните шлюз Azure NAT, который использует несколько общедоступных IP-адресов и назначьте разные IP-адреса разным пулам узлов.

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

Дополнительные сведения см. в статье "Настройка сети наложения Azure CNI" в AKS.

Ограничение сетевого доступа к серверу API

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

Частные кластеры AKS

Частный кластер AKS сохраняет сетевой трафик между сервером API и пулами узлов в виртуальной сети. AKS предоставляет два подхода для доступа к частному серверу API:

• Интеграция виртуальной сети API-сервера: Этот подход проектирует конечную точку сервера API в делегированную подсеть виртуальной сети кластера. Сервер API использует внутреннюю подсистему балансировки нагрузки. Узлы напрямую взаимодействуют с частным IP-адресом сервера API. Вы можете разрешить или заблокировать доступ к общедоступной сети без повторного развертывания кластера.

• Частные кластеры с приватным каналом Azure: Этот подход использует приватный канал для создания частной конечной точки без общедоступного IP-адреса. Доступ к серверу API осуществляется только через частную конечную точку. Необходимо настроить систему доменных имен (DNS) через частные зоны DNS.

  Частный кластер AKS ограничивает доступ уровня управления к ресурсам в той же виртуальной сети или через пиринг виртуальной сети, виртуальную частную сеть или Azure ExpressRoute. Дополнительные сведения см. в статье Создание частного кластера AKS.

Диапазоны авторизованных IP-адресов

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

Интеграция приватного канала

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

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

Дополнительные сведения см. в статье «Многотенантность и Private Link».

Обратные прокси-серверы

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

• Контроллер входящего трафика NGINX — это обратный прокси-сервер, поддерживающий балансировку нагрузки, завершение SSL и маршрутизацию уровня 7. Проект Ingress NGINX уходит в отставку в марте 2026 года.

• Поставщик входящего трафика Traefik Kubernetes — это контроллер входящего трафика Kubernetes , который управляет доступом к службам кластеров, поддерживая спецификацию входящего трафика.

• Контроллер входящего трафика HAProxy Kubernetes — это обратный прокси-сервер для Kubernetes, который поддерживает завершение протокола TLS, маршрутизацию на основе URL-адресов и другие стандартные функции.

• Шлюз приложений для контейнеров — это контроллер доставки управляемых приложений (ADC), обеспечивающий балансировку нагрузки уровня 7 для размещенных приложений AKS. Он предоставляет расширенные возможности маршрутизации, завершение SSL и функции брандмауэра веб-приложений (WAF) для защиты приложений клиента от распространенных веб-уязвимостей и атак. Шлюз приложений для контейнеров заменяет AGIC. Используйте шлюз приложений для контейнеров для новых развертываний. Вы можете использовать существующие развертывания AGIC, но следует запланировать миграцию в шлюз приложений для контейнеров.

При использовании обратного прокси-сервера с размещением AKS для защиты и обработки входящих запросов к нескольким приложениям клиента рассмотрите следующие рекомендации:

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

• Настройте пул узлов, на котором размещен обратный прокси-сервер для автомасштабирования.

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

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

При использовании шлюза приложений для контейнеров рассмотрите следующие рекомендации.

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

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

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

Интеграция с Azure Front Door

Azure Front Door — это глобальная подсистема балансировки нагрузки уровня 7 и сеть доставки облачного содержимого, которая обеспечивает доступ между пользователями и веб-приложениями. Используйте такие функции Azure Front Door, как ускорение запросов, завершение SSL, кэширование ответов, WAF на границе, маршрутизация на основе URL-адресов, перезапись и перенаправления при предоставлении мультитенантных приложений AKS в общедоступном Интернете.

Например, используйте Azure Front Door для управления несколькими пользовательскими доменами, по одному для каждого клиента и маршрутизации всего трафика в мультитенантное приложение AKS, настроенное с одним именем узла. Вы можете завершить SSL-подключения на границе перед маршрутизацией трафика в серверное приложение.

Настройте Azure Front Door, чтобы изменить заголовок узла источника запроса , чтобы он соответствовал доменному имени внутреннего приложения. Azure Front Door распространяет исходный Host заголовок через X-Forwarded-Host заголовок, который многопользовательский код приложения может использовать для сопоставления входящего запроса с правильным клиентом.

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

Настройте Azure Front Door Premium для частного подключения к клиентским приложениям, работающим в кластере AKS через внутреннюю подсистему балансировки нагрузки с помощью приватного канала. Дополнительные сведения см. в статье "Подключение Azure Front Door Premium" к внутреннему источнику подсистемы балансировки нагрузки через приватный канал.

Исходящие подключения

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

• Azure Load Balancer: AKS создает стандартный балансировщик нагрузки типа Standard SKU для управления исходящим трафиком по умолчанию. Но конфигурация по умолчанию может не соответствовать всем требованиям сценария, если общедоступные IP-адреса запрещены или если для исходящего трафика требуются дополнительные прыжки. Общедоступная подсистема балансировки нагрузки создается с общедоступным IP-адресом по умолчанию, который использует правила исходящего трафика . Правила исходящего трафика можно использовать, чтобы явно задать SNAT для публичного стандартного балансировщика нагрузки. Эта конфигурация позволяет использовать общедоступные IP-адреса подсистемы балансировки нагрузки для обеспечения исходящего подключения к Интернету для внутренних экземпляров. Чтобы избежать исчерпания портов SNAT, настройте правила исходящего трафика общедоступной подсистемы балансировки нагрузки, чтобы использовать более общедоступные IP-адреса.

  Дополнительные сведения см. в разделе Использование внешнего IP-адреса подсистемы балансировки нагрузки для исходящего трафика через правила исходящего трафика.

• Шлюз Azure NAT: Настройте кластер AKS для маршрутизации исходящего трафика из приложений клиента с помощью шлюза NAT Azure. Шлюз NAT Azure поддерживает до 64 512 исходящих потоков трафика протоколов UDP и ТСР на один общедоступный IP-адрес, с максимум 16 IP-адресами. Чтобы избежать нехватки портов SNAT при использовании шлюза Azure NAT для обработки исходящих подключений из кластера AKS, свяжите более общедоступные IP-адреса или префикс общедоступного IP-адреса с шлюзом.

  Дополнительные сведения см. в статье рекомендации по использованию шлюза NAT Azure для многотенантности.

• UDR: Настройте исходящий маршрут кластера AKS для поддержки пользовательских сетевых сценариев, таких как сценарии, которые запрещают общедоступные IP-адреса и требуют, чтобы кластер сидел за сетевым виртуальным устройством (NVA). При настройке кластера для UDR AKS не настраивает пути исходящего трафика автоматически. Необходимо настроить пути исходящего трафика. Например, маршрутизация исходящего трафика через брандмауэр Azure.

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

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

Контроль

Мониторинг кластеров Kubernetes с помощью Azure Monitor и облачных средств для наблюдения за работоспособностью и производительностью кластеров AKS и рабочих нагрузок клиента. Azure Monitor собирает журналы и метрики, анализ телеметрии и оповещения для упреждающего обнаружения проблем. Используйте Azure Managed Grafana для визуализации этих данных.

Costs

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

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

• Выделенный кластер: Если кластер предназначен для одного клиента, легко взимать расходы на ресурсы Azure обратно клиенту. Общая стоимость владения (TCO) зависит от многих факторов, включая количество и размер виртуальных машин, затраты на сетевой трафик, общедоступные IP-адреса, подсистемы балансировки нагрузки и службы хранения, используемые решением клиента, например управляемые диски или файлы Azure. Пометьте кластер AKS и его ресурсы в группе ресурсов узлов, для упрощения распределения затрат. Дополнительные сведения см. в разделе Добавление тегов в кластер.

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

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

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

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

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

• Управление затратами с помощью Kubecost
• Архитектурные подходы для управления затратами и их распределения в мультитенантном решении
• Общие сведения о основной части оптимизации затрат

Управление

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

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

Соавторы

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

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

• Паоло Сальватори

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

• Богдан Черчик | Старший инженер клиента
• Сэм Коган | Старший архитектор облачных решений
• Джон Даунс | Главный инженер по программному обеспечению — шаблоны и методики Azure
• Бен Гриффин | Старший архитектор решений для партнеров
• Чад Киттель | Главный инженер по программному обеспечению — шаблоны и методики Azure
• Арсен Владимирский | Главный инженер клиента

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

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

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