Дмитрий Исаев

Kubernetes стал стандартом де-факто для оркестрации контейнеров. Его активно используют стартапы, разработчики и крупные компании — как для небольших dev/test-окружений, так и для переноса продакшен-нагрузки в кластер. Несмотря на разные сценарии, у большинства пользователей однажды возникает вопрос: «Как оптимизировать расходы на инфраструктуру Kubernetes-кластера?»Обозначим на старте, что основная часть стоимости кластера — это воркер-ноды, на которых запускаются поды. Отсюда легко сделать вывод: первое, что важно рассмотреть для экономии, — выбрать подходящие типы виртуальных машин или серверов. Экономия для dev-, test- и pet-проектов Окружения для разработки, тестирования и pet-проектов обычно не требуют высокой доступности или отказоустойчивости. Это позволяет использовать более дешевые ресурсы, принимая возможные ограничения. Вариант 1: прерываемые виртуальные машины Прерываемые ВМ (preemptible) — это виртуальные машины, которые могут быть автоматически остановлены платформой в случае нехватки ресурсов. Но при этом они стоят значительно дешевле: в среднем пользователь может сэкономить 75% по сравнению с обычными ВМ. Обратите внимание: такие ВМ не обладают SLA. Что из этого следует? Платформа может остановить машину без предупреждения, если ей понадобятся ресурсы. При этом такие ВМ автоматически перезапускаются при наличии свободных ресурсов. При их использовании в продакшене важно, чтобы приложение было устойчиво к перезапуску узлов и корректно восстанавливало соединение. Разберемся, когда использовать прерываемые ВМ. CI/CD-пайплайны. Задачи сборки и тестирования выполняются быстро и не требуют непрерывной работы. Если ВМ выключат, вы просто перезапустите задачу. ETL и обработка данных. Spark, Dask, Flink или Airflow-воркеры могут корректно работать на прерываемых узлах, если хранят промежуточное состояние во внешнем хранилище — например, S3. Потеря части воркеров не приведет к сбою всего пайплайна. Машинное обучение и обучение моделей. Если обучение поддерживает чекпойнты (например, PyTorch или TensorFlow), можно сэкономить, выполняя тренировки на прерываемые ноды. При прерывании узла обучение просто продолжается с последнего сохраненного состояния.Dev, Stage и Preview-окружения. Тестовые среды, которые разворачиваются под каждую ветку или pull request. Ненадежность прерываемых инстансов не страшна: такие окружения временные и легко пересоздаются. Интеграция с Managed Kubernetes Прерываемые ВМ можно использовать в Managed Kubernetes для экономии на группах узлов. Группу нод любой конфигурации можно сделать прерываемой при создании кластера или добавлении группы. В панели управления для этого есть соответствующая настройка Прерываемая группа нод: Пример создания прерываемой ноды. Сравнение стоимости двух нод одной конфигурации. Вариант 2: процентные инстансы Процентные инстансы (Shared Line) — это ВМ, которым предоставляется не весь vCPU, а только часть — например, 10, 20 или 50%. Это значительно снижает стоимость, но производительность может колебаться при высокой загрузке. При этом она никогда не опустится ниже указанной доли и может временно повышаться до 100%, если другие клиенты не используют ресурсы на полную или часть виртуального ядра свободна. Но важно учесть: такие ВМ не подходят для сервисов с жесткими SLA или требованием стабильной производительности. Вкратце разберем примеры использования. Pet-проекты. Такие проекты обычно не требуют высокой вычислительной мощности, работают нерегулярно и не чувствительны к задержкам. Переплачивать за полноценные ресурсы в этом случае нет смысла. Ноды кластера с уровнем производительности 10–50% позволяют запускать приложения, сохраняя функциональность и снижая затраты в несколько раз. Даже при временном снижении скорости работы приложения остаются доступными. Ненагруженные сайты. Сайты-визитки, небольшие лендинги и портфолио обычно обладают низкой посещаемостью и выполняют простые задачи — отображение информации, формы обратной связи или записи на услуги. Для таких проектов не нужна полная вычислительная мощность, поэтому ноды с частичной производительностью CPU (например, 50 % и ниже) — оптимальное решение. Они обеспечивают стабильную работу и быстрое открытие страниц при минимальных затратах на инфраструктуру. Дополнительные сервисы — чат-боты, формы записи или сбор заявок — также можно размещать на таких инстансах без потери качества работы. Бэкенды без критичных SLA. Для внутренних API или сервисов, которые не обрабатывают критические транзакции, нестабильная производительность не станет проблемой. Например, бэкенд админки или вспомогательных сервисов можно разместить на Shared Line, сохранив бюджет без ущерба для бизнеса. Тестовые среды. Окружения для проверки новых функций, демонстрации изменений и предварительного тестирования обычно не требуют высокой производительности и постоянной нагрузки. В таких случаях выгодно использовать ноды с частичной производительностью CPU. Они обеспечивают стабильную работу приложений и позволяют разработчикам и менеджерам удобно просматривать результаты перед выпуском в продакшен, при этом значительно сокращая затраты на инфраструктуру. Для большинства задач тестирования 10–50 % мощности ядра достаточно, чтобы сохранить отзывчивость системы и скорость развертывания. Использование в Managed Kubernetes Сейчас такие флейворы можно использовать при создании групп нод через Terraform. Пример кода для Terraform: Экономия в продакшене Когда речь идет о продакшен-нагрузке, клиенты предпочитают надежные и предсказуемые по производительности решения. В этом случае оптимизация должна быть «аккуратной». Выделенные серверы как воркер-ноды Вы можете подключить выделенные серверы к Managed Kubernetes и использовать их как воркер-ноды. Здесь пригодится Chipcore Line — линейка недорогих выделенных серверов начального уровня. Они не обеспечивают высокой избыточности, но отлично подходят для задач, где важна стабильность ресурсов по доступной цене. Пример создания ноды на выделенном сервере. Рассмотрим ключевые преимущества: полный контроль над железом; предсказуемая производительность; снижение стоимости при аренде на длительный срок. Например, при почасовой аренде выйдет стоимость примерно в 6,5–8 ₽/час, а при оплате за один год — от ~3 ₽/час (в пересчете). Сравнение месячной стоимости Сравним стоимость с ВМ аналогичной конфигурации у разных провайдеров инфраструктуры. Для примера возьмем: 6 vCPU, 64 ГБ RAM, 2×1000 ГБ SSD NVMe, 730 ч/мес. Chipcore Line значительно дешевле облака, даже при аренде на один месяц. А при аренде на 12 месяцев с разовой оплатой экономия может достигать до 6 800 ₽/мес, или более 80 000 ₽/год на одну ноду. Более того, в Chipcore уже включены NVMe-диски — как мы отметили в таблице, в облаках за такие объемы хранилища нужно доплачивать 5 000–6 000с. ₽ отдельно. ПровайдерvCPU / RAMДиски₽/мес (итого)CL34-NVMe14 / 64 ГБ2×1000 NVMe9 775 – 11 500Провайдер №1 14 / 64 ГБSSD отдельно~33 000 - 35 000 Провайдер №214 / 64 ГБSSD отдельно~36 000 - 41 000Провайдер №314 / 64 ГБSSD отдельно~33 000 – 37 000Провайдер №414 / 64 ГБSSD отдельно~33 000 - 35 000 Заключение Экономить на Kubernetes — это не значит идти на компромиссы с качеством. Благодаря гибкому выбору ресурсов и возможности подключения физических серверов вы можете: снизить расходы на dev- и test-окружения, используя прерываемые и процентные ВМ; оптимизировать продакшен-среду с помощью выделенных серверов. Правильная комбинация ресурсов позволит вам удерживать баланс между стоимостью, отказоустойчивостью и производительностью.

Дмитрий Исаев

Материалы автора

Как сократить расходы на Kubernetes. Практические подходы для pet-проектов и продакшена