Обзор Azure Well-Architected Framework — Служба Azure Kubernetes (AKS)

  • Статья

В этой статье приведены рекомендации по архитектуре для Служба Azure Kubernetes (AKS). Руководство основано на пяти основных аспектах архитектуры:

  • надежность;
  • Безопасность
  • Оптимизация затрат
  • эффективность работы;
  • оптимизация производительности;

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

Предварительные требования

Понимание основных принципов Well-Architected Framework поможет создать высококачественную, стабильную и эффективную облачную архитектуру. Рекомендуется проверить рабочую нагрузку с помощью оценки azure Well-Architected Framework Review .

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

надежность;

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

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

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

Контрольный список проектирования

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

Рекомендации по настройке AKS

Ознакомьтесь со следующей таблицей рекомендаций по оптимизации конфигурации AKS для обеспечения надежности.

Рекомендация Преимущество
Архитектуры кластеров и рабочих нагрузок: Управление планированием pod с помощью селекторов узлов и сходства. Позволяет планировщику Kubernetes логически ограничивать рабочие нагрузки, например, аппаратно в узле. В отличие от допусков, модули pod без соответствующего селектора узлов можно запланировать на помеченных узлах, что позволяет использовать неиспользуемые ресурсы на узлах, но дает приоритет модулям pod, определяющим соответствующий селектор узлов. Сходство узлов обеспечивает большую гибкость. Это позволяет определить, что произойдет, если модуль не может быть сопоставлен с узлом.
Архитектура кластера. Убедитесь в правильном выборе сетевого подключаемого модуля в зависимости от требований к сети и размера кластера. Azure CNI требуется для конкретных сценариев, например для пулов узлов на основе Windows, конкретных требований к сети и сетевых политик Kubernetes. Дополнительные сведения см. в статье Kubenet и Azure CNI .
Архитектуры кластеров и рабочих нагрузок: Используйте соглашение об уровне обслуживания по времени бесперебойной работы AKS для кластеров производственного уровня. Гарантия соглашения об уровне обслуживания на время доступности AKS:
- Доступность 99.95% конечной точки сервера API Kubernetes для кластеров AKS, использующих Зоны доступности Azure; или
- Доступность 99.9% для кластеров AKS, которые не используют Зоны доступности.
Архитектуры кластеров и рабочих нагрузок: Настройте мониторинг кластера с помощью аналитики контейнеров. Аналитика контейнеров помогает отслеживать работоспособность и производительность контроллеров, узлов и контейнеров, доступных в Kubernetes через API метрик. Интеграция с Prometheus позволяет собирать метрики приложений и рабочих нагрузок.
Архитектура кластера. Используйте зоны доступности для повышения устойчивости в регионе Azure, распределяя узлы агента AKS между физически разными центрами обработки данных. При распространении пулов узлов между несколькими зонами узлы в одном пуле узлов будут продолжать работать, даже если другая зона не работает. Если требования к колокальности существуют, можно использовать обычное развертывание AKS на основе VMSS в одной зоне или группы размещения близкого взаимодействия , чтобы свести к минимуму задержку между узлами.
Архитектура кластера. Применяйте стратегию в нескольких регионах , развертывая кластеры AKS, развернутые в разных регионах Azure, чтобы максимально повысить доступность и обеспечить непрерывность бизнес-процессов. Рабочие нагрузки с выходом в Интернет должны использовать Azure Front Door или диспетчер трафика Azure для глобальной маршрутизации трафика между кластерами AKS.
Архитектуры кластеров и рабочих нагрузок: Определите запросы и ограничения ресурсов pod в манифестах развертывания приложений и применяйте их с помощью Политика Azure. Ограничения ресурсов ЦП и памяти контейнера необходимы для предотвращения нехватки ресурсов в кластере Kubernetes.
Архитектуры кластеров и рабочих нагрузок: Изолируйте пул системных узлов от рабочих нагрузок приложений. Для пулов системных узлов требуется номер SKU виртуальной машины не менее 2 виртуальных ЦП и 4 ГБ памяти, но рекомендуется использовать 4 виртуальных ЦП или более. Сведения о требованиях см. в разделе Пулы системных и пользовательских узлов.
Архитектуры кластеров и рабочих нагрузок: Разделение приложений на выделенные пулы узлов в зависимости от конкретных требований. Приложения могут использовать одну и ту же конфигурацию и нуждаются в виртуальных машинах с поддержкой GPU, ЦП или оптимизированных для памяти виртуальных машинах, а также возможности масштабирования до нуля. Избегайте большого количества пулов узлов, чтобы уменьшить дополнительные затраты на управление.
Архитектура кластера. Используйте шлюз NAT для кластеров, выполняющих рабочие нагрузки, которые выполняют множество одновременных исходящих подключений. Чтобы избежать проблем с надежностью Azure Load Balancer ограничений с большим количеством параллельного исходящего трафика, вместо этого мы создаем шлюз NAT для поддержки надежного исходящего трафика в большом масштабе.

Дополнительные рекомендации см. в разделе Принципы обеспечения надежности.

Политика Azure

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

Архитектура кластера и рабочей нагрузки

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

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

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

Чтобы узнать о поддержке уровня влияния DoD 5 (IL5) и требованиях к AKS, см. Azure для государственных организаций требования к изоляции IL5.

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

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

Контрольный список проектирования

  • Архитектура кластера. Используйте управляемые удостоверения , чтобы избежать управления и смены принципов службы.
  • Архитектура кластера. Используйте управление доступом на основе ролей Kubernetes (RBAC) с Microsoft Entra ID для доступа с минимальными привилегиями и свести к минимуму предоставление прав администратора для защиты конфигурации и доступа к секретам.
  • Архитектура кластера. Используйте Microsoft Defender для контейнеров с Azure Sentinel, чтобы обнаруживать угрозы в кластере и рабочих нагрузках, выполняющихся на них, и быстро реагировать на них.
  • Архитектура кластера. Разверните частный кластер AKS, чтобы обеспечить, чтобы трафик управления кластером на сервер API оставался в частной сети. Или используйте список разрешений сервера API для кластеров, не являющихся частными.
  • Архитектура рабочей нагрузки: Используйте Брандмауэр веб-приложений для защиты трафика HTTP(S).
  • Архитектура рабочей нагрузки: Убедитесь, что конвейер CI/CID защищен с помощью сканирования с учетом контейнеров.

Рекомендации

Ознакомьтесь со следующей таблицей рекомендаций по оптимизации конфигурации AKS для обеспечения безопасности.

Рекомендация Преимущество
Архитектура кластера. Используйте интеграцию Microsoft Entra. Использование Microsoft Entra ID централизации компонента управления удостоверениями. Любые изменения в статусе учетной записи пользователя или группы автоматически обновляются при доступе к кластеру AKS. Разработчикам и владельцам приложений кластера Kubernetes нужен доступ к различным ресурсам.
Архитектура кластера. Проверка подлинности с помощью Microsoft Entra ID для Реестр контейнеров Azure. AKS и Microsoft Entra ID позволяют выполнять проверку подлинности с помощью Реестр контейнеров Azure без использования секретовimagePullSecrets. Дополнительные сведения см. в статье Проверка подлинности с помощью Реестр контейнеров Azure из Служба Azure Kubernetes.
Архитектура кластера. Защита сетевого трафика к серверу API с помощью частного кластера AKS. По умолчанию сетевой трафик между пулами узлов и сервером API проходит через магистральную сеть Майкрософт; С помощью частного кластера можно обеспечить, чтобы сетевой трафик к серверу API оставался только в частной сети.
Архитектура кластера. Для кластеров AKS, не являющихся частными, используйте авторизованные диапазоны IP-адресов сервера API. При использовании общедоступных кластеров вы по-прежнему можете ограничить трафик, который может достигать сервера API кластеров, с помощью функции авторизованного диапазона IP-адресов. Включите такие источники, как общедоступные IP-адреса агентов сборки развертывания, управление операциями и точка исходящего трафика пулов узлов (например, Брандмауэр Azure).
Архитектура кластера. Защитите сервер API с помощью Microsoft Entra RBAC. Обеспечение безопасного доступа к серверу API Kubernetes является одним из самых важных факторов для защиты кластера. Интеграция управления доступом на основе ролей (RBAC) Kubernetes с Microsoft Entra ID для управления доступом к серверу API. Отключите локальные учетные записи, чтобы обеспечить доступ ко всем кластерам с помощью удостоверений на основе Microsoft Entra ID.
Архитектура кластера. Используйте политики сети Azure или Calico. Защита и управление сетевым трафиком между модулями pod в кластере.
Архитектура кластера. Защита кластеров и модулей pod с помощью Политика Azure. Политика Azure может помочь централизованно и согласованно применять меры принудительного применения в большом масштабе к кластерам. Она также может управлять тем, каким функциям назначаются модули pod, и нет ли нарушений политики компании.
Архитектура кластера. Безопасный доступ контейнера к ресурсам. Ограничьте доступ к действиям, которые могут выполнять контейнеры. Укажите наименьшее количество разрешений и избегайте использования корневого доступа или повышения привилегий.
Архитектура рабочей нагрузки: Используйте Брандмауэр веб-приложений для защиты трафика HTTP(S). Чтобы проверить входящий трафик на наличие потенциальных атак, используйте брандмауэр веб-приложения, например Azure Брандмауэр веб-приложений (WAF) на Шлюз приложений Azure или Azure Front Door.
Архитектура кластера. Управление исходящим трафиком кластера. Убедитесь, что исходящий трафик кластера проходит через точку безопасности сети, например Брандмауэр Azure или прокси-сервер HTTP.
Архитектура кластера. Используйте драйвер CSIхранилища секретов и Идентификация рабочей нагрузки Microsoft Entra с открытым кодом с Key Vault Azure. Защита и смена секретов, сертификатов и строк подключения в Azure Key Vault с помощью надежного шифрования. Предоставляет журнал аудита доступа и сохраняет основные секреты из конвейера развертывания.
Архитектура кластера. Используйте Microsoft Defender для контейнеров. Отслеживайте и поддерживайте безопасность кластеров, контейнеров и их приложений.

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

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

Определения политик

Политика Azure предлагает различные встроенные определения политик, которые применяются как к ресурсу Azure, так и к AKS, например стандартные определения политик, а также с использованием надстройки Политика Azure для Kubernetes, также в пределах кластера. Многие политики ресурсов Azure поставляются как в аудите или запрете, так и в варианте Deploy If Not Exists .

Существует множество политик, и здесь приведены основные политики, относящиеся к этому принципу. Более подробное представление см. в разделе Встроенные определения политик для Kubernetes.

Архитектура кластера

  • Microsoft Defender для облачных политик
  • Режим проверки подлинности и политики конфигурации (Microsoft Entra ID, RBAC, отключение локальной проверки подлинности)
  • Политики сетевого доступа сервера API, включая частный кластер

Архитектура кластера и рабочей нагрузки

  • Инициативы по обеспечению безопасности pod кластера Kubernetes для рабочих нагрузок на основе Linux
  • Включите политики возможностей pod и контейнеров, такие как AppArmor, sysctl, ограничения безопасности, SELinux, seccomp, привилегированные контейнеры, учетные данные API кластера автоматического подключения.
  • Политики подключения, драйверов томов и файловой системы
  • Сетевые политики pod или контейнеров, такие как сеть узлов, порт, разрешенные внешние IP-адреса, HTTP и внутренние подсистемы балансировки нагрузки

Служба Azure Kubernetes развертываниях часто используют Реестр контейнеров Azure для диаграмм Helm и образов контейнеров. Реестр контейнеров Azure также поддерживает широкий спектр политик Azure, охватывающих сетевые ограничения, управление доступом и Microsoft Defender для облака, которые дополняют защищенную архитектуру AKS.

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

Дополнительные рекомендации см. в статье Концепции безопасности AKS и ознакомьтесь с нашими рекомендациями по повышению безопасности на основе теста производительности CIS Kubernetes.

Оптимизация затрат

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

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

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

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

Контрольный список проектирования

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

Рекомендации

Ознакомьтесь со следующей таблицей рекомендаций по оптимизации конфигурации AKS по затратам.

Рекомендация Преимущество
Архитектуры кластеров и рабочих нагрузок: Согласование выбора номера SKU и размера управляемого диска с требованиями к рабочей нагрузке. Сопоставление выбора с требованиями рабочей нагрузки гарантирует, что вы не будете платить за ненужные ресурсы.
Архитектура кластера. Выберите правильный тип экземпляра виртуальной машины. Выбор правильного типа экземпляра виртуальной машины имеет решающее значение, так как это напрямую влияет на стоимость запуска приложений в AKS. Выбор высокопроизводительного экземпляра без надлежащего использования может привести к расточительным затратам, а выбор мощного экземпляра может привести к проблемам с производительностью и увеличению времени простоя. Чтобы определить правильный тип экземпляра виртуальной машины, рассмотрите характеристики рабочей нагрузки, требования к ресурсам и потребности в доступности.
Архитектура кластера. Выберите виртуальные машины на основе архитектуры Arm. AKS поддерживает создание узлов агента Ubuntu ARM64, а также сочетание узлов архитектуры Intel и ARM в кластере, что может повысить производительность при меньших затратах.
Архитектура кластера. Выберите Точечный Виртуальные машины Azure. Точечные виртуальные машины позволяют воспользоваться неиспользуемой емкостью Azure со значительными скидками (до 90 % по сравнению с ценами с оплатой по мере использования). Если Azure требуется обратная емкость, инфраструктура Azure вытесает точечные узлы.
Архитектура кластера. Выберите соответствующий регион. Из-за многих факторов стоимость ресурсов зависит от региона в Azure. Оцените требования к затратам, задержкам и соответствию, чтобы обеспечить экономичность выполнения рабочей нагрузки и не влиять на конечных пользователей и не создавать дополнительных расходов на сеть.
Архитектура рабочей нагрузки: Поддерживайте небольшие и оптимизированные образы. Оптимизация образов помогает снизить затраты, так как новые узлы должны скачивать эти образы. Создавайте образы таким образом, чтобы контейнер запускалось как можно скорее, чтобы избежать сбоев запросов пользователей или превышения времени ожидания во время запуска приложения, что может привести к чрезмерной подготовке.
Архитектура кластера. Включите средство автомасштабирования кластера , чтобы автоматически уменьшить количество узлов агента в ответ на избыточную емкость ресурсов. Автоматическое масштабирование числа узлов в кластере AKS позволяет запускать эффективный кластер, когда спрос низкий, и увеличивать масштаб при возврате спроса.
Архитектура кластера. Включите автоматическую подготовку узла , чтобы автоматизировать выбор номера SKU виртуальной машины. Автоматическая подготовка узла упрощает процесс выбора номера SKU и решает, исходя из требований к ресурсам pod, оптимальную конфигурацию виртуальной машины для выполнения рабочих нагрузок наиболее эффективным и экономичным способом.
Архитектура рабочей нагрузки: Используйте средство горизонтального автомасштабирования pod. Настройте количество модулей pod в развертывании в зависимости от использования ЦП или других метрик, которые поддерживают операции масштабирования кластера.
Архитектура рабочей нагрузки: Используйте средство автомасштабирования вертикального pod (предварительная версия). Укажите права для модулей pod и динамически устанавливайте запросы и ограничения на основе исторических данных об использовании.
Архитектура рабочей нагрузки: Используйте автомасштабирование на основе событий Kubernetes (KEDA). Масштабирование в зависимости от количества обрабатываемых событий. Выберите из богатого каталога из более чем 50 масштабировщиков KEDA.
Архитектура кластера и рабочей нагрузки: Применяйте облачную финансовую дисциплину и культурную практику, чтобы управлять использованием облака. Основой оптимизации затрат является распределение кластера, экономя затраты. Подход к финансовым операциям (FinOps) часто используется для того, чтобы помочь организациям снизить затраты на облако. Это практика, предполагающая совместную работу между финансовыми, операционными и инженерными командами для обеспечения согласованности целей экономии средств и обеспечения прозрачности затрат на облако.
Архитектура кластера: Зарегистрируйтесь для получения резервирований Azure или сберегательного плана Azure. Если вы правильно спланировали емкость, рабочая нагрузка предсказуема и существует в течение длительного периода времени, зарегистрируйтесь для резервирования Azure или плана экономии , чтобы еще больше сократить затраты на ресурсы.
Архитектура кластера: Настройте мониторинг кластера с помощью аналитики контейнеров. Аналитика контейнеров предоставляет полезные сведения о бездействующих и нераспределенных ресурсах кластеров. Аналитика контейнеров также поддерживает сбор метрик Prometheus и интегрируется с Управляемой Grafana Azure, чтобы получить целостное представление о приложении и инфраструктуре.
Архитектура кластера: Настройте надстройку анализа затрат AKS. Расширение кластера для анализа затрат позволяет получить подробные сведения о затратах, связанных с различными ресурсами Kubernetes в кластерах или пространствах имен.

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

Определения политик

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

Эффективность облака

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

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

эффективность работы;

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

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

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

Контрольный список проектирования

  • Архитектура кластера: Используйте развертывание на основе шаблона с помощью Bicep, Terraform или других. Убедитесь, что все развертывания являются повторяемыми, отслеживаемыми и хранятся в репозитории исходного кода.
  • Архитектура кластера: Создайте автоматизированный процесс, чтобы обеспечить начальную загрузку кластеров с необходимыми конфигурациями и развертываниями на уровне кластера. Это часто выполняется с помощью GitOps.
  • Архитектура рабочей нагрузки: Используйте повторяемые и автоматизированные процессы развертывания для рабочей нагрузки в рамках жизненного цикла разработки программного обеспечения.
  • Архитектура кластера: Включите параметры диагностика, чтобы обеспечить ведение журнала взаимодействия уровня управления или основного сервера API.
  • Архитектура кластера и рабочей нагрузки: Включите аналитику контейнеров для сбора метрик, журналов и диагностика для отслеживания доступности и производительности кластера и рабочих нагрузок, работающих в нем.
  • Архитектура рабочей нагрузки: Рабочая нагрузка должна быть разработана для отправки данных телеметрии, которые могут быть собраны, которые также должны включать в себя состояние живости и готовности.
  • Архитектура кластера и рабочей нагрузки: Используйте методы проектирования хаоса, предназначенные для Kubernetes, для выявления проблем с надежностью приложений или платформ.
  • Архитектура рабочей нагрузки: Оптимизируйте рабочую нагрузку для эффективной работы и развертывания в контейнере.
  • Архитектура кластера и рабочей нагрузки: Применяйте управление кластерами и рабочими нагрузками с помощью Политика Azure.

Рекомендации

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

Рекомендация Преимущество
Архитектура кластера и рабочей нагрузки: Ознакомьтесь с документацией по рекомендациям AKS . Чтобы успешно создавать и запускать приложения в AKS, необходимо понять и реализовать основные аспекты. К этим областям относится мультитенантность и возможности планировщика, безопасность кластера и pod, непрерывность бизнес-процессов и аварийное восстановление.
Архитектура кластера и рабочей нагрузки: Ознакомьтесь с Azure Chaos Studio. Azure Chaos Studio может помочь имитировать ошибки и активировать ситуации аварийного восстановления.
Архитектура кластера и рабочей нагрузки: Настройте мониторинг кластера с помощью аналитики контейнеров. Аналитика контейнеров помогает отслеживать производительность контейнеров, собирая метрики памяти и процессора из контроллеров, узлов и контейнеров, доступных в Kubernetes с помощью API метрик и журналов контейнеров.
Архитектура рабочей нагрузки: Мониторинг производительности приложений с помощью Azure Monitor. Настройте Application Insights для мониторинга приложений, работающих в кластере AKS на основе кода.
Архитектура рабочей нагрузки: Настройте получение метрик Prometheus с помощью аналитики контейнеров. Аналитика контейнеров, которая является частью Azure Monitor, обеспечивает простое подключение для сбора метрик Prometheus. Дополнительные сведения см. в статье Настройка очистки метрик Prometheus .
Архитектура кластера: Применяйте стратегию в нескольких регионах , развертывая кластеры AKS, развернутые в разных регионах Azure, чтобы обеспечить максимальную доступность и непрерывность бизнес-процессов. Рабочие нагрузки, подключенные к Интернету, должны использовать Azure Front Door или диспетчер трафика Azure для глобальной маршрутизации трафика между кластерами AKS.
Архитектура кластера: Ввод в эксплуатацию стандартов конфигурации кластеров и модулей pod с помощью Политика Azure. Политика Azure может помочь централизованно и согласованно применять к кластерам применение и меры безопасности в большом масштабе. Она также может управлять тем, каким функциям назначаются модули pod, и нет ли нарушений политики компании.
Архитектура рабочей нагрузки: Используйте возможности платформы в процессе разработки выпуска. Контроллеры Kubernetes и ingress поддерживают множество расширенных шаблонов развертывания для включения в процесс разработки выпуска. Рассмотрите такие шаблоны, как сине-зеленые развертывания или канаревые выпуски.
Архитектура кластера и рабочей нагрузки: Для критически важных рабочих нагрузок используйте сине-зеленые развертывания на уровне меток. Автоматизация критически важных областей проектирования, включая развертывание и тестирование.

Дополнительные предложения см. в разделе Принципы операционного совершенства.

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

Определения политик

Политика Azure предлагает различные встроенные определения политик, которые применяются как к ресурсу Azure, так и к AKS, например стандартные определения политик, а также с использованием надстройки Политика Azure для Kubernetes в кластере. Многие политики ресурсов Azure поставляются как в аудите или запрете, так и в варианте Deploy If Not Exists .

Существует множество политик, и ключевые политики, связанные с этим компонентом, приведены здесь. Более подробное представление см. в статье Встроенные определения политик для Kubernetes.

Архитектура кластера

  • надстройка Политика Azure для Kubernetes
  • Политики конфигурации GitOps
  • Политики параметров диагностики
  • Ограничения версий AKS
  • Запрет вызова команды

Архитектура кластера и рабочей нагрузки

  • Ограничения развертывания пространства имен

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

Уровень производительности

Уровень производительности — это способность вашей рабочей нагрузки масштабироваться в соответствии с требованиями, предъявляемыми к ней пользователями эффективным образом. Мы рекомендуем ознакомиться с принципами эффективности производительности.

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

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

Контрольный список проектирования

При выборе макета для Служба Azure Kubernetes ознакомьтесь с принципами эффективности производительности.

  • Архитектура кластера и рабочей нагрузки: Выполните итерацию по подробному плану емкости, включающее SKU, параметры автомасштабирования, IP-адресацию и рекомендации по отработке отказа.
  • Архитектура кластера: Включите средство автомасштабирования кластера , чтобы автоматически настраивать количество узлов агента в соответствии с требованиями рабочей нагрузки.
  • Архитектура кластера: Используйте средство горизонтального автомасштабирования pod , чтобы настроить количество модулей pod в развертывании в зависимости от использования ЦП или других метрик.
  • Архитектура кластера и рабочей нагрузки: Выполняйте текущие действия нагрузочного тестирования, которые выполняют как средство автомасштабирования pod, так и кластера.
  • Архитектура кластера и рабочей нагрузки: Разделяйте рабочие нагрузки на разные пулы узлов, обеспечивая независимое масштабирование.

Рекомендации

Ознакомьтесь со следующей таблицей рекомендаций по оптимизации конфигурации Служба Azure Kubernetes для повышения производительности.

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

Дополнительные рекомендации см. в разделе Принципы обеспечения эффективности производительности.

Определения политик

Политика Azure предлагает различные встроенные определения политик, которые применяются как к ресурсу Azure, так и к AKS, например стандартные определения политик, а также с использованием надстройки Политика Azure для Kubernetes в кластере. Многие политики ресурсов Azure поставляются как в аудите или запрете, так и в варианте Deploy If Not Exists .

Существует множество политик, и ключевые политики, связанные с этим компонентом, приведены здесь. Более подробное представление см. в статье Встроенные определения политик для Kubernetes.

Архитектура кластера и рабочей нагрузки

  • Ограничения ресурсов ЦП и памяти

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

Дополнительные ресурсы

Руководство по Центру архитектуры Azure

Руководство по Cloud Adoption Framework

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