Обзор Azure Well-Architected Framework — Служба Azure Kubernetes (AKS)
В этой статье приведены рекомендации по архитектуре Служба Azure Kubernetes (AKS). Руководство основано на пяти основных принципах архитектуры:
- Надежность
- Безопасность
- Оптимизация затрат
- Эффективность работы
- Оптимизация производительности
Мы предполагаем, что вы понимаете принципы проектирования системы, имеют знания о Служба Azure Kubernetes и хорошо знакомы с ее функциями. Дополнительные сведения см. на странице Служба Azure Kubernetes.
Необходимые компоненты
Общие сведения о принципах хорошо спроектированной платформы могут помочь в создании высококачественной, стабильной и эффективной облачной архитектуры. Рекомендуется просмотреть рабочую нагрузку с помощью оценки проверки платформы Azure Well-Architected Framework .
Для контекста рассмотрите возможность проверки эталонной архитектуры, которая отражает эти аспекты в его проектировании. Мы рекомендуем начать с базовой архитектуры для кластера Служба Azure Kubernetes (AKS) и архитектуры микрослужб на Служба Azure Kubernetes. Кроме того, просмотрите акселератор целевой зоны AKS, который предоставляет архитектурный подход и эталонную реализацию для подготовки подписок целевой зоны для масштабируемого кластера Служба Azure Kubernetes (AKS).
Надежность
Мы подтверждаем, что в облачной среде возникают сбои. Вместо того чтобы пытаться предотвратить все возможные сбои, нужно свести к минимуму воздействие сбоя каждого отдельного компонента. Используйте следующие сведения, чтобы свести к минимуму неудачные экземпляры.
При обсуждении надежности с Служба Azure Kubernetes важно различать надежность кластера и надежность рабочей нагрузки. Надежность кластера — это общая ответственность между администратором кластера и поставщиком ресурсов, а надежность рабочей нагрузки — это домен разработчика. Служба Azure Kubernetes имеет рекомендации и рекомендации для обеих этих ролей.
В контрольном списке конструктора и списке рекомендаций ниже выноски указывают, подходит ли каждый выбор к архитектуре кластера, архитектуре рабочей нагрузки или обоим.
Контрольный список проектирования
- Архитектура кластера. Для критически важных рабочих нагрузок используйте зоны доступности для кластеров AKS.
- Архитектура кластера. Запланируйте пространство IP-адресов, чтобы обеспечить надежное масштабирование кластера, включая обработку трафика отработки отказа в топологиях с несколькими кластерами.
- Архитектура кластера. Ознакомьтесь с рекомендациями по мониторингу Kubernetes с помощью Azure Monitor , чтобы определить оптимальную стратегию мониторинга для рабочих нагрузок.
- Архитектура рабочей нагрузки. Убедитесь, что рабочие нагрузки созданы для поддержки горизонтального масштабирования и готовности приложения к работе с приложением отчетов и работоспособности.
- Архитектуры кластера и рабочей нагрузки: убедитесь, что рабочая нагрузка выполняется в пулах узлов пользователей и выбирает правильный номер 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 с помощью Azure Monitor , чтобы определить оптимальную стратегию мониторинга для рабочих нагрузок. | Н/П |
| Архитектура кластера. Используйте зоны доступности для максимальной устойчивости в регионе Azure путем распределения узлов агента AKS в физически отдельных центрах обработки данных. | Распространяя пулы узлов по нескольким зонам, узлы в одном пуле узлов будут продолжать работать, даже если другая зона снизилась. Если существуют требования к колокалисти, можно использовать обычное развертывание AKS на основе Масштабируемые наборы виртуальных машин в одной зоне или группах размещения близкого взаимодействия для минимизации задержки в междомерной среде. |
| Архитектура кластера. Внедрение стратегии многорегионирования путем развертывания кластеров 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.
Архитектура кластера и рабочей нагрузки
- Кластеры имеют проверки готовности или работоспособности активности, настроенные для спецификации pod.
Помимо встроенных определений Политика Azure настраиваемые политики можно создавать как для ресурса AKS, так и для надстройки Политика Azure для Kubernetes. Это позволяет добавлять дополнительные ограничения надежности, которые вы хотите применить в архитектуре кластера и рабочей нагрузки.
Безопасность
Безопасность является одним из наиболее важных аспектов любой архитектуры. Чтобы узнать, как AKS может повысить безопасность рабочей нагрузки приложения, рекомендуется ознакомиться с принципами проектирования безопасности. Если кластер Служба Azure Kubernetes должен быть разработан для выполнения конфиденциальной рабочей нагрузки, которая соответствует нормативным требованиям стандарта безопасности данных индустрии карт оплаты (PCI-DSS 3.2.1), ознакомьтесь с регулируемым кластером AKS для PCI-DSS 3.2.1.
Чтобы узнать о поддержке и требованиях уровня влияния DoD 5 (IL5) с помощью AKS, ознакомьтесь с требованиями к изоляции IL5 Azure для государственных организаций IL5.
При обсуждении безопасности с Служба Azure Kubernetes важно различать безопасность кластера и безопасность рабочей нагрузки. Безопасность кластера является общей ответственностью между администратором кластера и их поставщиком ресурсов, а безопасность рабочей нагрузки — это домен разработчика. Служба Azure Kubernetes имеет рекомендации и рекомендации для обеих этих ролей.
В контрольном списке конструктора и списке рекомендаций ниже выносятся вызовы, чтобы указать, подходит ли каждый выбор к архитектуре кластера, архитектуре рабочей нагрузки или обоим.
Контрольный список проектирования
- Архитектура кластера: используйте управляемые удостоверения , чтобы избежать управления и смены принципов службы.
- Архитектура кластера. Использование управления доступом на основе ролей Kubernetes (RBAC) с идентификатором Microsoft Entra для минимального доступа к привилегиям и минимизации предоставления прав администратора для защиты конфигурации и доступа к секретам.
- Архитектура кластера. Используйте Microsoft Defender для контейнеров с Azure Sentinel для обнаружения и быстрого реагирования на угрозы в кластере и рабочих нагрузках, работающих на них.
- Архитектура кластера. Разверните частный кластер AKS, чтобы убедиться, что трафик управления кластерами на сервер API остается в частной сети. Или используйте список разрешений сервера API для не частных кластеров.
- Архитектура рабочей нагрузки: используйте Брандмауэр веб-приложений для защиты трафика HTTP(S).
- Архитектура рабочей нагрузки. Убедитесь, что конвейер CI/CID затверден с помощью проверки с учетом контейнера.
Рекомендации
Ознакомьтесь со следующей таблицей рекомендаций по оптимизации конфигурации AKS для обеспечения безопасности.
| Рекомендация | Преимущества |
|---|---|
| Архитектура кластера. Использование интеграции Microsoft Entra. | Использование идентификатора Microsoft Entra позволяет централизованно использовать компонент управления удостоверениями. Любые изменения в статусе учетной записи пользователя или группы автоматически обновляются при доступе к кластеру AKS. Разработчикам и владельцам приложений кластера Kubernetes нужен доступ к различным ресурсам. |
| Архитектура кластера: проверка подлинности с помощью идентификатора Microsoft Entra в Реестр контейнеров Azure. | AKS и идентификатор Microsoft Entra позволяют выполнять проверку подлинности с Реестр контейнеров Azure без использования секретовimagePullSecrets. Дополнительные сведения см. в Служба Azure Kubernetes для проверки подлинности с помощью Реестр контейнеров Azure. |
| Архитектура кластера: безопасный сетевой трафик к серверу API с помощью частного кластера AKS. | По умолчанию сетевой трафик между пулами узлов и сервером API передает магистральную сеть Майкрософт; С помощью частного кластера можно убедиться, что сетевой трафик к серверу API остается только в частной сети. |
| Архитектура кластера. Для кластеров, отличных от частных кластеров AKS, используйте авторизованные диапазоны IP-адресов сервера API. | При использовании общедоступных кластеров можно ограничить трафик, который может достичь сервера API кластеров с помощью функции авторизованного диапазона IP-адресов. Включите такие источники, как общедоступные IP-адреса агентов сборки развертывания, управление операциями и точки исходящего трафика пулов узлов (например, Брандмауэр Azure). |
| Архитектура кластера: защита сервера API с помощью Microsoft Entra RBAC. | Обеспечение безопасного доступа к серверу API Kubernetes является одним из самых важных факторов для защиты кластера. Интеграция управления доступом на основе ролей Kubernetes (RBAC) с идентификатором Microsoft Entra для управления доступом к серверу API. Отключите локальные учетные записи для принудительного доступа ко всем кластерам с помощью удостоверений на основе идентификаторов Microsoft Entra. |
| Архитектура кластера: используйте политики сети Azure или Calico. | Защита сетевого трафика между модулями pod в кластере и управление ими. |
| Архитектура кластера: защита кластеров и модулей pod с помощью Политика Azure. | Политика Azure может помочь применить масштабируемое применение и защиту в кластерах в централизованном и согласованном режиме. Она также позволяет управлять назначением функций определенным pod и контролировать отсутствие нарушений политики компании. |
| Архитектура кластера: безопасный доступ к ресурсам контейнера. | Ограничьте доступ к действиям, которые могут выполнять контейнеры. Укажите наименьшее количество разрешений и избегайте использования корневого доступа или повышения привилегий. |
| Архитектура рабочей нагрузки: используйте Брандмауэр веб-приложений для защиты трафика HTTP(S). | Чтобы проверить входящие трафик для потенциальных атак, используйте брандмауэр веб-приложения, например Azure Брандмауэр веб-приложений (WAF) в Шлюз приложений Azure или Azure Front Door. |
| Архитектура кластера: управление исходящим трафиком кластера. | Убедитесь, что исходящий трафик кластера проходит через точку безопасности сети, например Брандмауэр Azure или прокси-сервер HTTP. |
| Архитектура кластера: используйте Идентификация рабочей нагрузки Microsoft Entra драйвер CSI хранилища секретов с открытым исходным кодом с открытым кодом в Azure Key Vault. | Защита и смена секретов, сертификатов и строка подключения в Azure Key Vault с помощью строгого шифрования. Предоставляет журнал аудита доступа и сохраняет основные секреты из конвейера развертывания. |
| Архитектура кластера. Использование Microsoft Defender для контейнеров. | Отслеживайте и поддерживайте безопасность кластеров, контейнеров и их приложений. |
Дополнительные предложения см. в разделе "Принципы обеспечения безопасности".
Помощник по Azure помогает обеспечить и улучшить службу Azure Kubernetes. Он предоставляет рекомендации по подмножества элементов, перечисленных в разделе политики ниже, например кластеры без настройки RBAC, отсутствие конфигурации Microsoft Defender, неограниченный сетевой доступ к серверу API. Аналогичным образом он предоставляет рекомендации по рабочей нагрузке для некоторых элементов инициативы по безопасности pod. Просмотрите рекомендации.
Определения политик
Политика Azure предлагает различные встроенные определения политик, которые применяются как к ресурсу Azure, так и к стандартным определениям политик и использованию надстройки Политика Azure для Kubernetes, а также в кластере. Многие политики ресурсов Azure входят как в аудит, так и в запрете, но и в варианте развертывания, если он не существует.
Здесь приведены многочисленные ключевые политики, связанные с этим принципом. Более подробное представление см . в встроенных определениях политик для Kubernetes.
Архитектура кластера
- политики на основе Microsoft Defender для облака
- Режим проверки подлинности и политики конфигурации (идентификатор Microsoft Entra, RBAC, отключение локальной проверки подлинности)
- Политики сетевого доступа к СЕРВЕРУ API, включая частный кластер
Архитектура кластера и рабочей нагрузки
- Инициативы по безопасности pod кластера Kubernetes под управлением Linux
- Включение политик возможностей pod и контейнеров, таких как AppArmor, sysctl, caps, SELinux, seccomp, привилегированные контейнеры, учетные данные API кластера автоподключения
- Подключение, драйверы томов и политики файловой системы
- Политики сети pod/Container, такие как сеть узлов, порт, разрешенные внешние IP-адреса, HTTPs и внутренние подсистемы балансировки нагрузки
Служба Azure Kubernetes развертывания часто используют Реестр контейнеров Azure для диаграмм Helm и образов контейнеров. Реестр контейнеров Azure также поддерживает широкий спектр политик Azure, охватывающих ограничения сети, управление доступом и Microsoft Defender для облака, который дополняет безопасную архитектуру AKS.
Помимо встроенных политик пользовательские политики можно создавать как для ресурса AKS, так и для надстройки Политика Azure для Kubernetes. Это позволяет добавлять дополнительные ограничения безопасности, которые вы хотите применить в архитектуре кластера и рабочей нагрузки.
Дополнительные предложения см . в концепциях безопасности AKS и оценке рекомендаций по защите безопасности на основе теста CIS Kubernetes.
Оптимизация затрат
Оптимизация затрат — это понимание различных параметров конфигурации и рекомендуемых рекомендаций по сокращению ненужных расходов и повышению эффективности работы. Прежде чем следовать инструкциям в этой статье, рекомендуется ознакомиться со следующими ресурсами:
- Принципы проектирования оптимизации затрат.
- Как работают цены и управление затратами в Служба Azure Kubernetes (AKS) по сравнению с Amazon Elastic Kubernetes Service (Amazon EKS).
- Если вы используете AKS локально или на границе, Преимущество гибридного использования Azure также можно использовать для дальнейшего снижения затрат при выполнении контейнерных приложений в этих сценариях.
При обсуждении оптимизации затрат с Служба Azure Kubernetes важно различать затраты на ресурсы кластера и затраты на рабочие нагрузки. Ресурсы кластера являются общей ответственностью между администратором кластера и их поставщиком ресурсов, а ресурсы рабочей нагрузки являются доменом разработчика. Служба Azure Kubernetes имеет рекомендации и рекомендации для обеих этих ролей.
В контрольном списке проектирования и списке рекомендаций вызовы выполняются, чтобы указать, подходит ли каждый выбор к архитектуре кластера, архитектуре рабочей нагрузки или обоим.
Для оптимизации затрат кластера перейдите к калькулятору цен Azure и выберите Служба Azure Kubernetes из доступных продуктов. Вы можете протестировать различные планы конфигурации и оплаты в калькуляторе.
Контрольный список проектирования
- Архитектура кластера. Используйте соответствующий номер SKU виртуальной машины для пула узлов и зарезервированные экземпляры, где ожидается долгосрочная емкость.
- Архитектуры кластера и рабочей нагрузки: используйте соответствующий уровень и размер управляемого диска.
- Архитектура кластера: просмотрите метрики производительности, начиная с ЦП, памяти, хранилища и сети, чтобы определить возможности оптимизации затрат по кластеру, узлам и пространству имен.
- Архитектура кластера и рабочей нагрузки: используйте автомасштабирование для масштабирования при менее активной рабочей нагрузке.
Рекомендации
Ознакомьтесь со следующей таблицей рекомендаций по оптимизации конфигурации AKS для затрат.
| Рекомендация | Преимущества |
|---|---|
| Архитектура кластера и рабочей нагрузки: выравнивание размера SKU и размера управляемого диска с требованиями к рабочей нагрузке. | Сопоставление выбора с требованиями рабочей нагрузки гарантирует, что вы не платите за ненужные ресурсы. |
| Архитектура кластера. Выберите правильный тип экземпляра виртуальной машины. | Выбор правильного типа экземпляра виртуальной машины имеет решающее значение, так как это напрямую влияет на стоимость запуска приложений в AKS. Выбор высокопроизводительного экземпляра без правильного использования может привести к расточительным расходам, при этом выбор менее мощного экземпляра может привести к проблемам производительности и увеличению простоя. Чтобы определить правильный тип экземпляра виртуальной машины, рассмотрите характеристики рабочей нагрузки, требования к ресурсам и потребности в доступности. |
| Архитектура кластера. Выбор виртуальных машин на основе архитектуры Arm. | AKS поддерживает создание узлов агента Ubuntu Arm64, а также сочетание узлов архитектуры Intel и ARM в кластере, которые могут повысить производительность при более низкой стоимости. |
| Архитектура кластера: выберите Виртуальные машины Azure Spot. | Точечные виртуальные машины позволяют воспользоваться неиспользуемой емкостью Azure со значительными скидками (до 90 % по сравнению с ценами по мере использования). Если Azure нуждается в емкости, инфраструктура Azure вытесняет точечные узлы. |
| Архитектура кластера: выберите соответствующий регион. | Из-за многих факторов стоимость ресурсов зависит от региона в Azure. Оцените требования к затратам, задержкам и соответствию требованиям, чтобы обеспечить эффективную работу рабочей нагрузки, и это не влияет на конечных пользователей или создает дополнительные сетевые расходы. |
| Архитектура рабочей нагрузки: обслуживание небольших и оптимизированных образов. | Упрощение изображений помогает сократить затраты, так как новые узлы должны скачать эти образы. Создавайте образы таким образом, чтобы контейнер запускал как можно скорее, чтобы избежать сбоев запросов пользователей или времени ожидания во время запуска приложения, что может привести к чрезмерной подготовке. |
| Архитектура кластера. Включите автомасштабирование кластера для автоматического уменьшения количества узлов агента в ответ на превышение емкости ресурсов. | Автоматическое масштабирование числа узлов в кластере AKS позволяет запускать эффективный кластер, когда спрос низкий и масштабируется при возврате спроса. |
| Архитектура кластера: включение автоматической подготовки узла для автоматизации выбора номера SKU виртуальной машины. | Автопровизия узла упрощает процесс выбора номера SKU и решает, основываясь на требованиях к ресурсам pod, оптимальной конфигурации виртуальной машины для выполнения рабочих нагрузок в наиболее эффективном и экономичном режиме. |
| Архитектура рабочей нагрузки: используйте средство автомасштабирования горизонтального модуля Pod. | Настройте количество модулей pod в развертывании в зависимости от использования ЦП или других метрик выбора, которые поддерживают операции масштабирования кластера. |
| Архитектура рабочей нагрузки: используйте средство автомасштабирования pod (предварительная версия). | Справа от модулей pod и динамически устанавливайте запросы и ограничения на основе исторического использования. |
| Архитектура рабочей нагрузки: использование автомасштабирования на основе событий Kubernetes (KEDA). | Масштабирование на основе количества обрабатываемых событий. Выберите из полнофункционированного каталога 50+ масштабировщиков KEDA. |
| Архитектура кластера и рабочей нагрузки: внедрение облачной финансовой дисциплины и культурной практики для управления владением облачным использованием. | Основой включения оптимизации затрат является распространение кластера экономии затрат. Подход к финансовым операциям (FinOps) часто используется для снижения затрат на облако организациями. Это практика, связанная с сотрудничеством между финансами, операциями и инженерными командами, чтобы обеспечить выравнивание по целям экономии затрат и обеспечить прозрачность облачных затрат. |
| Архитектура кластера: регистрация для резервирования Azure или плана экономии Azure. | Если вы правильно планировали для емкости, рабочая нагрузка предсказуема и существует в течение длительного периода времени, зарегистрируйтесь в резервировании Azure или плане экономии для дальнейшего снижения затрат на ресурсы. |
| Архитектура кластера. Ознакомьтесь с рекомендациями по мониторингу Kubernetes с помощью Azure Monitor , чтобы определить оптимальную стратегию мониторинга для рабочих нагрузок. | Н/П |
| Архитектура кластера: настройка надстройки "Анализ затрат AKS". | Расширение кластера анализа затрат позволяет получить подробные сведения о затратах, связанных с различными ресурсами Kubernetes в кластерах или пространствах имен. |
Дополнительные предложения см. в разделе "Принципы оптимизации затрат" и "Оптимизация затрат" в Служба Azure Kubernetes.
Определения политик
Несмотря на отсутствие встроенных политик, связанных с оптимизацией затрат, пользовательские политики можно создавать как для ресурса AKS, так и для надстройки Политика Azure для Kubernetes. Это позволяет добавлять дополнительные ограничения оптимизации затрат, которые вы хотите применить в архитектуре кластера и рабочей нагрузки.
Эффективность облака
Создание рабочих нагрузок более устойчивым и облачным, требует объединения усилий по оптимизации затрат, сокращению выбросов углерода и оптимизации потребления энергии. Оптимизация затрат приложения — это начальный шаг в том, чтобы рабочие нагрузки были более устойчивыми.
Узнайте, как создавать устойчивые и эффективные рабочие нагрузки AKS в принципах устойчивого проектирования программного обеспечения в Служба Azure Kubernetes (AKS).
Эффективность работы
Мониторинг и диагностика имеют огромное значение. Не только можно измерять статистику производительности, но и быстро устранять проблемы с метриками. Мы рекомендуем ознакомиться с принципами проектирования операционного превосходства и руководством по операциям Day-2.
При обсуждении эффективности работы с Служба Azure Kubernetes важно различать эффективность работы кластера и эффективность работы рабочей нагрузки. Операции кластера являются общей ответственностью между администратором кластера и их поставщиком ресурсов, а операции рабочей нагрузки являются доменом разработчика. Служба Azure Kubernetes имеет рекомендации и рекомендации для обеих этих ролей.
В контрольном списке конструктора и списке рекомендаций ниже выносятся вызовы, чтобы указать, подходит ли каждый выбор к архитектуре кластера, архитектуре рабочей нагрузки или обоим.
Контрольный список проектирования
- Архитектура кластера: используйте развертывание на основе шаблонов с помощью Bicep, Terraform или других. Убедитесь, что все развертывания повторяются, отслеживаются и хранятся в репозитории исходного кода.
- Архитектура кластера: создайте автоматизированный процесс, чтобы обеспечить загрузку кластеров с необходимыми конфигурациями и развертываниями на уровне кластера. Это часто выполняется с помощью GitOps.
- Архитектура рабочей нагрузки. Используйте повторяемые и автоматизированные процессы развертывания для рабочей нагрузки в рамках жизненного цикла разработки программного обеспечения.
- Архитектура кластера. Включите параметры диагностика, чтобы обеспечить ведение журнала взаимодействия с сервером API уровня управления или ядра API.
- Архитектура кластера и рабочей нагрузки. Ознакомьтесь с рекомендациями по мониторингу Kubernetes с помощью Azure Monitor , чтобы определить оптимальную стратегию мониторинга для рабочих нагрузок.
- Архитектура рабочей нагрузки: рабочая нагрузка должна быть разработана для передачи данных телеметрии, которую можно собирать, что также должно включать состояние работоспособности и готовности.
- Архитектуры кластеров и рабочих нагрузок: используйте методики проектирования хаоса, предназначенные для Kubernetes, для выявления проблем с надежностью приложений или платформы.
- Архитектура рабочей нагрузки: оптимизируйте рабочую нагрузку для эффективной работы и развертывания в контейнере.
- Архитектуры кластеров и рабочих нагрузок: принудительное управление кластером и рабочей нагрузкой с помощью Политика Azure.
Рекомендации
Ознакомьтесь со следующей таблицей рекомендаций по оптимизации конфигурации AKS для операций.
| Рекомендация | Преимущества |
|---|---|
| Архитектура кластера и рабочей нагрузки. Ознакомьтесь с документацией по рекомендациям AKS. | Чтобы успешно создавать и запускать приложения в AKS, необходимо понимать и реализовывать основные рекомендации. К этим областям относится мультитенантность и возможности планировщика, безопасность кластера и pod, непрерывность бизнес-процессов и аварийное восстановление. |
| Архитектура кластера и рабочей нагрузки. Просмотрите Azure Chaos Studio. | Azure Chaos Studio может помочь имитировать ошибки и активировать ситуации аварийного восстановления. |
| Архитектура кластера и рабочей нагрузки. Ознакомьтесь с рекомендациями по мониторингу Kubernetes с помощью Azure Monitor , чтобы определить оптимальную стратегию мониторинга для рабочих нагрузок. | Н/П |
| Архитектура кластера. Внедрение стратегии многорегионирования путем развертывания кластеров AKS, развернутых в разных регионах Azure, чтобы повысить доступность и обеспечить непрерывность бизнес-процессов. | Рабочие нагрузки, подключенные к Интернету, должны использовать Azure Front Door или Диспетчер трафика Azure для глобального маршрутизации трафика в кластерах AKS. |
| Архитектура кластера: эксплуатация кластеров и стандартов конфигурации pod с помощью Политика Azure. | Политика Azure может помочь применить масштабируемое применение и защиту в кластерах в централизованном и согласованном режиме. Она также позволяет управлять назначением функций определенным pod и контролировать отсутствие нарушений политики компании. |
| Архитектура рабочей нагрузки: используйте возможности платформы в процессе разработки выпусков. | Контроллеры Kubernetes и ingress поддерживают множество расширенных шаблонов развертывания для включения в процесс разработки выпусков. Рассмотрим такие шаблоны, как голубые зеленые развертывания или канареарные выпуски. |
| Архитектуры кластеров и рабочих нагрузок: для критически важных рабочих нагрузок используйте синие и зеленые развертывания на уровне метки. | Автоматизация критически важных областей проектирования, включая развертывание и тестирование. |
Дополнительные предложения см. в разделе "Принципы операционного превосходства".
Помощник по Azure также предоставляет рекомендации по подмножествам элементов, перечисленных в разделе политики ниже, таким неподдерживаемых версий AKS и ненастроенных параметров диагностики. Аналогичным образом он делает рекомендации по рабочей нагрузке по использованию пространства имен по умолчанию.
Определения политик
Политика Azure предлагает различные встроенные определения политик, которые применяются как к ресурсу Azure, так и к стандартным определениям политик и использованию надстройки Политика Azure для Kubernetes, а также в кластере. Многие политики ресурсов Azure входят как в аудит, так и в запрете, но и в варианте развертывания, если он не существует.
Здесь приведены многочисленные ключевые политики, связанные с этим принципом. Более подробное представление см . в встроенных определениях политик для 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, так и к стандартным определениям политик и использованию надстройки Политика Azure для Kubernetes, а также в кластере. Многие политики ресурсов Azure входят как в аудит, так и в запрете, но и в варианте развертывания, если он не существует.
Здесь приведены многочисленные ключевые политики, связанные с этим принципом. Более подробное представление см . в встроенных определениях политик для Kubernetes.
Архитектура кластера и рабочей нагрузки
- Ограничения ресурсов ЦП и памяти
Помимо встроенных политик пользовательские политики можно создавать как для ресурса AKS, так и для надстройки Политика Azure для Kubernetes. Это позволяет добавлять дополнительные ограничения безопасности, которые вы хотите применить в архитектуре кластера и рабочей нагрузки.
Дополнительные ресурсы
Руководство по Центру архитектуры Azure
- Базовая архитектура AKS
- Расширенная архитектура микрослужб AKS
- Кластер AKS для рабочей нагрузки PCI-DSS
- Базовые показатели AKS для кластеров с несколькими агрегатами