Оптимизация затрат в Служба Azure Kubernetes (AKS)

  • Статья

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

В этой статье раскрываются следующие темы:

  • Выбор стратегической инфраструктуры.
  • Динамическое масштабирование и автомасштабирование.
  • Использование скидок Azure для существенной экономии.
  • Целостные методики мониторинга и FinOps.

Подготовка среды приложения

Оценка семейства SKU

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

Семейство SKU Description Вариант использования
точечные виртуальные машины Azure. Масштабируемые масштабируемые виртуальные машины Azure возвращают пулы точечных узлов и развертываются в одном домене сбоя без гарантий высокого уровня доступности или соглашения об уровне обслуживания. Точечные виртуальные машины позволяют воспользоваться неиспользуемой емкостью Azure со значительными скидками (до 90 %, по сравнению с ценами по мере использования). Если Azure нуждается в емкости, инфраструктура Azure вытесняет точечные узлы. Лучше всего подходит для сред разработки и тестирования, рабочих нагрузок, которые могут обрабатывать прерывания, такие как задания пакетной обработки и рабочие нагрузки с гибким временем выполнения.
Процессоры на основе Ampere Altra Arm (Arm64) Виртуальные машины Arm64 являются эффективными и экономичными, но не компрометируют производительность. Благодаря поддержке пула узлов Arm64 в AKS можно создавать узлы агента Ubuntu Arm64 и даже смешивать узлы архитектуры Intel и ARM в кластере. Эти виртуальные машины ARM предназначены для эффективного выполнения динамических масштабируемых рабочих нагрузок и могут обеспечить до 50 % более высокую производительность по цене, чем сопоставимые виртуальные машины на основе x86 для масштабируемых рабочих нагрузок. Лучше всего подходит для серверов веб-приложений, баз данных с открытым исходным кодом, облачных приложений, игровых серверов и т. д.
Оптимизированные номера SKU gpu В зависимости от характера рабочей нагрузки рекомендуется использовать оптимизированные вычислительные ресурсы, оптимизированные для памяти, оптимизированные для хранения хранилища или даже оптимизированные графические номера SKU виртуальных машин. Размеры виртуальных машин GPU — это специализированные виртуальные машины, доступные с одним, несколькими и дробными gpu. Пулы узлов Linux с поддержкой GPU в AKS лучше всего подходит для вычислительных рабочих нагрузок, таких как отрисовка графики, обучение больших моделей и вывод.

Примечание.

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

Обзор вариантов хранения

Дополнительные сведения о вариантах хранения и связанных затратах см. в следующих статьях:

Использование конфигураций предустановки кластера

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

Рассмотрите возможность мультитенантности

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

Предупреждение

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

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

Создание нативных облачных приложений

Сделать контейнер как можно более бережливым

Бережливый контейнер относится к оптимизации размера и объема ресурсов контейнерного приложения. Убедитесь, что базовый образ минимальный и содержит только необходимые зависимости. Удалите ненужные библиотеки и пакеты. Меньший образ контейнера ускоряет развертывание и повышает эффективность операций масштабирования. Потоковая передача артефактов в AKS позволяет передавать образы контейнеров из Реестр контейнеров Azure (ACR). Он извлекает только необходимый слой для начального запуска pod, уменьшая время извлечения для больших образов от минут до секунд.

Применение квот ресурсов

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

Использование запуска и остановки кластера

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

Использование резервирования емкости

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

Мониторинг среды и расходы

Повышение видимости с помощью Microsoft Cost Management

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

Azure Monitor

При приеме данных метрик с помощью аналитики контейнеров рекомендуется перенести в управляемый Prometheus, что обеспечивает значительное сокращение затрат. Вы можете отключить метрики аналитики контейнеров с помощью правила сбора данных (DCR) и развернуть управляемую надстройку Prometheus, которая поддерживает настройку с помощью Azure Resource Manager, Azure CLI, портал Azure и Terraform.

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

Служба Log Analytics

Для журналов плоскости управления рекомендуется отключить категории, которые вам не нужны, или использовать API базовых журналов, если применимо к сокращению затрат на Log Analytics. Дополнительные сведения см. в разделе Служба Azure Kubernetes (AKS) плоскости управления или журналы ресурсов. Для журналов плоскости данных или журналов приложений рекомендуется настроить параметры оптимизации затрат.

Оптимизация рабочих нагрузок с помощью автомасштабирования

Определение базовых показателей

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

Включение автомасштабирования приложений

Автомасштабирование вертикального модуля pod

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

Автомасштабирование горизонтального модуля pod

Горизонтальное автомасштабирование pod (HPA) динамически масштабирует количество реплик pod на основе наблюдаемых метрик, таких как использование ЦП или памяти. В периоды высокого спроса HPA масштабируется, добавляя дополнительные реплики pod для распределения рабочей нагрузки. В периоды низкого спроса HPA масштабируется, уменьшая количество реплик для экономии ресурсов. Лучше всего подходит для приложений с прогнозируемыми требованиями к ресурсам.

Предупреждение

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

Автомасштабирование на основе событий Kubernetes

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

Включение автомасштабирования инфраструктуры

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

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

Автоматическая подготовка узла

Для сложных рабочих нагрузок может потребоваться несколько пулов узлов с различными конфигурациями размера виртуальной машины для удовлетворения требований к ЦП и памяти. Точное выбор и управление несколькими конфигурациями пула узлов добавляет сложность и операционные издержки. Автоматическая подготовка узла (NAP) упрощает процесс выбора номера SKU и решает оптимальную конфигурацию виртуальной машины на основе ожидающих требований к ресурсам pod для выполнения рабочих нагрузок наиболее эффективно и экономично.

Примечание.

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

Сохранение с помощью скидок Azure

Резервирования Azure

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

Экономичный план Azure

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

Преимущество гибридного использования Azure

Преимущество гибридного использования Azure для Служба Azure Kubernetes (AKS) позволяет максимизировать локальные лицензии без дополнительных затрат. Используйте любые соответствующие локальные лицензии, которые также имеют активную версию Software Assurance (SA) или ценовую подписку, чтобы получить виртуальные машины Windows в Azure по сниженной стоимости.

Использование FinOps для создания культуры экономии затрат

Финансовые операции (FinOps) — это дисциплина, которая объединяет финансовую отчетность с управлением облаком и оптимизацией. В нем основное внимание уделяется обеспечению выравнивания между финансами, операциями и инженерными командами, чтобы понять и контролировать затраты на облако. Фонд FinOps имеет несколько важных проектов, таких как:

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

Оптимизация затрат — это постоянные итеративные усилия. Дополнительные сведения см. в следующих рекомендациях и рекомендациях по архитектуре: