Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
При управлении кластерами в службе Azure Kubernetes (AKS) часто необходимо изолировать команды и рабочие нагрузки. AKS позволяет гибко управлять многопользовательскими кластерами и изолировать ресурсы. Чтобы повысить ценность своих инвестиций в Kubernetes, важно понимать функции многотенантности и изоляции AKS.
В этой статье рассматриваются рекомендации по изоляции для операторов кластера. В этой статье вы узнаете, как:
- Планирование многоарендных кластеров и разделение ресурсов.
- Используйте логическую или физическую изоляцию в кластерах AKS.
Проектирование кластеров под многопользовательскую среду
Kubernetes позволяет логически изолировать команды и рабочие нагрузки в одном кластере. Цель состоит в том, чтобы обеспечить наименьшее количество привилегий, ограниченных для ресурсов, необходимых каждой команде. Пространство имен Kubernetes создает логическую границу изоляции. Другие функции Kubernetes и рекомендации по изоляции и многотенантности включают следующие области:
Планирование
планирование использует базовые функции, такие как квоты ресурсов и бюджеты сбоев pod. Дополнительные сведения об этих функциях см. в рекомендациях по основным функциям планировщика в AKS.
Ниже приведены более сложные функции планировщика:
- Таинты и допуски.
- Селекторы узлов.
- Сходства и антисходства узлов и модулей.
Дополнительные сведения об этих функциях см. в рекомендациях по расширенным функциям планировщика в AKS.
Сетевые технологии
Сетевые взаимодействия используют политики сети для управления потоком входящего и исходящего трафика в подах.
Для получения более подробной информации см. Защита трафика между подсистемами с использованием сетевых политик в Azure Kubernetes Services (AKS).
Проверка подлинности и авторизация
Используется проверка подлинности и авторизация :
- Управление доступом на основе ролей (RBAC).
- Интеграция Microsoft Entra.
- Идентичности Pod.
- Секреты в Azure Key Vault.
Дополнительные сведения об этих функциях см. в рекомендациях по проверке подлинности и авторизации в AKS.
Контейнеры
Контейнеры включают:
- Дополнение Azure Policy для AKS, обеспечивающее безопасность Pod.
- Контроль безопасности Pod.
- Сканирование образов и времени выполнения на наличие уязвимостей.
- Использование App Armor или Seccomp (Secure Computing) для ограничения доступа контейнера к базовому узлу.
Логически изолированные кластеры
Руководство по передовым практикам
Разделите команды и проекты с помощью логической изоляции. Свести к минимуму количество физических кластеров AKS, которые развертываются для изоляции команд или приложений.
С логической изоляцией можно использовать один кластер AKS для нескольких рабочих нагрузок, команд или сред. Пространства имен Kubernetes образуют границу логической изоляции для рабочих нагрузок и ресурсов.
Логическое разделение кластеров обычно обеспечивает более высокую плотность pod по сравнению с физически изолированными кластерами, при этом в кластере остается меньше избыточной вычислительной мощности в режиме простоя. В сочетании с автомасштабированием кластера Kubernetes можно масштабировать количество узлов вверх или вниз до удовлетворения требований. Этот подход лучших практик позволяет свести к минимуму затраты, поддерживая только необходимое количество узлов.
Среды Kubernetes не являются полностью безопасными для враждебного использования нескольких клиентов. В мульти-тенантной среде несколько арендаторов работают на общей инфраструктуре. Если нельзя доверять всем арендаторам, необходимо дополнительное планирование, чтобы предотвратить влияние арендаторов на безопасность и обслуживание других.
Другие функции безопасности, такие как Kubernetes RBAC для узлов, эффективно блокируют эксплойты. Для обеспечения настоящей безопасности при выполнении враждебных многопользовательских рабочих нагрузок необходимо доверять только гипервизору. Домен безопасности для Kubernetes становится всем кластером, а не отдельным узлом.
Для таких типов враждебных многотенантных рабочих нагрузок следует использовать физически изолированные кластеры.
Физически изолированные кластеры
Руководство по передовым практикам
Сведите к минимуму использование физической изоляции для каждой отдельной команды или развертывания приложений и используйте логическую изоляцию.
Физическое разделение кластеров AKS является распространенным подходом к изоляции кластера. В этой модели изоляции команды или рабочие нагрузки получают свой кластер AKS. Хотя физическая изоляция может выглядеть как самый простой способ изоляции рабочих нагрузок или команд, он добавляет управление и финансовые издержки. При использовании физически изолированных кластеров необходимо поддерживать несколько кластеров и отдельно предоставлять доступ и назначать разрешения. За каждый отдельный узел также взимается плата.
Физически изолированные кластеры обычно имеют низкую плотность подов. Так как каждая команда или рабочая нагрузка имеет собственный кластер AKS, кластер часто переполнен вычислительными ресурсами. Часто на этих узлах запланировано несколько модулей pod. Неиспользуемую емкость узла нельзя использовать для приложений или служб, разрабатываемых другими командами. Эти избыточные ресурсы способствуют дополнительным затратам в физически изолированных кластерах.
Дальнейшие действия
Эта статья посвящена изоляции кластера. Дополнительные сведения об операциях кластера в AKS см. в следующих статьях: