Базовая архитектура для кластера Службы Azure Kubernetes (AKS)

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

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

Целевая архитектура зависит от бизнес-требований, и в результате она может отличаться между различными контекстами приложений. Она должна рассматриваться как отправная точка для этапов предварительной и рабочей среды.

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

Конфигурации сети

Топология сети
Планирование IP-адресов
Развертывание ресурсов входящего трафика

Вычислительные ресурсы кластера

Вычисления для базового кластера
Справочник по образу контейнера
Управление политиками

Управление удостоверениями

Интеграция идентификатора Microsoft Entra для кластера
Интеграция идентификатора Microsoft Entra для рабочей нагрузки

Безопасный поток данных

Защита сетевого потока
Добавление управления секретами

Непрерывность бизнес-процессов

Масштабируемость
Доступность кластера и узла
Поддержка доступности и нескольких регионов

Операции

Конвейеры CI/CD кластера и рабочей нагрузки
Работоспособности кластера и метрик
Управление затратами и отчетность

Топология сети

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

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

• Сводит к минимуму прямую экспозицию ресурсов Azure к общедоступному Интернету.

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

• Для управления потоком трафика HTTP все веб-приложения должны требоваться служба брандмауэра веб-приложений (WAF).

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

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

• Некоторые ресурсы, такие как брандмауэр и DNS, могут быть общими для сетей.

• Соответствует целевым зонам корпоративного масштаба Azure.

Скачайте файл Visio для этой архитектуры.

Дополнительные сведения см. в статье Звездообразная топологии сети в Azure.

Чтобы просмотреть изменения в структуре сети, включенные в контейнеры Windows в базовой эталонной архитектуре AKS, см. в статье-компаньоне.

Узел

Виртуальная сеть концентратора — это центральная точка подключения и наблюдаемости. Концентратор всегда содержит Брандмауэр Azure с глобальными политиками брандмауэра, определенными центральными ИТ-группами для применения политики брандмауэра организации, Бастиона Azure, подсети шлюза для VPN-подключения и Azure Monitor для отслеживания сети.

В сети развертываются три подсети.

Подсеть для размещения Брандмауэр Azure

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

Подсеть для размещения шлюза

Эта подсеть является заполнителем для VPN или шлюза ExpressRoute. Шлюз обеспечивает подключение между маршрутизаторами в локальной сети и виртуальной сетью.

Подсеть для размещения Бастиона Azure

Эта подсеть является заполнителем для Бастиона Azure. Бастион можно использовать для безопасного доступа к ресурсам Azure без предоставления ресурсов в Интернете. Эта подсеть используется только для управления и операций.

Луч

Периферийная виртуальная сеть содержит кластер AKS и другие связанные ресурсы. В периферии есть четыре подсети:

Подсеть для размещения Шлюз приложений Azure

Azure Шлюз приложений — это балансировщик нагрузки веб-трафика, работающий на уровне 7. Эталонная реализация использует номер SKU Шлюз приложений версии 2, который включает Брандмауэр веб-приложений (WAF). WAF защищает входящие трафик от распространенных атак веб-трафика, включая боты. Экземпляр имеет общедоступную IP-конфигурацию внешнего интерфейса, которая получает запросы пользователей. Для Шлюз приложений требуется выделенная подсеть.

Подсеть для размещения ресурсов входящего трафика

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

Подсеть для размещения узлов кластера

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

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

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

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

планирование IP-адресов

Скачайте файл Visio для этой архитектуры.

Адресное пространство виртуальной сети должно быть достаточно большим, чтобы хранить все подсети. Учетная запись для всех сущностей, которые будут получать трафик. IP-адреса для этих сущностей будут выделены из адресного пространства подсети. Рассмотрим эти моменты.

• Обновление

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

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

• Масштабируемость

  Учитывайте количество узлов всех системных и пользовательских узлов и их максимальное ограничение масштабируемости. Предположим, вы хотите масштабировать на 400 %. Вам потребуется четыре раза больше адресов для всех этих узлов горизонтального масштабирования.

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

• адреса Приватный канал Azure

  Фактор в адресах, необходимых для связи с другими службами Azure по Приватный канал. В этой архитектуре у нас есть два адреса, назначенные для ссылок на Реестр контейнеров Azure и Key Vault.

• Некоторые адреса зарезервированы для использования в Azure. Они не могут быть назначены.

Предыдущий список не является исчерпывающим. Если у вашей структуры есть другие ресурсы, которые повлияют на количество доступных IP-адресов, вместите эти адреса.

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

Полный набор рекомендаций по этой архитектуре см. в статье "Базовая топология сети AKS".

Сведения, связанные с планированием IP-адресов для кластера AKS, см. в разделе "Планирование IP-адресов для кластера".

Сведения о планировании IP-адресов, включенных в эталонную архитектуру контейнеров Windows в базовой архитектуре AKS, см. в статье-компаньоне.

Надстройки и предварительные версии функций

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

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

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

Справочник по образу контейнера

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

• Кластер проходит проверку подлинности для извлечения образа.

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

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

  Параметром является Реестр контейнеров Azure (ACR).

• Извлечение изображений из авторизованных реестров. Это ограничение можно применить с помощью Политики Azure. В этой эталонной реализации кластер извлекает только образы из ACR, развернутых в рамках архитектуры.

Настройка вычислений для базового кластера

В AKS каждый пул узлов сопоставляется с масштабируемым набором виртуальных машин. Узлы — это виртуальные машины в каждом пуле узлов. Рекомендуется использовать меньший размер виртуальной машины для пула системных узлов, чтобы свести к минимуму затраты. Эта эталонная реализация развертывает пул системных узлов с тремя DS2_v2 узлами. Этот размер достаточно для удовлетворения ожидаемой нагрузки системных модулей pod. Диск ОС составляет 512 ГБ.

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

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

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

• Фактические размеры узлов для рабочей нагрузки зависят от требований, определенных командой разработчиков. На основе бизнес-требований мы выбрали DS4_v2 рабочей нагрузки. Чтобы снизить затраты, можно уменьшить размер до DS3_v2, что является минимальной рекомендацией.

• При планировании емкости кластера предположим, что рабочая нагрузка может использовать до 80 % каждого узла; Остальные 20 % зарезервированы для служб AKS.

• Задайте максимальное количество модулей pod на узел на основе планирования емкости. Если вы пытаетесь установить базовые показатели емкости, начните со значения 30. Настройте это значение на основе требований рабочей нагрузки, размера узла и ограничений IP-адресов.

Интеграция идентификатора Microsoft Entra для кластера

Защита доступа к кластеру и из нее критически важна. Думайте с точки зрения кластера при выборе безопасности:

• Внутренний доступ. Доступ AKS к компонентам Azure, таким как сетевая инфраструктура, Реестр контейнеров Azure и Azure Key Vault. Авторизация только тех ресурсов, к которым разрешен доступ кластера.
• Внешний доступ. Предоставление удостоверениям доступа к кластеру Kubernetes. Авторизуйте только те внешние сущности, которым разрешен доступ к серверу API Kubernetes и Azure Resource Manager.

Доступ AKS к Azure

Существует два способа управления доступом AKS к Azure с помощью идентификатора Microsoft Entra: субъектов-служб или управляемых удостоверений для ресурсов Azure.

Из двух способов рекомендуется использовать управляемые удостоверения. При использовании субъектов-служб вы отвечаете за управление секретами и смену их вручную или программным способом. С помощью управляемых удостоверений идентификатор Microsoft Entra управляет и выполняет проверку подлинности и своевременное смену секретов.

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

По умолчанию существует два основных удостоверения , используемые кластером, удостоверение кластера и удостоверение kubelet. Удостоверение кластера используется компонентами уровня управления AKS для управления ресурсами кластера, включая подсистемы балансировки нагрузки входящего трафика, управляемые общедоступные IP-адреса AKS и т. д. Удостоверение kubelet используется для проверки подлинности с помощью Реестр контейнеров Azure (ACR). Некоторые надстройки также поддерживают проверку подлинности с помощью управляемого удостоверения.

В качестве примера для внутреннего случая давайте рассмотрим использование управляемых удостоверений, когда кластеру нужно извлечь образы из реестра контейнеров. Для этого действия кластеру требуется получить учетные данные реестра. Один из способов заключается в хранении этих сведений в виде объекта Секретов Kubernetes и использования imagePullSecrets для извлечения секрета. Этот подход не рекомендуется из-за сложностей безопасности. Вам нужно не только предварительное знание секрета, но и раскрытие этого секрета через конвейер DevOps. Другая причина заключается в том, что операционные издержки управления сменой секрета. Вместо этого предоставьте acrPull доступ к управляемому удостоверению kubelet кластера в реестр. Этот подход решает эти проблемы.

В этой архитектуре кластер обращается к ресурсам Azure, защищенным идентификатором Microsoft Entra, и выполняет операции, поддерживающие управляемые удостоверения. Назначьте управление доступом на основе ролей Azure (Azure RBAC) и разрешения для управляемых удостоверений кластера в зависимости от операций, которые кластер намерен выполнить. Кластер проходит проверку подлинности в идентификаторе Microsoft Entra, а затем разрешен или запрещен доступ на основе назначенных ролей. Ниже приведены некоторые примеры из этой эталонной реализации, в которой встроенные роли Azure были назначены кластеру:

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

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

Интеграция Microsoft Entra также упрощает безопасность для внешнего доступа. Предположим, что пользователь хочет использовать kubectl. В качестве начального шага они выполняют az aks get-credentials команду, чтобы получить учетные данные кластера. Идентификатор Microsoft Entra будет проходить проверку подлинности удостоверения пользователя в ролях Azure, разрешенных для получения учетных данных кластера. Дополнительные сведения см. в разделе "Доступные разрешения для ролей кластера".

AKS позволяет получить доступ Kubernetes с помощью идентификатора Microsoft Entra id двумя способами. Первое — использование идентификатора Microsoft Entra в качестве поставщика удостоверений, интегрированного с собственной системой RBAC Kubernetes. Другой использует собственный azure RBAC для управления доступом к кластеру. Оба подробно описаны ниже.

Связывание Kubernetes RBAC с идентификатором Microsoft Entra

Kubernetes поддерживает управление доступом на основе ролей (RBAC):

• Набор разрешений. Определяется объектом Role или ClusterRole объектом для разрешений на уровне кластера.

• Привязки, назначающие пользователей и группы, которым разрешено выполнять действия. Определяется объектом RoleBinding или ClusterRoleBinding объектом.

Kubernetes имеет некоторые встроенные роли, такие как администратор кластера, изменение, просмотр и т. д. Привязывайте эти роли к пользователям и группам Microsoft Entra, чтобы использовать корпоративный каталог для управления доступом. Дополнительные сведения см. в разделе "Использование RBAC Kubernetes" с интеграцией Microsoft Entra.

Убедитесь, что группы Microsoft Entra, используемые для доступа к кластеру и пространству имен, включены в проверки доступа Microsoft Entra.

Авторизация Kubernetes с использованием Azure RBAC

Вместо использования kubernetes native RBAC (ClusterRoleBindings и RoleBindings) для авторизации с интегрированной проверкой подлинности Microsoft Entra, еще одним вариантом, который мы рекомендуем, является использование Azure RBAC и назначений ролей Azure для принудительного применения проверка авторизации в кластере. Эти назначения ролей можно даже добавить в подписку или группу ресурсов область, чтобы все кластеры в область наследуют согласованный набор назначений ролей в отношении тех, у кого есть разрешения на доступ к объектам в кластере Kubernetes.

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

Локальные учетные записи

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

В этой эталонной реализации доступ через локальные учетные записи кластера явно отключается при развертывании кластера.

Интеграция идентификатора Microsoft Entra для рабочей нагрузки

Аналогично наличии управляемого удостоверения, назначаемого системой Azure для всего кластера, можно назначить управляемые удостоверения на уровне pod. Удостоверение рабочей нагрузки позволяет размещенной рабочей нагрузке получать доступ к ресурсам с помощью идентификатора Microsoft Entra. Например, рабочая нагрузка хранит файлы в служба хранилища Azure. Когда он должен получить доступ к этим файлам, модуль pod будет проходить проверку подлинности в качестве управляемого удостоверения Azure.

В этой эталонной реализации управляемые удостоверения для модулей pod предоставляются через Идентификация рабочей нагрузки Microsoft Entra в AKS. Это интегрируется с собственными возможностями Kubernetes для федерации с внешними поставщиками удостоверений. Дополнительные сведения о федерации Идентификация рабочей нагрузки Microsoft Entra см. в следующем обзоре.

Развертывание ресурсов входящего трафика

Маршрут ресурсов входящего трафика Kubernetes и распределение входящего трафика в кластер. Существует две части ресурсов входящего трафика:

• Внутренний балансировщик нагрузки. Управляется AKS. Эта подсистема балансировки нагрузки предоставляет контроллер входящего трафика через частный статический IP-адрес. Он служит одной точкой контакта, получающей входящие потоки.

  В этой архитектуре используется Azure Load Balancer. Он размещается за пределами кластера в подсети, выделенной для ресурсов входящего трафика. Он получает трафик от Шлюз приложений Azure и обмен данными через TLS. Сведения о шифровании TLS для входящего трафика см. в разделе "Поток трафика входящего трафика".

• Контроллер входящего трафика. Мы выбрали Траефик. Он выполняется в пуле узлов пользователя в кластере. Он получает трафик от внутренней подсистемы балансировки нагрузки, завершает TLS и перенаправит его в модули pod рабочей нагрузки по протоколу HTTP.

Контроллер входящего трафика является критически важным компонентом кластера. При настройке этого компонента учитывайте эти моменты.

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

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

• Ограничить планирование модулей pod только в пуле узлов пользователей с помощью nodeSelectors. Этот параметр изолирует рабочие нагрузки и системные модули pod.

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

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

• Попробуйте ограничить доступ контроллера входящего трафика к определенным ресурсам и возможность выполнения определенных действий. Это ограничение можно реализовать с помощью разрешений RBAC Kubernetes. Например, в этой архитектуре Traefik было предоставлено разрешение на просмотр, получение и получение и перечисление служб и конечных точек с помощью правил в объекте Kubernetes ClusterRole .

Сведения о структуре входящего трафика, используемой в контейнерах Windows в базовой эталонной архитектуре AKS, см. в статье-компаньоне.

Параметры маршрутизатора

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

Ниже приведен пример из этой архитектуры:

Traefik использует поставщик Kubernetes для настройки маршрутов. tlsentrypoints И annotationsукажите, что маршруты будут обслуживаться по протоколу HTTPS. Указываетmiddlewares, что разрешен только трафик из подсети Шлюз приложений Azure. Ответы будут использовать кодировку gzip, если клиент принимает. Так как Traefik завершает tls, обмен данными со службами серверной части выполняется по протоколу HTTP.

apiVersion:networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: aspnetapp-service
            port: 
              number: 80

защита сетевого потока

Сетевой поток в этом контексте можно классифицировать как:

• Входящий трафик. От клиента к рабочей нагрузке, работающей в кластере.

• Исходящий трафик. Из модуля pod или узла в кластер в внешнюю службу.

• Трафик pod -to-pod. Обмен данными между модулями pod. Этот трафик включает обмен данными между контроллером входящего трафика и рабочей нагрузкой. Кроме того, если рабочая нагрузка состоит из нескольких приложений, развернутых в кластере, обмен данными между этими приложениями будет падать в эту категорию.

• Трафик управления. Трафик, который проходит между клиентом и сервером API Kubernetes.

Скачайте файл Visio для этой архитектуры.

Эта архитектура имеет несколько уровней безопасности для защиты всех типов трафика.

Поток трафика входящего трафика

Архитектура принимает только зашифрованные запросы TLS от клиента. TLS версии 1.2 — это минимальная разрешенная версия с ограниченным набором шифров. Строгое указание имени сервера (SNI). Сквозное подключение TLS настраивается с помощью Шлюз приложений с помощью двух разных сертификатов TLS, как показано на этом рисунке.

Скачайте файл Visio для этой архитектуры.

1. Клиент отправляет HTTPS-запрос на доменное имя: bicycle.contoso.com. Это имя связано с записью DNS A с общедоступным IP-адресом Шлюз приложений Azure. Этот трафик шифруется, чтобы убедиться, что трафик между клиентским браузером и шлюзом не может быть проверен или изменен.

2. Шлюз приложений имеет интегрированный брандмауэр веб-приложения (WAF) и согласовывает подтверждение TLS для bicycle.contoso.com, что позволяет только безопасные шифры. Шлюз приложений — это точка завершения TLS, так как она требуется для обработки правил проверки WAF и выполнения правил маршрутизации, перенаправляющих трафик в настроенную серверную часть. Сертификат TLS хранится в Azure Key Vault. Доступ к нему осуществляется с помощью управляемого удостоверения, назначаемого пользователем, интегрированного с Шлюз приложений. Дополнительные сведения об этой функции см. в разделе "Завершение TLS с помощью сертификатов Key Vault".

3. По мере перемещения трафика из Шлюз приложений в серверную часть он снова шифруется с другим сертификатом TLS (диким карта для *.aks-ingress.contoso.com), так как он перенаправляется во внутреннюю подсистему балансировки нагрузки. Это повторное шифрование гарантирует, что трафик, не защищенный, не передается в подсеть кластера.

4. Контроллер входящего трафика получает зашифрованный трафик через подсистему балансировки нагрузки. Контроллер является еще одной точкой завершения TLS для *.aks-ingress.contoso.com и перенаправит трафик в модули pod рабочей нагрузки по протоколу HTTP. Сертификаты хранятся в Azure Key Vault и подключены к кластеру с помощью драйвера интерфейса служба хранилища контейнера (CSI). Дополнительные сведения см. в разделе "Добавление управления секретами".

Сквозной трафик TLS можно реализовать во всех прыжках через модуль pod рабочей нагрузки. Обязательно измеряйте производительность, задержку и оперативное влияние при принятии решения о защите трафика pod-to-pod. Для большинства кластеров с одним клиентом с соответствующим уровнем управления RBAC и зрелой практикой жизненного цикла разработки программного обеспечения достаточно шифровать tls до контроллера входящего трафика и защищать с помощью Брандмауэр веб-приложений (WAF). Это позволит свести к минимуму затраты на управление рабочими нагрузками и влияние на производительность сети. Требования к рабочей нагрузке и соответствию требованиям определяют, где выполняется завершение TLS.

Исходящий поток трафика

В этой архитектуре рекомендуется использовать весь исходящий трафик из кластера, взаимодействующий через Брандмауэр Azure или собственный виртуальный виртуальный сетевой (модуль), через другие параметры, такие как шлюз NAT или прокси-сервер HTTP. Для контроля нулевого доверия и возможности проверки трафика все исходящие трафик из кластера перемещаются через Брандмауэр Azure. Этот выбор можно реализовать с помощью определяемых пользователем маршрутов (определяемых пользователем). Следующий прыжок маршрута — частный IP-адрес Брандмауэр Azure. Здесь Брандмауэр Azure решает, следует ли блокировать или разрешать исходящий трафик. Это решение основано на конкретных правилах, определенных в Брандмауэр Azure или встроенных правилах аналитики угроз.

Альтернативой использованию Брандмауэр Azure является использование функции ПРОКСИ-сервера HTTP AKS. Для всех исходящих трафика кластера сначала задан IP-адрес HTTP-прокси, который решает перенаправить трафик или удалить его.

В любом из методов просмотрите необходимые правила сети исходящего трафика для AKS.

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

Если Приватный канал или конечные точки службы не являются вариантом, вы можете получить доступ к другим службам через общедоступные конечные точки и управлять доступом с помощью правил Брандмауэр Azure и брандмауэра, встроенного в целевую службу. Так как этот трафик будет проходить через статические IP-адреса брандмауэра, эти адреса можно добавить в список разрешений IP-адресов службы. Одним из недостатков является то, что Брандмауэр Azure должны иметь дополнительные правила, чтобы убедиться, что разрешен только трафик из определенной подсети. Фактор в этих адресах при планировании нескольких IP-адресов для исходящего трафика с Брандмауэр Azure, в противном случае можно достичь исчерпания портов. Дополнительные сведения о планировании нескольких IP-адресов см. в разделе "Ограничить и контролировать исходящий трафик".

Сведения о том, как ознакомиться с рекомендациями по исходящего трафика, используемым в контейнерах Windows в базовой эталонной архитектуре AKS, см. в статье-компаньоне.

Трафик pod -to-pod

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

Включите сетевую политику при подготовке кластера, так как ее нельзя добавить позже. Существует несколько вариантов для технологий, которые реализуют NetworkPolicy. Рекомендуется использовать политику сети Azure, для которой требуется сетевой интерфейс контейнеров Azure (CNI), см. примечание ниже. Другие варианты включают Политику сети Calico, известный вариант с открытым исходным кодом. Если вам нужно управлять политиками сети на уровне кластера, рассмотрите возможность Calico. Калико не охватывается по стандарту поддержка Azure.

Дополнительные сведения см. в разделе "Различия между политикой сети Azure" и политиками Calico и их возможностями.

Трафик управления

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

Дополнительные сведения см. в разделе "Определение авторизованных диапазонов IP-адресов сервера API".

Для дополнительного уровня управления за счет дополнительной сложности можно подготовить частный кластер AKS. Используя частный кластер, вы можете гарантировать, что сетевой трафик между сервером API и пулами узлов остается только в частной сети, он не предоставляется в Интернете. Дополнительные сведения см. в разделе "Частные кластеры AKS".

новые возможности управления секретами

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

Azure Key Vault хорошо интегрирован с другими службами Azure. Используйте встроенную функцию этих служб для доступа к секретам. Пример того, как Шлюз приложений Azure обращается к сертификатам TLS для потока входящего трафика, см. в разделе потока входящего трафика.

Модель разрешений Azure RBAC для Key Vault позволяет назначить удостоверения рабочей нагрузки назначению роли "Секреты Key Vault" или "Читатель Key Vault" и получить доступ к секретам. Дополнительные сведения см. в статье Access Azure Key Vault с помощью RBAC.

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

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

Драйвер CSI имеет множество поставщиков для поддержки различных управляемых хранилищ. В этой реализации мы выбрали Azure Key Vault с драйвером CSI Хранилища секретов с помощью надстройки, чтобы получить сертификат TLS из Azure Key Vault и загрузить его в модуль pod под управлением контроллера входящего трафика. Он выполняется во время создания pod, а том хранит как открытые, так и закрытые ключи.

Хранилище рабочей нагрузки

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

Дополнительные сведения о параметрах хранения см. в разделе служба хранилища варианты приложений в Служба Azure Kubernetes (AKS).

Управление политикой

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

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

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

При настройке политик примените их на основе требований рабочей нагрузки. Учитывайте следующие факторы:

• Вы хотите задать коллекцию политик (называемых инициативами) или выбрать отдельные политики? Политика Azure предоставляет две встроенные инициативы: базовые и ограниченные. Каждая инициатива представляет собой коллекцию встроенных политик, применимых к кластеру AKS. Рекомендуется выбрать инициативу и выбрать дополнительные политики для кластера и ресурсов (ACR, Шлюз приложений, Key Vault и других), взаимодействующих с кластером, в соответствии с требованиями вашей организации.

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

• У вас есть области рабочей нагрузки, которые не должны соответствовать дизайну? Политика Azure имеет возможность указать пространства имен Kubernetes, которые не применяются к политике. Рекомендуется по-прежнему применять политики в режиме аудита , чтобы вы знали об этих экземплярах.

• У вас есть требования, которые не охватываются встроенными политиками? Вы можете создать пользовательское определение Политика Azure, которое применяет пользовательские политики OPA Gatekeeper. Не применяйте настраиваемые политики непосредственно к кластеру. Дополнительные сведения о создании настраиваемых политик см. в статье "Создание и назначение определений настраиваемых политик".

• У вас есть требования на уровне организации? Если да, добавьте эти политики на уровне группы управления. Кластер также должен назначать собственные политики, относящиеся к рабочей нагрузке, даже если у организации есть универсальные политики.

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

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

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

Чтобы узнать, как Политика Azure работает в кластере, вы можете получить доступ к журналам pod для всех модулей pod в gatekeeper-system пространстве имен, а также журналам для azure-policy объектов pod в kube-system пространстве имен.azure-policy-webhook

Дополнительные сведения о Политика Azure, включенных в эталонную архитектуру контейнеров Windows в базовых эталонных архитектурах AKS, см. в статье-компаньоне.

Масштабируемость узлов и pod

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

Существует два подхода: автомасштабирование или ручное масштабирование.

Вручную или программным способом требуется отслеживать и задавать оповещения по использованию ЦП или пользовательским метрикам. Для масштабирования pod оператор приложения может увеличить или уменьшить количество реплика pod, изменив ReplicaSet API Kubernetes. Для масштабирования кластера можно получать уведомления при сбое планировщика Kubernetes. Другим способом является отслеживание ожидающих модулей pod с течением времени. Вы можете настроить количество узлов с помощью Azure CLI или портала.

Автомасштабирование — это рекомендуемый подход, так как некоторые из этих механизмов вручную встроены в автомасштабирование.

В качестве общего подхода начните с тестирования производительности с минимальным количеством модулей pod и узлов. Используйте эти значения, чтобы установить базовое ожидание. Затем используйте сочетание метрик производительности и ручного масштабирования, чтобы найти узкие места и понять ответ приложения на масштабирование. Наконец, используйте эти данные для задания параметров автомасштабирования. Сведения о сценарии настройки производительности с помощью AKS см . в сценарии настройки производительности: распределенные бизнес-транзакции.

Средство горизонтального автомасштабирования объектов pod

Горизонтальное автомасштабирование pod (HPA) — это ресурс Kubernetes, который масштабирует количество модулей pod.

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

HPA может масштабироваться на основе использования ЦП, использования памяти и пользовательских метрик. Только использование ЦП предоставляется вне поля. Определение HorizontalPodAutoscaler указывает целевые значения для этих метрик. Например, спецификация задает целевое использование ЦП. Во время выполнения модулей pod контроллер HPA использует API метрик Kubernetes для проверка использования ЦП каждого модуля pod. Он сравнивает это значение с целевым использованием и вычисляет соотношение. Затем он использует соотношение, чтобы определить, являются ли модули pod общими или недораспределенными. Он использует планировщик Kubernetes для назначения новых модулей pod узлам или удаления модулей pod из узлов.

Может возникнуть состояние гонки, в котором (HPA) проверка до завершения операции масштабирования. Результат может быть неправильным вычислением коэффициента. Дополнительные сведения см. в разделе "Прохладка" событий масштабирования.

Если рабочая нагрузка управляется событиями, популярный вариант с открытым кодом — KEDA. Рассмотрим KEDA, если рабочая нагрузка управляется источником событий, например очередью сообщений, а не привязкой К ЦП или памяти. KEDA поддерживает множество источников событий (или масштабировщиков). Список поддерживаемых масштабировщиков KEDA можно найти здесь, включая масштабировщик Azure Monitor. Удобный способ масштабирования рабочих нагрузок KEDA на основе метрик Azure Monitor.

Средство автомасштабирования кластера

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

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

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

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

Сведения о масштабировании, включенные в контейнеры Windows в базовой эталонной архитектуре AKS, см. в статье-компаньоне.

Решения по непрерывности бизнес-процессов

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

Узлы кластера

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

Изолируйте приложения от системных служб, разместив его в отдельном пуле узлов, называемом пулом узлов пользователя. Таким образом, службы Kubernetes выполняются на выделенных узлах и не конкурируют с рабочей нагрузкой. Использование тегов, меток и фрагментов рекомендуется определить пул узлов для планирования рабочей нагрузки и убедиться, что пул системных узлов запятнан с помощью параметра CriticalAddonsOnly [taint] (/azure/aks/use-system-pool#system-and-user-node-pool-pool).

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

Доступность pod

Убедитесь, что ресурсы pod. Настоятельно рекомендуется, чтобы в развертываниях были указаны требования к ресурсам pod. Тогда планировщик может надлежащим образом запланировать объект pod. Надежность значительно устареет, если модули pod не могут быть запланированы.

Задайте бюджеты нарушений pod. Этот параметр определяет, сколько реплика в развертывании может спуститься во время события обновления или обновления. Дополнительные сведения см. в разделе "Бюджеты нарушений Pod".

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

Задайте квоты ресурсов в пространствах имен рабочей нагрузки. Квота ресурсов для пространства имен обеспечит правильную настройку запросов и ограничений pod в развертывании. Дополнительную информацию см. в разделе Принудительная квота ресурсов.

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

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

Эти ограничения можно указать в манифестах развертывания. Дополнительные сведения см. в разделе "Настройка запросов и ограничений pod".

Поддержка зон доступности и нескольких регионов

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

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

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

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

• Зависимые ресурсы. Чтобы максимально полно использовать преимущество зон, их также должны поддерживать зависимости служб. Если зависимая служба не поддерживает зоны, сбой зоны может привести к сбою этой службы.

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

Для простоты в этой архитектуре AKS развертывается в одном регионе с пулами узлов, охватывающими зоны доступности 1, 2 и 3. Другие ресурсы инфраструктуры, такие как Брандмауэр Azure и Шлюз приложений, развертываются в том же регионе, что и поддержка нескольких зон. Георепликация включена для Реестра контейнеров Azure.

Несколько регионов

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

• Используйте сопряженные регионы. Рассмотрите возможность использования конвейера CI/CD, настроенного для восстановления из-за сбоев в регионе. Преимущество использования парных регионов — надежность во время обновлений. Azure гарантирует, что одновременно обновляется только один регион в паре. Некоторые средства DevOps, такие как Flux, упрощают развертывание в нескольких регионах.

• Если ресурс Azure поддерживает геоизбыточное обеспечение, укажите расположение, в котором у избыточной службы будет ее вторичная. Например, включение гео реплика для Реестр контейнеров Azure автоматически реплика te образов в выбранные регионы Azure и обеспечит непрерывный доступ к изображениям, даже если регион столкнулся с сбоем.

• Выберите маршрутизатор трафика, способный распределять трафик между зонами или регионами, с учетом своих требований. Эта архитектура развертывает службу Azure Load Balancer, так как она может распределять трафик, отличный от веб-трафика, между зонами. Если необходимо распределить трафик между регионами, следует учитывать Azure Front Door. Дополнительные сведения см. в разделе "Выбор подсистемы балансировки нагрузки".

Аварийное восстановление

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

• Используйте сопряженные регионы.

• Рабочую нагрузку без отслеживания состояния можно эффективно реплика. Если вам нужно сохранить состояние в кластере (не рекомендуется), убедитесь, что вы часто выполняете резервное копирование данных в парном регионе.

• Интеграция стратегии восстановления, например реплика ting в другой регион, в рамках конвейера DevOps для удовлетворения целей уровня обслуживания (SLO).

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

Резервное копирование кластера

Для многих архитектур подготовьте новый кластер и верните его в рабочее состояние, можно выполнить с помощью GitOps на основе [начальной загрузки кластера}(#cluster-начальной загрузки) и последующего развертывания приложения. Однако если в процессе начальной загрузки критически важное состояние ресурса, например карты конфигурации, задания и потенциально секреты, которые по какой-то причине не могут быть записаны в процессе начальной загрузки, рассмотрите стратегию восстановления. Обычно рекомендуется запускать рабочие нагрузки без отслеживания состояния в Kubernetes, но если архитектура включает состояние на основе дисков, вам также потребуется рассмотреть стратегию восстановления для этого содержимого.

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

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

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

Выберите и проверьте решение, соответствующее вашей бизнес-цели, включая определенную целевую точку восстановления (RPO) и цель времени восстановления (RTO). Определите этот процесс восстановления в runbook команды и на практике для всех критически важных для бизнеса рабочих нагрузок.

Соглашение об уровне обслуживания сервера API Kubernetes

AKS можно использовать в качестве бесплатной службы, однако эта ценовая категория не предоставляет соглашение об уровне обслуживания с финансовыми гарантиями. Чтобы получить это соглашение об уровне обслуживания, необходимо выбрать уровень "Стандартный". Мы рекомендуем использовать уровень "Стандартный" для всех рабочих кластеров. Резервировать кластеры уровня "Бесплатный" для предварительно рабочих кластеров. В сочетании с Azure Зоны доступности соглашение об уровне обслуживания сервера API Kubernetes увеличивается до 99,95%. Пулы узлов и другие ресурсы имеют собственные соглашения об уровне обслуживания.

Компромиссы

Существует компромисс между затратами и доступностью для развертывания архитектуры в зонах и особенно регионах. Некоторые функции реплика tion, такие как гео-реплика в Реестр контейнеров Azure, доступны в номерах SKU уровня "Премиум", что является более дорогим. Стоимость также увеличится, так как плата за пропускную способность, которая применяется при перемещении трафика между зонами и регионами.

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

Тестирование с моделированием и принудительными переходами на другой ресурс

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

Дополнительные сведения см. в Azure Chaos Studio.

Мониторинг и сбор метрик

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

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

Существуют некоторые сторонние решения, которые интегрируются с Kubernetes, вы можете воспользоваться такими преимуществами, как Datadog, Grafana или New Relic, если ваша организация уже использует их.

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

• Ведение журнала в ClusterAutoscaler для получения наблюдаемости в операциях масштабирования. Дополнительные сведения см. в разделе "Получение журналов и состояния автомасштабирования кластера".
• KubeControllerManager имеет возможность наблюдения за взаимодействием между Kubernetes и плоскостью управления Azure.
• KubeAudit Администратор для наблюдения за действиями, изменяющими кластер. Нет никаких причин иметь как KubeAudit, так и KubeAudit Администратор как KubeAudit, так как KubeAudit является супермножеством KubeAudit Администратор который также включает операции без изменения (чтения).
• Guard записывает идентификатор Microsoft Entra и аудиты Azure RBAC.

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

Хотя Azure Monitor включает набор существующих запросов журналов для начала, их также можно использовать в качестве основы для создания собственных запросов. По мере роста библиотеки можно сохранять и повторно использовать запросы журналов с помощью одного или нескольких пакетов запросов. Настраиваемая библиотека запросов помогает обеспечить дополнительную наблюдаемость в работоспособности и производительности кластеров AKS, а также поддерживать цели уровня обслуживания (SLOS).

Дополнительные сведения о рекомендациях по мониторингу akS см. в статье "Мониторинг Служба Azure Kubernetes (AKS) с помощью Azure Monitor.

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

Включение самовосстановления

Отслеживайте работоспособность модулей pod, задав пробы liveness и готовности. Если обнаружен неподдерживающий модуль pod, Kubernetes перезагрузит модуль pod. Проба активности определяет, является ли модуль pod работоспособным. Если он не отвечает, Kubernetes перезапустит модуль pod. Проверка готовности определяет, готов ли модуль pod получать запросы и трафик.

Обновления кластера AKS

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

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

• Узлы AKS:

  1. Нет или обновление вручную: это для неизменяемой инфраструктуры или если обновления вручную являются предпочтениями. Это обеспечивает более высокую прогнозируемость и контроль над обновлениями узлов AKS.
  2. Автоматическое автоматическое автоматическое обновление: AKS выполняет собственные обновления ОС. Это дает прогнозируемость путем настройки окон обслуживания, согласованных с тем, что хорошо для бизнеса. Это может быть основано на пиковых часах и то, что лучше всего подходит для операций. Уровень управления низкий, так как заранее не удается узнать, что будет специально установлено в узле AKS.
  3. Автоматическое обновление образа узла. Рекомендуется автоматически обновлять образы узлов AKS, когда новые виртуальные жесткие диски (VHD) становятся доступными. Проектирование окон обслуживания для выравнивания как можно больше с бизнес-потребностями. Для обновлений VHD, помеченных безопасностью, рекомендуется настроить ежедневные периоды обслуживания, предоставляющие наименьшую прогнозируемость. Регулярные обновления VHD можно настроить с еженедельной периодом обслуживания, каждые две недели или даже ежемесячно. В зависимости от того, требуется ли наличие меток безопасности и обычных виртуальных жестких жестких систем в сочетании с запланированным периодом обслуживания, прогнозируемость изменяется, обеспечивая большую или меньшую гибкость, чтобы соответствовать бизнес-требованиям. Оставляя это всегда до бизнес-требований, было бы идеальным, реальность предписывает организациям найти точку подсказки. Уровень управления низкий, так как заранее не удается узнать, какие двоичные файлы были включены в новый виртуальный жесткий диск и по-прежнему этот тип автоматических обновлений является рекомендуемым вариантом, так как образы проверяются перед тем, как становятся доступными.

  Примечание.

  Дополнительные сведения о настройке обновлений автоматических узлов AKS см. в руководстве по образам ОС узла автоматического обновления.

• Версия кластера AKS:

  1. Нет или обновление вручную: это для неизменяемой инфраструктуры или если обновления вручную являются предпочтениями. Это обеспечивает более высокую прогнозируемость и контроль над обновлениями версий кластера AKS. Рекомендуется использовать этот вариант, так как это оставляет полный контроль, предоставляя возможность протестировать новую версию кластера AKS (т. е. 1.14.x до 1.15.x) в более низких средах перед попаданием в рабочую среду.
  2. Автоматическое обновление: рабочий кластер не рекомендуется автоматически обновлять или обновляться автоматически (т. е. 1.16.x до 1.16.y) до новой версии кластера AKS, доступной без правильного тестирования в более низких средах. Хотя выпуски Kubernetes вышестоящий и обновления версий кластера AKS координируются с регулярной частотой, рекомендация по-прежнему должна быть обороняться с кластерами AKS в рабочей среде, повышая предсказуемость и контроль над процессом обновления. Против рассмотрения этой конфигурации для более низких сред в рамках операционного превосходства, что позволяет упреждающим выполнением регулярного тестирования обнаруживать потенциальные проблемы как можно раньше.

Обновляйте версию Kubernetes с поддерживаемыми версиями N-2. Обновление до последней версии Kubernetes критически важно, так как новые версии выпускаются часто.

Дополнительные сведения см. в статье "Регулярное обновление до последней версии Kubernetes" и обновление кластера Служба Azure Kubernetes (AKS).

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

Еженедельные обновления

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

Ежедневные обновления

Между обновлениями образа узлы AKS загружают и устанавливают исправления ОС и среды выполнения по отдельности. Для установки может потребоваться перезагрузка виртуальных машин узла. AKS не перезагрузит узлы из-за ожидающих обновлений. У вас есть процесс, отслеживающий узлы для примененных обновлений, требующих перезагрузки и выполняющий перезагрузку этих узлов в управляемом режиме. Параметр с открытым исходным кодом — Kured (управляющая программа перезагрузки Kubernetes).

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

Мониторинг безопасности

Отслеживайте инфраструктуру контейнеров как для активных угроз, так и для потенциальных рисков безопасности:

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

Операции кластера и рабочей нагрузки (DevOps)

Ниже приведены некоторые рекомендации. Дополнительные сведения см. в разделе "Операционное превосходство".

Начальная загрузка кластера

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

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

Процесс начальной загрузки можно настроить с помощью одного из следующих методов:

• Самостоятельная настройка с использованием таких элементов, как Flux или Argo CD
• Pipelines
• Расширение кластера GitOps Flux версии 2

Одним из основных преимуществ использования расширения кластера GitOps Flux версии 2 для AKS является отсутствие пробела между подготовленным кластером и загрузочным кластером. Она устанавливает среду в соответствии с стратегией IaC и поддерживает включение этой начальной загрузки в качестве шаблонов ресурсов.

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

Изоляция обязанностей рабочей нагрузки

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

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

Другой частью может быть интеграция базовой рабочей нагрузки с идентификатором Microsoft Entra.

Использование инфраструктуры в качестве кода (IaC)

Выберите идемпотентный декларативный метод над императивным подходом, где это возможно. Вместо написания последовательности команд, определяющих параметры конфигурации, используйте декларативный синтаксис, описывающий ресурсы и их свойства. Одним из вариантов является шаблоны Azure Resource Manager (ARM ). Другой — Terraform.

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

Если необходимо написать последовательность команд, используйте Azure CLI. Эти команды охватывают ряд служб Azure и могут быть автоматизированы с помощью сценариев. Azure CLI поддерживается в Windows и Linux. Другой кроссплатформенный вариант — Azure PowerShell. Выбор зависит от предпочтительного набора навыков.

Храните и версии скрипты и файлы шаблонов в системе управления версиями.

CI/CD рабочей нагрузки

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

Стратегия развертывания должна включать надежный и автоматизированный конвейер непрерывной доставки (CD). Изменения образов контейнеров рабочей нагрузки должны быть автоматически развернуты в кластере.

В этой архитектуре мы выбрали GitHub Actions для управления рабочим процессом и развертыванием. Другие популярные варианты включают Azure DevOps Services и Jenkins.

Ci/CD кластера

Скачайте файл Visio для этой архитектуры.

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

Важной частью потока CI/CD является начальная загрузка только что подготовленного кластера. Подход GitOps полезен для этого конца, позволяя операторам декларативно определять процесс начальной загрузки в рамках стратегии IaC и просматривать конфигурацию, отраженную в кластере автоматически.

При использовании GitOps агент развертывается в кластере, чтобы убедиться, что состояние кластера координируется с конфигурацией, хранящейся в частном репозитории Git. Один из таких агентов — flux, который использует один или несколько операторов в кластере для активации развертываний внутри Kubernetes. Flux выполняет следующие задачи:

• Отслеживает все настроенные репозитории.
• Обнаруживает новые изменения конфигурации.
• Активирует развертывания.
• Обновления требуемой конфигурации на основе этих изменений.

Вы также можете задать политики, которые управляют развертыванием этих изменений.

Ниже приведен пример, в который показано, как автоматизировать конфигурацию кластера с помощью GitOps и flux:

Скачайте файл Visio для этой архитектуры.

1. Разработчик фиксирует изменения исходного кода, например файлов YAML конфигурации, которые хранятся в репозитории Git. Затем изменения отправляются на сервер Git.

2. Flux выполняется в pod вместе с рабочей нагрузкой. Flux имеет доступ только для чтения к репозиторию Git, чтобы убедиться, что Flux применяет изменения только по запросу разработчиков.

3. Flux распознает изменения в конфигурации и применяет эти изменения с помощью команд kubectl.

4. Разработчики не имеют прямого доступа к API Kubernetes через kubectl.

5. У вас есть политики ветвей на сервере Git. Таким образом, несколько разработчиков могут утвердить изменение с помощью запроса на вытягивание перед применением к рабочей среде.

Хотя GitOps и Flux можно настроить вручную, для AKS рекомендуется использовать расширение кластера GitOps с расширением кластера Flux версии 2.

Стратегии развертывания рабочей нагрузки и кластера

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

Запустите тесты и проверки на каждом этапе перед переходом к следующему, чтобы убедиться, что вы можете отправлять обновления в рабочую среду строго контролируемым способом и свести к минимуму прерывание с непредвиденными проблемами развертывания. Это развертывание должно соответствовать аналогичному шаблону, как рабочей среде, используя те же конвейеры GitHub Actions или операторы Flux.

Для расширенных методов развертывания, таких как развертывание Blue-green, тестирование A/B и канарийные выпуски, потребуется дополнительный процесс и потенциально инструментирование. Flagger — это популярное решение с открытым исходным кодом для решения сложных сценариев развертывания.

Управление затратами

Начните с просмотра проекта оптимизации затрат проверка списка и списка рекомендаций, описанных в хорошо спроектированной платформе для AKS. Используйте калькулятор цен Azure для оценки затрат на службы, используемые в архитектуре. Другие рекомендации описаны в разделе "Оптимизация затрат" в Microsoft Azure Well-Architected Framework.

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

Сведения об управлении затратами, относящиеся к рабочим нагрузкам на основе Windows, включенным в контейнеры Windows в базовой эталонной архитектуре AKS, см. в статье-компаньоне.

Подготовка

• В кластере Kubernetes нет затрат, связанных с AKS в развертывании, управлении и операциях кластера Kubernetes. Что влияет на затраты, это экземпляры виртуальных машин, хранилище, данные журнала и сетевые ресурсы, потребляемые кластером. Рассмотрите возможность выбора более дешевых виртуальных машин для пулов системных узлов. Номер SKU DS2_v2 — это типичный тип виртуальной машины для пула системных узлов.

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

• Для рабочих нагрузок добавьте соглашение об уровне обслуживания от простоя. Однако существует экономия кластеров, предназначенных для разработки и тестирования или экспериментальных рабочих нагрузок, в которых доступность не требуется. Например, SLO достаточно. Кроме того, если ваша рабочая нагрузка поддерживает ее, рассмотрите возможность использования выделенных пулов точечных узлов, на которые выполняются виртуальные машины с точечными виртуальными машинами.

  Для нерабочих рабочих нагрузок, которые включают База данных SQL Azure или службу приложение Azure в рамках архитектуры рабочей нагрузки AKS, оцените, имеет ли вы право использовать подписки Azure Dev/Test для получения скидок на обслуживание.

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

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

• Включение диагностика в кластере может увеличить затраты.

• Если ожидается, что рабочая нагрузка существует в течение длительного периода, можно зафиксировать один или три года зарезервированных экземпляров виртуальных машин, чтобы сократить затраты на узлы. Дополнительные сведения см. в разделе "Зарезервированные виртуальные машины".

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

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

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

Azure Monitor

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

• Помощник по Azure

• Управление затратами Azure

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

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

Оптимизация

Действовать по рекомендациям, предоставляемым помощником По Azure. Существуют другие способы оптимизации:

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

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

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

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

Сведения о других затратах см. в разделе о ценах AKS.

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

Продолжить изучение базовой архитектуры AKS:

• Дополнительные сведения о размещении микрослужб в базовой базе AKS см. в статье "Расширенная архитектура микрослужб Служба Azure Kubernetes (AKS).
• Сведения о развертывании базовых показателей AKS в нескольких регионах см . в базовых показателях AKS для кластеров с несколькими регионами.
• Сведения о развертывании базовых показателей AKS в среде PCI-DSS 3.2.1 см . в регламентируемом кластере AKS для PCI-DSS 3.2.1.
• Дополнительные сведения о добавлении контейнеров Windows в эталонную архитектуру см. в статье о контейнерах Windows в базовой эталонной архитектуре AKS.

Подробнее об AKS

• Ознакомьтесь с планом разработки продуктов AKS, см. Служба Azure Kubernetes "Стратегия развития" на сайте GitHub.
• Если вам требуется обновление в Kubernetes, выполните инструкции в Kubernetes и разработка и развертывание приложений на схемах обучения Kubernetes.

Связанные ресурсы

Ознакомьтесь со следующими руководствами.

• Обзор Azure Well-Architected Framework для Служба Azure Kubernetes (AKS)
• Акселератор целевой зоны AKS, который является реализацией корпоративного масштаба на основе этой архитектуры. Акселератор помогает настроить среду Azure в согласованном и повторяющемся режиме с помощью инфраструктуры как кода (IaC) для развертывания Служба Azure Kubernetes (AKS).
• Руководство по работе со Службой контейнеров Azure, день 2

См. следующие связанные архитектуры:

• Архитектура микрослужб в Службе Azure Kubernetes
• Использование Брандмауэр Azure для защиты кластера Служба Azure Kubernetes (AKS)
• GitOps для Служба Azure Kubernetes
• Потоковая передача данных с помощью AKS