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

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

Кластеры 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 должны изолировать клиентов друг от друга. Эта изоляция сводит к минимуму ущерб, который скомпрометированный или вредоносный клиент может сделать кластеру и другим клиентам.

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

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

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

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

• Кластер
• Пространство имен
• Пул узлов или узел
• Объект pod
• Контейнер

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

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

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

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

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

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

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

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

• Пространства имен
• Элементы управления доступом
• Квоты

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

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

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

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

Служба Azure Kubernetes (AKS) предоставляет два способа реализации политик сети:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Служба Azure 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 связана с определенными компонентами, которые можно развернуть отдельно для каждого клиента. Например, базы данных могут поглощать большую часть нагрузки системы, так как нагрузка запроса высока. Если один клиент отправляет в решение большое количество запросов, производительность базы данных может негативно повлиять на производительность базы данных, но другие базы данных клиентов (и общие компоненты, такие как уровень приложений), остаются не затронутыми.

Риски:

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

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

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

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

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

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

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

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

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

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

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

Риски:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Access and identity options for Azure Kubernetes Service (AKS) (Возможности контроля доступа и идентификации в Службе Azure Kubernetes (AKS))
• Интеграция Microsoft Entra с управляемым AKS
• Управление доступом к ресурсам кластера с помощью управления доступом на основе ролей Kubernetes и удостоверений Microsoft Entra в Служба Azure Kubernetes

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

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

Рабочие нагрузки клиента, развернутые в кластерах AKS, могут использовать учетные данные приложения Microsoft Entra для доступа к ресурсам, защищенным идентификатором Microsoft, например 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, работающих на узле контейнера Linux Для AKS для обеспечения аппаратной изоляции. Контейнеры Kata в AKS основаны на гипервизоре Azure, защищенном безопасностью. Изоляция для каждого модуля pod достигается с помощью вложенной упрощенной виртуальной машины Kata, которая использует ресурсы из родительского узла виртуальной машины. В этой модели каждый pod Kata получает собственное ядро в вложенной гостевой виртуальной машине Kata. Эта модель позволяет разместить множество контейнеров Kata на одной гостевой виртуальной машине, продолжая запускать контейнеры на родительской виртуальной машине. Модель предоставляет строгой границу изоляции в общем кластере AKS.

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

• Песочница Pod с Служба Azure Kubernetes (AKS)
• Поддержка изолированных контейнеров виртуальной машины Kata в AKS для песочницы Pod

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

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

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

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

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

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

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

Вы можете использовать конфиденциальные Виртуальные машины (CVM) для добавления одного или нескольких пулов узлов в кластер AKS для решения строгих требований к изоляции, конфиденциальности и безопасности клиентов. CVM используют надежную среду выполнения на основе оборудования (TEE). Безопасная зашифрованная виртуализация AMD — безопасная вложенная разбиение на страницы (SEV-SNP) запрещает гипервизор и другой код управления узлами к памяти и состоянию виртуальной машины, добавляя уровень глубокой защиты от доступа к операторам. Дополнительные сведения см. в разделе "Использование CVMs в кластере AKS".

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

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

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

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

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

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

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

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

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

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

Сеть

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

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

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

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

Авторизованные IP-адреса

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

интеграция Приватный канал

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

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

Общие рекомендации по настройке Приватный канал для размещенного в Azure мультитенантного решения см. в разделе "Многотенантность" и Приватный канал Azure.

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

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

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

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

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

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

• Настройте Шлюз приложений, которая используется контроллером входящего трафика для автомасштабирования. С включенным автомасштабированием Шлюз приложений и SKU WAF версии 2 масштабируются или в зависимости от требований к трафику приложения. Этот режим обеспечивает большую гибкость в отношении приложений и исключает необходимость угадывания размера шлюза приложений или числа экземпляров. Этот режим также позволяет сэкономить затраты, не требуя, чтобы шлюз выполнялся в пиковой подготовленной емкости для ожидаемой максимальной нагрузки трафика. Необходимо указать минимальное (и необязательно максимальное) число экземпляров.
• Рассмотрите возможность развертывания нескольких экземпляров контроллера входящего трафика Шлюз приложений (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 для изменения заголовка узла источника запроса в соответствии с доменным именем серверного приложения. Исходный Host заголовок, отправленный клиентом, распространяется через X-Forwarded-Host заголовок, и код мультитенантного приложения может использовать эти сведения для сопоставления входящего запроса с правильным клиентом.

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

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

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

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

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

Наблюдение

Azure Monitor и Container Insights можно использовать для мониторинга приложений клиентов, работающих в общем кластере AKS, а также для вычисления разбивки затрат на отдельные пространства имен. Azure Monitor позволяет отслеживать работоспособность и производительность Служба Azure Kubernetes (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, обзор основы оптимизации затрат

Соавторы

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

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

• Паоло Сальватори | Главный инженер клиента, FastTrack для Azure

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

• Джон Даунс | Главный инженер клиента, FastTrack для Azure
• Эд Прайс | Старший диспетчер программ содержимого
• Арсен Владимирский | Главный инженер клиента, FastTrack для Azure
• Богдан Черчик | Старший инженер по работе с клиентами, FastTrack для Azure

Следующие шаги

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