Изменить

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

Рекомендации по многотенантности службы Azure Kubernetes (AKS)

Azure
Служба Azure Kubernetes (AKS)

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

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

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

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

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

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

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

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

В этом сценарии члены команд часто имеют прямой доступ к ресурсам Kubernetes с помощью таких средств, как kubectl. Кроме того, члены имеют косвенный доступ через контроллеры GitOps, такие как Flux и Argo CDили с помощью других типов средств автоматизации выпуска.

Дополнительные сведения об этом сценарии см. в нескольких команд в документации Kubernetes.

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

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

Дополнительные сведения об этом сценарии см. в нескольких клиентов в документации Kubernetes.

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

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

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

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

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

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

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

  • Гроздь
  • Пространство имен
  • Пул узлов или узел
  • Стручок
  • Контейнер

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

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

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

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

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

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

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

  • Пространства имен позволяют различным рабочим нагрузкам клиента существовать в своей виртуальной рабочей области без риска влияния друг на друга. Отдельные команды в организации могут использовать пространства имен для изоляции своих проектов друг от друга, так как они могут использовать одинаковые имена ресурсов в разных пространствах имен без риска перекрытия имен.
  • роли RBAC и привязки ролей — это ресурсы с областями имен, которые команды могут использовать для ограничения пользователей и процессов клиента для доступа к ресурсам и службам только в своих пространствах имен. Разные команды могут определять роли для группирования списков разрешений или возможностей под одним именем. Затем они назначают эти роли учетным записям пользователей и учетным записям служб, чтобы обеспечить доступ только авторизованным удостоверениям к ресурсам в заданном пространстве имен.
  • квоты ресурсов для ЦП и памяти являются объектами пространства имен. Teams может использовать их для обеспечения того, чтобы рабочие нагрузки, совместно использующие один и тот же кластер, строго изолированы от использования системных ресурсов. Этот метод может гарантировать, что каждое приложение клиента, которое выполняется в отдельном пространстве имен, имеет ресурсы, необходимые для выполнения и избегая шумных проблем соседей, которые могут повлиять на другие приложения клиента, которые используют один и тот же кластер.
  • политики сети — это объекты пространства имен, которые команды могут применять для применения сетевого трафика для данного приложения клиента. Политики сети можно использовать для разделения отдельных рабочих нагрузок, которые совместно используют один и тот же кластер с точки зрения сети.
  • Командные приложения, работающие в разных пространствах имен, могут использовать разные учетные записи службы для доступа к ресурсам в одном кластере, внешних приложениях или управляемых службах.
  • Используйте пространства имен для повышения производительности на уровне уровня управления. Если рабочие нагрузки в общем кластере организованы в несколько пространств имен, API Kubernetes имеет меньше элементов для поиска при выполнении операций. Эта организация может снизить задержку вызовов к серверу API и увеличить пропускную способность плоскости управления.

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

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

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

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

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

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

  • Azure реализует политики сети, называемые политиками сети Azure.
  • политики сети Calico — это решение с открытым исходным кодом и безопасность сети, основанное Tigera.

Обе реализации используют iptables Linux для применения указанных политик. Политики сети превратятся в наборы разрешенных и запрещенных пар IP-адресов. Затем эти пары запрограммируются как правила фильтрации iptable. Политики сети Azure можно использовать только с кластерами AKS, настроенными с помощью подключаемого модуля сети Azure CNI. Однако политики сети Calico поддерживают как Azure CNI, так и kubenet. Дополнительные сведения см. в статье Безопасный трафик между модулями pod с помощью политик сети в службе Azure Kubernetes.

Дополнительные сведения см. в сетевой изоляции в документации Kubernetes.

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительные сведения см. в изоляции узла в документации По Kubernetes.

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

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

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

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

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

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

преимущества :

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

риски :

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

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

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

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

преимущества:

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

риски:

  • В этом контексте одно приложение обрабатывает все запросы клиентов. Необходимо разработать и реализовать меры безопасности, чтобы предотвратить наводнение приложения клиентами с помощью вызовов. Эти вызовы могут замедлить работу всей системы и повлиять на всех клиентов.
  • Если профиль трафика является высокой переменной, необходимо настроить автомасштабирование кластера AKS, чтобы изменить количество модулей pod и узлов агента. Настройка зависит от использования системных ресурсов, таких как ЦП и память. Кроме того, можно масштабировать и масштабировать количество модулей pod и узлов кластера на основе пользовательских метрик. Например, можно использовать количество ожидающих запросов или метрик внешней системы обмена сообщениями, которая использует автомасштабирование на основе Kubernetes (KEDA).
  • Убедитесь, что вы отделяете данные для каждого клиента и реализуете меры безопасности, чтобы избежать утечки данных между разными клиентами.
  • Убедитесь, что отслеживать и связывать затраты Azure с отдельными клиентами на основе фактического использования. Решения, отличные от Майкрософт, такие как kubecost, помогают вычислить и разбить затраты на разные команды и арендаторы.
  • Обслуживание может быть более простым с одним развертыванием, так как вам нужно обновить только один набор ресурсов Azure и поддерживать одно приложение. Однако это также может быть более рискованным, так как любые изменения в инфраструктуре или компонентах приложений могут повлиять на всю клиентскую базу.
  • Кроме того, следует учитывать ограничения масштабирования. Скорее всего, вы достигнете ограничений масштаба ресурсов Azure, если у вас есть общий набор ресурсов. Чтобы избежать достижения предельной квоты ресурсов, вы можете распределить клиентов между несколькими подписками Azure.

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

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

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

преимущества :

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

риски :

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

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

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

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

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

  • Базовый уровень. Запросы клиента обслуживаются одним мультитенантным приложением Kubernetes, совместно используемым с другими клиентами. Данные хранятся в одной или нескольких базах данных, к которым совместно используются все клиенты уровня "Базовый".
  • Стандартный уровень: запросы клиентов обслуживаются выделенным приложением Kubernetes, которое выполняется в отдельном пространстве имен, что обеспечивает границы изоляции с точки зрения безопасности, сети и потребления ресурсов. Все приложения клиентов, по одному для каждого клиента, совместно используют один кластер AKS и пул узлов с другими клиентами уровня "Стандартный".
  • Уровень "Премиум": приложение клиента выполняется в выделенном пуле узлов или кластере AKS для обеспечения более высокого уровня обслуживания, повышения производительности и более высокой степени изоляции. Этот уровень может предоставить гибкую модель затрат на основе числа и номера SKU узлов агента, в которых размещается приложение клиента. Вы можете использовать песочницу Pod в качестве альтернативного решения выделенным кластерам или пулам узлов для изоляции отдельных рабочих нагрузок клиента.

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

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

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

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

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

преимущества :

  • Так как вы по-прежнему предоставляете общий доступ к инфраструктуре, вы по-прежнему можете получить некоторые преимущества затрат на наличие общих мультитенантных развертываний. Вы можете развернуть кластеры и пулы узлов, которые совместно используются в нескольких приложениях клиента уровня "базовый" и "Стандартный", которые используют менее дорогой размер виртуальной машины для узлов агента. Такой подход гарантирует лучшую плотность и экономию затрат. Для клиентов уровня "Премиум" можно развертывать кластеры и пулы узлов AKS с более высоким размером виртуальной машины и максимальным количеством реплик и узлов pod по более высокой цене.
  • Системные службы, такие как CoreDNS, Konnectivityили контроллера входящего трафика шлюза приложений Azure,в выделенном пуле узлов в режиме системы. Вы можете использовать селекторов, толерантности, меток узлов, селекторов узлови сопоставления узлов для запуска приложения клиента в одном или нескольких пулах узлов в пользовательском режиме.
  • Для запуска общих ресурсов можно использовать , толерации, метки узлов, селекторы узлови сходство узлов. Например, у вас может быть контроллер входящего трафика или система обмена сообщениями в выделенном пуле узлов с определенным размером виртуальной машины, параметрами автомасштабирования и поддержкой зон доступности.

риски :

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

Автомасштабирование

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

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

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

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

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

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

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

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

Содержание

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

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

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

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

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

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

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

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

Рабочие нагрузки клиента, развернутые в кластерах AKS, могут использовать учетные данные приложения Microsoft Entra для доступа к ресурсам, защищенным идентификаторами Майкрософт, например Azure Key Vault и Microsoft Graph. идентификатор рабочей нагрузки Microsoft Entra для Kubernetes интегрируется с собственными возможностями Kubernetes для федерации с любыми внешними поставщиками удостоверений.

Песочница Pod

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

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

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

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

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

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

Существует несколько преимуществ использования выделенного узла Azure с AKS, в том числе:

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

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

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

Карпентер

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

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

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

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

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

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

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

Использование собственных ключей (BYOK) с дисками Azure

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

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

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

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

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

Сети

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

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

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

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

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

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

Второй вариант повышения безопасности кластера и минимизации атак заключается в использовании авторизованных диапазонов IP-адресов. Этот подход ограничивает доступ к плоскости управления общедоступного кластера AKS хорошо известному списку IP-адресов и диапазонов маршрутизации Inter-Domain маршрутизации (CIDR). При использовании авторизованных IP-адресов они по-прежнему открыты, но доступ ограничен набором диапазонов. Дополнительные сведения см. в разделе Безопасный доступ к серверу API с помощью авторизованных диапазонов IP-адресов вAKS.

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

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

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

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

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

  • контроллер входящего трафика NGINX является популярным обратным прокси-сервером, поддерживающим расширенные функции, такие как балансировка нагрузки, завершение SSL и маршрутизация уровня 7.
  • поставщик входящего трафика Traefik Kubernetes Ingress — это контроллер входящего трафика Kubernetes, который можно использовать для управления доступом к службам кластеров, поддерживая спецификацию входящего трафика.
  • контроллер входящего трафика HAProxy Kubernetes является еще одним обратным прокси-сервером Для Kubernetes, который поддерживает стандартные функции, такие как завершение TLS, маршрутизация на основе URL-адресов и многое другое.
  • контроллер входящего трафика шлюза приложений Azure (AGIC) — это приложение Kubernetes, что позволяет клиентам AKS использовать собственный шлюз приложений Azure шлюз приложений L7 для предоставления приложений клиента общедоступному Интернету или внутренним системам, работающим в виртуальной сети.

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

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

При использовании контроллера входящего трафика шлюза приложений Azure (AGIC) рекомендуется реализовать следующие рекомендации.

  • Настройте шлюз приложений , который контроллер входящего трафика использует для автомасштабирования. С включенным автомасштабированием шлюз приложений и брандмауэр веб-приложений (WAF) версии 2 SKU масштабируются или в зависимости от требований к трафику приложений. Этот режим обеспечивает лучшую эластичность приложения и устраняет необходимость угадать размер шлюза приложений или количество экземпляров. Этот режим также помогает сэкономить на затратах, не требуя, чтобы шлюз выполнялся в пиковой подготовленной емкости для ожидаемой максимальной нагрузки трафика. Необходимо указать минимальное (и необязательно максимальное) число экземпляров.
  • Рассмотрите возможность развертывания нескольких экземпляров AGIC, каждый из которых связан с отдельным шлюзом приложений , если число приложений клиента превышает максимальное количество сайтов. При условии, что каждое приложение клиента выполняется в выделенном пространстве имен, используйте поддержке нескольких пространств имен для распространения приложений клиента по нескольким экземплярам AGIC.

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

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

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

схема, демонстрирующая подключение Azure Front Door и AKS.

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

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

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

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

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

  • Azure Load Balancer. По умолчанию AKS подготавливает подсистему балансировки нагрузки SKU уровня "Стандартный" и используется для подключений исходящего трафика. Однако настройка по умолчанию может не соответствовать требованиям всех сценариев, если общедоступные IP-адреса запрещены или если для исходящего трафика требуются дополнительные прыжки. По умолчанию общедоступная подсистема балансировки нагрузки создается с общедоступным IP-адресом по умолчанию, который правила исходящего трафика использовать. Правила исходящего трафика позволяют явно определить SNAT для общедоступной подсистемы балансировки нагрузки уровня "Стандартный". Эта конфигурация позволяет использовать общедоступные IP-адреса подсистемы балансировки нагрузки для обеспечения исходящего подключения к Интернету для внутренних экземпляров. Чтобы избежать исчерпания портов SNAT, можно настроить правила исходящего трафика общедоступной подсистемы балансировки нагрузки для использования более общедоступных IP-адресов. Дополнительные сведения см. в разделе Использование внешнего IP-адреса подсистемы балансировки нагрузки для исходящего трафика через правила исходящего трафика.
  • шлюза Azure NAT. Вы можете настроить кластер AKS для маршрутизации исходящего трафика из приложений клиента с помощью шлюза Azure NAT. Шлюз NAT позволяет выполнять до 64 512 исходящих потоков UDP и TCP-трафика на общедоступный IP-адрес, не более 16 IP-адресов. Чтобы избежать риска исчерпания портов SNAT при использовании шлюза NAT для обработки исходящих подключений из кластера AKS, можно связать более общедоступные IP-адреса или префикс общедоступного IP-адреса шлюзу. Дополнительные сведения см. в статье рекомендации по использованию шлюза NAT Azure для многотенантности.
  • определяемый пользователем маршрут (UDR). Вы можете настроить исходящий маршрут кластера AKS для поддержки пользовательских сетевых сценариев, таких как те, которые запрещают общедоступные IP-адреса и требуют, чтобы кластер сидел за сетевым виртуальным устройством (NVA). При настройке кластера для определяемой пользователем маршрутизацииAKS не настраивает пути исходящего трафика автоматически. Необходимо завершить настройку исходящего трафика. Например, вы направляете исходящий трафик через брандмауэра Azure. Необходимо развернуть кластер AKS в существующей виртуальной сети с подсетью, настроенной ранее. Если вы не используете стандартную архитектуру подсистемы балансировки нагрузки, необходимо установить явный исходящий трафик. Таким образом, эта архитектура требует явной отправки исходящего трафика на устройство, например брандмауэра, шлюза или прокси-сервера. Кроме того, архитектура позволяет выполнять преобразование сетевых адресов (NAT) общедоступным IP-адресом, назначенным стандартной подсистеме балансировки нагрузки или устройству.

Контроль

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

Вы также можете использовать средства с открытым кодом, такие как Prometheus и Grafana, которые широко используются для мониторинга Kubernetes. Кроме того, вы можете использовать другие средства, отличные от Майкрософт, для мониторинга и наблюдения.

Издержки

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

  • Полностью мультитенантный: если одно мультитенантное приложение обслуживает все запросы клиента, это ваша ответственность за отслеживание потребления ресурсов и количество запросов, создаваемых каждым клиентом. Затем вы взимаете плату за ваших клиентов соответствующим образом.
  • Выделенный кластер: если кластер выделен для одного клиента, легко взимать расходы на ресурсы Azure обратно клиенту. Общая стоимость владения зависит от многих факторов, включая количество и размер виртуальных машин, сетевые затраты на сетевой трафик, общедоступные IP-адреса, подсистемы балансировки нагрузки и службы хранения, такие как управляемые диски или файлы Azure, используемые решением клиента. Кластер AKS и его ресурсы можно пометить в группе ресурсов узла, чтобы упростить операции с зарядкой затрат. Дополнительные сведения см. в разделе Добавление тегов в кластер.
  • Выделенный пул узлов. Вы можете применить тег Azure к новому или существующему пулу узлов, выделенному для одного клиента. Теги применяются к каждому узлу в пуле узлов и сохраняются с помощью обновлений. Теги также применяются к новым узлам, которые добавляются в пул узлов во время операций горизонтального масштабирования. Добавление тега может помочь в таких задачах, как отслеживание политик или плата за затраты. Дополнительные сведения см. в статье Добавление тегов в пулы узлов.
  • Другие ресурсы: теги можно использовать для связывания затрат на выделенные ресурсы с заданным клиентом. В частности, можно пометить общедоступные IP-адреса, файлы и диски с помощью манифеста Kubernetes. Теги, заданные таким образом, поддерживают значения Kubernetes, даже если вы обновляете их позже с помощью другого метода. Когда общедоступные IP-адреса, файлы или диски удаляются через Kubernetes, все теги, которые наборы Kubernetes удаляются. Теги ресурсов, которые Kubernetes не отслеживает, остаются не затронутыми. Дополнительные сведения см. в разделе Добавление тегов с помощью kubernetes.

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

Дополнительные сведения об измерении, выделении и оптимизации затрат для мультитенантного приложения см. в разделе Архитектурные подходы к управлению затратами и выделению в мультитенантном решении. Общие рекомендации по оптимизации затрат см. в статье azure Well-Architected Framework, обзорпо оптимизации затрат.

Управление

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

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

Участников

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

Автор субъекта:

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