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

  • Статья

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

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

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

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

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

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

  • Пулы узлов Azure Spot Виртуальные машины - Spot поддерживаются масштабируемыми наборами виртуальных машин Azure и развертываются в одном домене сбоя без гарантий высокого уровня доступности или обслуживания. Точечные виртуальные машины позволяют воспользоваться неиспользуемой емкостью Azure со значительными скидками (до 90 % по сравнению с ценами по мере использования). Если Azure нуждается в емкости, инфраструктура Azure вытесняет точечные узлы. Лучше всего подходит для сред разработки и тестирования, рабочих нагрузок, которые могут обрабатывать прерывания, такие как задания пакетной обработки и рабочие нагрузки с гибким временем выполнения.
  • Процессоры Ampere Altra Arm (ARM64) — виртуальные машины ARM64 являются эффективными и экономичными, но не компрометируют производительность. Благодаря поддержке пула узлов AMR64 в AKS можно создавать узлы агента ARM64 Ubuntu и даже смешивать узлы архитектуры Intel и ARM в кластере. Эти виртуальные машины ARM предназначены для эффективного выполнения динамических масштабируемых рабочих нагрузок и могут обеспечить до 50 % более высокую производительность по цене, чем сопоставимые виртуальные машины на основе x86 для масштабируемых рабочих нагрузок. Лучше всего подходит для серверов веб-приложений, баз данных с открытым исходным кодом, облачных приложений, игровых серверов и т. д.
  • Оптимизированные для GPU номера SKU . В зависимости от характера рабочей нагрузки рекомендуется использовать оптимизированные вычислительные ресурсы, оптимизированные для памяти, оптимизированные для хранения или даже графические номера SKU виртуальных машин, оптимизированные для gpu. Размеры виртуальных машин 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 Monitor

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

Если вы используете прием журналов, мы также рекомендуем использовать API "Базовые журналы" для снижения затрат на Log Analytics. Дополнительные сведения см. в рекомендациях Azure Monitor и управлении затратами на аналитику контейнеров.

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

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

Автомасштабирование вертикального модуля 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 выпустил несколько важных проектов:

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

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