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

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

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

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

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

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

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

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

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

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

Управление идентичностью

Интегрируйте Microsoft Entra ID в кластер
Интегрируйте Microsoft Entra ID для нагрузки

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

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

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

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

Operations

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

Architecture

схема

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

Дополнительные сведения см. в разделе Концентраторно-спице-периферийной топологии сети в Azure.

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

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

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

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

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

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

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

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

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

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

Виртуальная сеть концентратора

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

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

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

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

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

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

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

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

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

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

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

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

Спиковая виртуальная сеть

Спицевая виртуальная сеть содержит кластер AKS и другие связанные ресурсы. У узла есть следующие подсети.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Кластер использует Azure Container Networking Interface (CNI) Overlay, который выделяет IP-адреса для модулей из отдельного адресного пространства для вашей виртуальной сети Azure.

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

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

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

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

• Масштабируемость: Рассмотрим общее количество системных и пользовательских узлов и их максимальное ограничение масштабируемости. Например, если вы хотите увеличить масштаб на 400%, необходимо в четыре раза больше адресов для всех узлов после масштабирования.

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

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

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

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

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

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

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

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

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

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

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

Другие соображения по пространству IP-адресов

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

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

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

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

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

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

Ссылка на образ контейнера

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

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

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

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

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

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

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

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

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

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

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

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

• Inside-out access: рассмотрим доступ AKS к компонентам Azure, таким как сетевая инфраструктура, реестр контейнеров и Key Vault. Предоставьте доступ только к тем ресурсам, к которым кластер должен иметь доступ.

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

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

Существует два способа управления доступом AKS к Azure через Microsoft Entra ID: учетные записи служб или управляемые удостоверения для ресурсов Azure.

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

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

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

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

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

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

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

• Роль Publisher Monitoring Metrics управляет способностью кластера отправлять метрики в Azure Monitor.

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

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

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

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

Связывание Kubernetes RBAC с Microsoft Entra ID

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

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

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

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

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

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

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

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

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

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

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

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

Интеграция Microsoft Entra ID с рабочими нагрузками

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

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

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

AKS предоставляет плагины интерфейса контейнерной сети (CNI) в двух сетевых моделях: оверлей и флэт. Обе модели поддерживают политики сети для управления трафиком в кластере.

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

Эта эталонная реализация использует Azure CNI Overlay, который является сетевым подключаемым модулем наложения. Он выделяет IP-адреса виртуальной сети только узлам и назначает IP-адреса pod из отдельного диапазона CIDR. Поскольку наложение Azure CNI потребляет гораздо меньше IP-адресов виртуальной сети, чем плоские модели, мы рекомендуем его для большинства развертываний.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Трафик pod-to-pod

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

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

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

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

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

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

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

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

• Tunnelling: Используйте Бастион Azure, чтобы открыть туннель непосредственно к API-серверу кластера.
• Jump-box: Подготовьте виртуальную машину для перехода и используйте Бастион Azure для подключения к нему через SSH или RDP. Оттуда оператор выполняет запросы к серверу API кластера через частный IP-адрес.

В эталонной реализации мы используем Бастион Azure для туннелирования на сервер API AKS при выполнении операций управления кластерами. Как правило, этим подходом проще управлять, он менее дорогостоящий, чем развертывание и управление виртуальной машиной для прыжка, и легче координировать между несколькими операторами. Однако вы можете использовать jump-box виртуальную машину, если у вас есть какие-либо из следующих требований:

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

Добавить управление секретами

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

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

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

секреты кластера Access

Необходимо использовать удостоверения рабочей нагрузки, чтобы под мог получить доступ к секретам из определенного хранилища. Чтобы упростить процесс извлечения, используйте драйвер 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 и заблокировать развертывание ненадежных образов контейнеров в кластере. Дополнительные сведения см. в шаблоне Quarantine.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Горизонтальное автомасштабирование Pod

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

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

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

Состояние гонки может произойти, например при проверке HPA до завершения операции масштабирования. Таким образом, результат может быть неправильным вычислением коэффициента. Более подробную информацию см. в разделе Cooldown событий масштабирования.

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

Автоматическое масштабирование кластера

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

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

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

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

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

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

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

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

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

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

Доступность модуля

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

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

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

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

  Note

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

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

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

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

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

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

• Entire infrastructure: Выберите регион, который поддерживает зоны доступности. Дополнительные сведения см. в разделе Limitations. Чтобы иметь SLA на время безотказной работы, вам необходимо выбрать стандартный или премиальный уровень. Уровень доступности выше, если вы используете зоны доступности.

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

  Зональная избыточность действует не только для пулов узлов, но и для плоскости управления. Плоскость управления 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 в качестве бесплатной службы, но этот уровень не предоставляет финансово поддерживаемое соглашение об уровне обслуживания. Чтобы получить соглашение об уровне обслуживания, необходимо выбрать уровень Standard. Мы рекомендуем, чтобы все рабочие кластеры использовали уровень "Стандартный". Зарезервировать уровень "Бесплатный" для предпроизводственных кластеров и уровень "Премиум" только для критически важных задач. При использовании зон доступности Azure уровень обслуживания сервера API Kubernetes выше. Пулы узлов и другие ресурсы охватываются собственными соглашениями об уровне обслуживания.

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

Компромисс

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

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

Тестирование с симуляциями и принудительными аварийными переключениями

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• guard: Сбор аудитов Microsoft Entra ID и Azure RBAC.

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

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

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

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

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

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

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

Оптимизация затрат на логгирование

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

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

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

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

Отслеживайте работоспособность модулей, задав пробы жизнеспособности и готовности. Если Kubernetes обнаруживает неподответственный модуль 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 или apt. Поставщик операционной системы предоставляет эти обновления напрямую, и они не проходят тестирование на совместимость с версией Kubernetes кластера. Изменения версий на этом уровне влияют на один узел и не влияют на версию Kubernetes.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Еще одной задачей является интеграция базовой рабочей нагрузки с Microsoft Entra ID.

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

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

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

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

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

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

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

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

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

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

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

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

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

Provision

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

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

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

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

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

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

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

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

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

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

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

Monitor

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

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

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

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

Optimize

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

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

  Important

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

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

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

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

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

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

• дорожная карта AKS на GitHub

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

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