Базовая архитектура для кластера Службы 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 для рабочей нагрузки

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

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

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

Масштабируемость узлов и подов
Решения по непрерывности бизнес-процессов
Зоны доступностиНесколько регионов

Operations

Операции кластера и рабочей нагрузки
Мониторинг и сбор журналов и метрик
Управление затратами

Architecture

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Брандмауэр Azure с глобальными политиками брандмауэра, которые центральные ИТ-группы определяют для применения правил всей организации.

• Бастион Azure, который устанавливает безопасный туннель в периметр частной сети, чтобы можно было выполнять операции управления кластерами.

• Шлюзовая подсеть для подключения к VPN

• Azure Monitor для отслеживания сети

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подсеть для сервера API AKS

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

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

С помощью частного кластера можно использовать сетевые группы безопасности (NSG) и другие встроенные сетевые элементы управления для защиты среды. Эта конфигурация запрещает любой несанкционированный общедоступный доступ между Интернетом и средой. Дополнительные сведения см. в статье Создание частного кластера AKS.

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

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

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

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

• В кластере используется наложение интерфейса сети контейнеров Azure (CNI), которое выделяет IP-адреса для подов из отдельного адресного пространства, отличного от вашей виртуальной сети 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В AKS каждый пул узлов обычно соответствует масштабируемому набору виртуальных машин. Узлы — это виртуальные машины в каждом пуле узлов.

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

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

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

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

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

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

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

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

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

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

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

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

Защита доступа к кластеру и из нее критически важна. Используйте перспективу кластера, чтобы понять разницу между внутренним и внешним трафиком:

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

• Доступ извне: Предоставьте идентификаторам доступ к кластеру Kubernetes. Авторизуйте только те внешние сущности, которым разрешен доступ к серверу API Kubernetes и Azure Resource Manager.

Доступ AKS к компонентам Azure

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

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

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

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

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

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

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

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

• Роль издателя метрик мониторинга управляет способностью кластера отправлять метрики в Azure Monitor.

• Роль AcrPull управляет способностью кластера извлекать образы из указанных экземпляров реестра контейнеров.

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

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

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

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

Kubernetes поддерживает RBAC через следующие объекты API:

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

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

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

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

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

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

Мы не рекомендуем использовать RBAC на основе Kubernetes с ClusterRoleBindings и RoleBindings.

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

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

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

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

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

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

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

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

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

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

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

Дополнительные сведения о моделях см. в статье "Настройка сети наложения Azure CNI" в AKS и рекомендации по обеспечению сетевого подключения и безопасности в AKS.

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

Ресурсы входящего трафика 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 .

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

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

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

Traefik использует поставщик Kubernetes для настройки маршрутов. annotationsПараметры tlsи 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-прокси , так как они не предоставляют проверку сетевого трафика. Для контроля нулевого доверия и возможности проверки трафика отправьте весь исходящий трафик через брандмауэр Azure. Реализуйте эту конфигурацию с маршрутами, определяемыми пользователем. Следующий прыжок маршрута — частный IP-адрес Брандмауэр Azure. Брандмауэр Azure решает, следует ли блокировать или разрешать исходящий трафик на основе правил, определяемых или встроенных правил аналитики угроз.

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

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

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

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

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

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

Трафик pod -to-pod

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

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

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

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

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

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

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

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

• Используйте Бастион Azure для открытия туннеля непосредственно на сервер API AKS.
• Подготовьте виртуальную машину типа jump-box и подключитесь к ней через Azure Bastion (Азур Бастион).

В эталонной реализации мы используем Бастион Azure для туннелирования на сервер API AKS при выполнении операций управления кластерами.

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

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

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

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

Модель разрешений Azure RBAC для Key Vault позволяет назначить удостоверения рабочей нагрузки назначению роли "Секреты Key Vault" или "Читатель Key Vault" и получить доступ к секретам. Дополнительные сведения см. в разделе Access Key Vault с помощью Azure 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 и заблокировать развертывание ненадежных образов контейнеров в кластере. Дополнительные сведения см. в шаблоне карантина.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Средство горизонтального автомасштабирования объектов 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 из-за ограничений ресурсов, автомасштабирование автоматически настраивает новый узел в пуле узлов. И наоборот, средство автомасштабирования кластера проверяет неиспользуемую емкость узлов. Если узел не работает с ожидаемой нагрузкой, поды перемещаются на другой узел, и такой узел удаляется.

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

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

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

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

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

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

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

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

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

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

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

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

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

  Note

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

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

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

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

Зоны доступности

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

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

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

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

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

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

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

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

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

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

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

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

Восстановление после катастрофы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Компромисс

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

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

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

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

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

Мониторинг и сбор журналов и метрик

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

Включение сбора журналов из модулей pod

Схема журнала containerLogV2 предназначена для сбора журналов контейнеров из модулей pod Kubernetes в упрощенном подходе. Записи журнала объединяются в таблицу ContainerLogV2 в рабочей области Azure Log Analytics.

В кластере AKS есть два основных метода настройки коллекции журналов pod. Оба подхода позволяют настраивать параметры. Можно отфильтровать пространства имен, настроить интервалы сбора, включить или запретить определенные функции (например ContainerLogV2 , или ContainerLogV2-HighScale) и указать, какие потоки данных следует собирать.

• Если требуется централизованная, повторно используемая конфигурация мониторинга в нескольких кластерах или предпочитаемая конфигурация кластера для внешнего использования в собственных ресурсах Azure, используйте правила сбора данных (DCR). Правила сбора данных (DCR) — это ресурсы Azure, которыми непосредственно управляет контрольная плоскость Azure Resource Manager, и их можно включить в файлы Bicep. Эталонная реализация использует DCRs.

• Кроме того, можно определить мониторинг с помощью ConfigMaps, которые являются неконфидентными объектами YamL Kubernetes, настроенными с помощью плоскости управления API Kubernetes. Агент Azure Monitor, работающий на мониторах кластера для объектов ConfigMap. Он использует предопределенные параметры для определения собираемых данных.

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

Оповещения и метрики Prometheus

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

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

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

Журналы плоскости управления и инфраструктуры Azure и Kubernetes

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

• ClusterAutoscaler: Обеспечьте видимость операций масштабирования посредством ведения журнала. Дополнительные сведения см. в разделе "Получение журналов и состояния автомасштабирования кластера".

• KubeControllerManager: Обеспечение видимости взаимодействия между Kubernetes и контрольной плоскостью Azure.

• kube-audit-admin: обеспечение наблюдаемости за действиями, которые изменяют кластер. Нет необходимости включать как kube-audit, так и kube-audit-admin, потому что kube-audit является надмножеством, которое также включает немодифицирующие (чтение) операции.

• guard: захват идентификатора Microsoft Entra и аудита Azure RBAC.

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

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

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

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

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

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

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

Оптимизация затрат для ведения журнала

Эталонная реализация настраивает таблицу ContainerLogV2 для использования плана Basic в качестве отправной точки. Microsoft Defender для контейнеров и оповещения, созданные для эталонной реализации, не запрашивают эту таблицу, поэтому базовый план, скорее всего, будет экономически эффективным, так как снижает затраты на прием.

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

Дополнительные сведения см. в статье Выбор плана таблицы на основе использования данных в рабочей области Log Analytics.

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

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

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

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

• Версия Kubernetes (например, Kubernetes 1.32.3 до 1.32.7 или Kubernetes 1.32.7 до 1.33.1), которой могут сопровождаться изменения и устаревания API Kubernetes. Изменения версий на этом уровне влияют на весь кластер.

• Образ виртуального жесткого диска (VHD) на каждом узле, который объединяет обновления операционной системы и обновления компонентов AKS. Эти обновления тестируются в версии Kubernetes кластера. Изменения версий на этом уровне применяются на уровне пула узлов и не влияют на версию Kubernetes.

• Процесс обновления, встроенный в операционную систему, например, Windows Update или apt. Поставщик операционной системы предоставляет эти обновления напрямую, и они не тестируются в версии Kubernetes кластера. Изменения версий на этом уровне влияют на один узел и не влияют на версию Kubernetes.

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

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

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

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

Когда нужное обновление станет доступным, необходимо выполнить следующие действия.

1. Проверьте обновление в предварительной среде и оцените ее совместимость в новом кластере.

2. Разверните производственный стамп реплики, включающий обновленную версию AKS и VHD пула узлов.

3. Когда новый рабочий кластер будет готов, очистите старый кластер и в конечном итоге выведите его из эксплуатации.

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

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

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

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

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

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

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

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

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

• Обновления никогда не изменяют версию AKS или Kubernetes, поэтому совместимость API Kubernetes не является проблемой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ci/CD кластера

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

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

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

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

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

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

На следующей схеме показано, как автоматизировать конфигурацию кластера с помощью GitOps и Flux.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Provision

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

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

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

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

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

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

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

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

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

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

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

Monitor

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

• Помощник по Azure
• Управление затратами

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

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

Optimize

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

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

  Important

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

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

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

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

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

Дальнейшие шаги

• Стратегия AKS на GitHub
• Акселератор целевой зоны AKS

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

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