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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Операции

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

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

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

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

• Свести к минимуму прямое воздействие ресурсов Azure на общедоступный Интернет.

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

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

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

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

• Поддержка совместного использования ресурсов, таких как брандмауэр и зоны DNS- системы доменных имен.

• Выравнивайте целевую зону azure корпоративного масштаба.

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

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

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

Центральная виртуальная сеть.

Виртуальная сеть концентратора — это центральная точка подключения и наблюдаемости. В этой архитектуре концентратор содержит следующее:

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

В сети архитектура имеет три подсети.

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

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

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

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

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

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

Периферийная виртуальная сеть

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

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

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

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

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

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

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

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

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

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

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

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

Эта эталонная архитектура использует несколько сетевых подходов, каждый из которых требует пространства IP-адресов:

• Виртуальная сеть Azure, которая используется для ресурсов, таких как узлы кластера, частные конечные точки и Шлюз приложений.
• В кластере используется наложение Azure CNI, которое выделяет IP-адреса для модулей pod из отдельного адресного пространства в виртуальную сеть Azure.

Пространство IP-адресов виртуальной сети

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

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

  В этой архитектуре модули pod выделяютСЯ IP-адреса из адресного пространства наложения Azure CNI, включая во время последовательного обновления. Этот подход сокращает общее количество IP-адресов, используемых из виртуальной сети Azure, по сравнению с другими сетевыми подходами Kubernetes.

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

  Так как эта архитектура использует наложение Azure CNI, масштабируемость модулей pod не влияет на адресное пространство виртуальной сети.

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

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

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

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

Пространство IP-адресов pod

Наложение Azure CNI назначает IP-адреса модулям pod с помощью выделенного адресного пространства, которое отделяется от адресного пространства, используемого в виртуальной сети. Используйте пространство IP-адресов, которое не перекрывается с виртуальной сетью или любыми пиринговыми виртуальными сетями. Однако при создании нескольких кластеров AKS можно безопасно использовать одно адресное пространство pod в каждом кластере.

Каждому узлу назначается адресное пространство /24 для своих модулей pod, поэтому важно убедиться, что адресное пространство pod достаточно большое, чтобы разрешить столько блоков /24, сколько необходимо для количества узлов в кластере. Не забудьте включить временные узлы, созданные во время обновлений или горизонтального масштабирования. Например, если для диапазона CIDR используется адресное пространство /16, кластер может увеличиться до не более 250 узлов.

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

Дополнительные сведения см . в руководстве по планированию IP-адресов для наложения azure CNI

Другие рекомендации по пространству IP-адресов

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

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

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

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

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

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

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

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

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

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

• Импортируйте общедоступный образ в реестр контейнеров, который соответствует цели уровня обслуживания (SLO), если вы используете общедоступный образ. В противном случае образ может быть подвержен непредвиденным проблемам доступности. Если образ недоступен при необходимости, это может вызвать операционные проблемы. Ниже приведены некоторые преимущества использования частного реестра контейнеров, например Реестр контейнеров Azure, а не общедоступного реестра:

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

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

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

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

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

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

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

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

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

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

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

Выбор операционной системы

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

AKS также поддерживает пулы узлов, работающие под управлением операционной системы Windows Server. Существуют особые требования для некоторых аспектов кластера под управлением Windows. Дополнительные сведения об архитектуре пула узлов Windows см. в статье "Запуск контейнеров Windows в AKS".

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

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

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

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

Доступ AKS к Azure

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

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

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

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

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

В этой архитектуре кластер обращается к ресурсам Azure, защищенным идентификатором Microsoft Entra ID, и кластер выполняет операции, поддерживающие управляемые удостоверения. Назначьте управление доступом на основе ролей 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 двумя способами. Первое — использование идентификатора 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

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

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

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

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

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

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

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

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

Выбор сетевой модели

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

В модели CNI, отличной от наложения, каждый модуль pod получает IP-адрес из адресного пространства подсети. Ресурсы в одной сети (или одноранговые ресурсы) могут обращаться к модулям pod напрямую через их IP-адрес. Преобразование сетевых адресов (NAT) не требуется для маршрутизации этого трафика.

В этой эталонной реализации мы используем наложение Azure CNI, которое выделяет только IP-адреса из подсети пула узлов для узлов и использует высокооптимичный слой наложения для IP-адресов pod. Так как наложение Azure CNI использует меньше IP-адресов виртуальной сети, чем многие другие подходы, мы рекомендуем использовать его для развертывания с ограниченным IP-адресом.

Сведения о моделях см. в разделе "Выбор сетевого интерфейса контейнера" для использования и сравнения моделей сети kubenet и Azure Container Network Interface.

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

Ресурсы входящего трафика Kubernetes обрабатывают маршрутизацию и распределение входящего трафика в кластер. Существует две части ресурсов входящего трафика:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Traefik использует поставщик Kubernetes для настройки маршрутов. tlsПараметры annotationsи entrypoints параметры указывают, что маршруты обслуживаются по протоколу HTTPS. Параметр middlewares указывает, что разрешен только трафик из подсети Шлюз приложений. Ответы используют кодировку 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-адресом Шлюз приложений. Этот трафик шифруется, чтобы обеспечить невозможность проверки или изменения трафика между клиентским браузером и шлюзом.

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

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

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

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

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

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

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

Альтернативой Брандмауэр Azure является использование функции прокси-сервера HTTP AKS. Весь трафик, который покидает кластер, переходит к IP-адресу HTTP-прокси, который перенаправит трафик или удаляет его.

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

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

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

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

Трафик pod -to-pod

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для управления кластерами AKS можно использовать Политика Azure для:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы обеспечить непрерывность бизнес-процессов, определите SLO для инфраструктуры и приложения. Дополнительные сведения см . в рекомендациях по определению целевых показателей надежности. Ознакомьтесь с условиями соглашения об уровне обслуживания (SLA) для AKS в последней статье об уровне обслуживания для веб-службы статьи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Компромиссы

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

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

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

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

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

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

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

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

Некоторые решения, отличные от Майкрософт, интегрируются с Kubernetes, например Datadog, Grafana или New Relic. Таким образом, если ваша организация уже использует эти решения, вы можете воспользоваться ими.

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

• ClusterAutoscaler: получение наблюдаемости в операциях масштабирования с помощью ведения журнала. Дополнительные сведения см. в разделе "Получение журналов и состояния автомасштабирования кластера".
• KubeControllerManager: получите возможность наблюдения за взаимодействием между Kubernetes и плоскостью управления Azure.
• kube-audit-admin: получение наблюдаемости в действиях, изменяющих кластер. Нет никаких причин, чтобы иметь оба kube-audit и kube-audit-admin включить. kube-audit — это супермножество kube-audit-admin , которое также включает немодифицировать (чтение) операции.
• guard: захват идентификатора Microsoft Entra и аудита Azure RBAC.

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

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

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

Дополнительные сведения о рекомендациях по мониторингу windows см. в разделе "Контейнеры Windows" в AKS.

Сетевые метрики

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

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

Для рабочих нагрузок, которые очень чувствительны к протоколу управления передачей (TCP) или протоколу UDP, потере пакетов, задержке или давлению DNS, важны метрики сети уровня pod. В AKS можно найти этот уровень детализации с помощью расширенной функции наблюдения за сетями. Большинство рабочих нагрузок не требуют этой глубины наблюдаемости сети. Невозможно включить расширенную сетевую наблюдаемость, если модули pod не требуют высокооптимизируемой сети с конфиденциальностью до уровня пакета.

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

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

Стандартные обновления для кластеров AKS

Часть операций day-2 для кластеров Kubernetes — выполнение стандартных обновлений платформы и операционной системы. Существует три уровня обновлений для адресов в каждом кластере AKS:

• Версия Kubernetes (например, Kubernetes 1.30.3 до 1.30.7 или Kubernetes 1.30.7 до 1.31.1), которая может быть связана с изменениями и отменами API Kubernetes. Изменения версий на этом уровне влияют на весь кластер.
• Образ виртуального жесткого диска (VHD) на каждом узле, который объединяет обновления операционной системы и обновления компонентов AKS. Эти обновления тестируются в версии Kubernetes кластера. Изменения версий на этом уровне применяются на уровне пула узлов и не влияют на версию Kubernetes.
• Собственный процесс обновления операционной системы, например Обновл. Windows или apt. Поставщик операционной системы предоставляет эти обновления напрямую, и они не тестируются в версии Kubernetes кластера. Изменения версий на этом уровне влияют на один узел и не влияют на версию Kubernetes.

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

Подробные сведения о исправлении и обновлении см. в руководстве по исправлению и обновлению AKS в руководстве по операциям AKS.2. Используйте следующую информацию для базовых рекомендаций, так как она относится к этой архитектуре.

Неизменяемая инфраструктура

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

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

Обновления на месте

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

• Запланируйте функцию планового обслуживания AKS, чтобы управлять обновлениями в кластере. Эта функция позволяет выполнять обновления( по сути рискованные операции) в управляемое время, чтобы уменьшить влияние неожиданного сбоя.
• Настройте бюджеты нарушений pod, чтобы приложение оставалось стабильным во время последовательного обновления. Но не настраивайте бюджеты настолько агрессивными, что они блокируют обновление узлов, так как большинство обновлений требуют кордона и очистки процесса на каждом узле.
• Подтвердите квоту ресурсов Azure и доступность ресурсов. Обновления на месте развертывают новые экземпляры узлов, известные как узлы всплеска, до удаления старых узлов. Это означает, что квота Azure и пространство IP-адресов должны быть доступны для новых узлов. Всплеск значения 33% является хорошей отправной точкой для большинства рабочих нагрузок.
• Проверка совместимости с средствами, такими как сетки служб или агенты безопасности, добавленные в кластер. И протестируйте компоненты рабочей нагрузки, такие как контроллеры входящего трафика, сетки служб и модули pod рабочей нагрузки. Выполняйте тесты в предварительной среде.

Обновления на месте для узлов

Используйте канал автоматического NodeImage обновления для обновлений образа ОС узла. Этот канал настраивает кластер для обновления виртуального жесткого диска на каждом узле с обновлениями на уровне узла. Корпорация Майкрософт проверяет обновления для вашей версии AKS. Для узлов Windows обновления происходят примерно один раз в месяц. Для узлов Linux эти обновления происходят примерно один раз в неделю.

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

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

Большинство кластеров, выполняющих обновление на месте, должны избежать None Unmanaged параметров канала обновления образа узла.

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

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

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

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

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

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

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

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

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

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

Рекомендации по работе с кластерами и рабочими нагрузками (DevOps) см. в разделе "Принципы проектирования операционного превосходства".

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

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

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

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

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

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

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

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

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

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

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

Использование IaC

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

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

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

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

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

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

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

В этой архитектуре GitHub Actions управляет рабочим процессом и развертыванием. Другие популярные варианты включают Azure DevOps и 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.

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

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

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

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

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

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

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

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

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

Сведения об управлении затратами для Windows см. в разделе "Контейнеры Windows" в AKS.

Подготовка

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

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

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

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

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

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

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

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

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

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

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

Azure Monitor

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

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

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

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

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

Оптимизация

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

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

  Внимание

  Агрессивно изменяя параметры автомасштабирования кластера, такие как минимальные и максимальные параметры узла для пула узлов, чтобы повлиять на затраты, могут иметь контрпродуктивные результаты. Например, если scale-down-unneeded-time задано значение 10 минут, а минимальные и максимальные параметры узлов изменяются каждые пять минут на основе характеристик рабочей нагрузки, количество узлов никогда не уменьшится. Это связано с тем, что вычисление ненужимого времени для каждого сброса узла из-за обновляемых параметров автомасштабирования кластера.

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

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

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

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

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

• Расширенная архитектура микрослужб AKS
• Базовые показатели AKS для кластеров с несколькими агрегатами
• Регулируемый кластер AKS для PCI-DSS 3.2.1
• Эталонная архитектура контейнеров Windows в базовой архитектуре AKS

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

• Стратегия AKS на GitHub
• Введение в Kubernetes
• Разработка и развертывание приложений в Kubernetes
• Обзор хорошо архитектора платформы для AKS
• Акселератор целевой зоны AKS
• Руководство по операциям AKS-2
• Архитектура микрослужб в AKS
• Использование Брандмауэра Azure для защиты кластера AKS
• Операции Git для AKS
• Потоковая передача данных с помощью AKS