В Kubernetes управление затратами быстро усложняется, и вскоре с этой проблемой столкнется больше компаний. По данным Gartner, к 2022 году 75% компаний будут запускать в производственной среде контейнерные приложения.

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

Почему стоимость облака Kubernetes так сбивает с толку?

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

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

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

Избегайте этих 5 ловушек затрат Kubernetes

1. Расчет стоимости контейнера

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

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

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

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

2. Вы платите через разные центры затрат.

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

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

3. Отслеживать расходы в облаках непросто

Если учесть многооблачность, отследить это станет еще труднее. Опрос пользователей публичного облака Gartner показывает, что сегодня 81% респондентов работают с двумя и более провайдерами. Согласно ICD, 90% предприятий будут полагаться на несколько облаков или сочетание локальных, частных, гибридных и общедоступных облаков к 2022 году.

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

Ваши приложения могут быть разбросаны по разным облакам, таким как AWS, Google Cloud Platform, Azure или Digital Ocean. На каждом из них может быть размещена лишь крошечная часть вашей общей рабочей нагрузки, что еще больше усложняет отслеживание узлов и кластеров.

4. Масштабирование еще больше усложняет дело

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

В то время как Vertical Pod Autoscaler (VPA) автоматически регулирует запросы и ограничивает конфигурацию для снижения накладных расходов, Horizontal Pod Autoscaler (HPA) фокусируется на масштабировании для достижения оптимального количества CPU или RAM, выделенных для существующего экземпляра.

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

Например, представьте себе три контейнера веб-сервера, работающих ночью. В часы пик HPA масштабируется от трех до 50 контейнеров. Затем он уменьшается во время обеда, а затем снова увеличивается. К вечеру стабилизируется на низком уровне.

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

5. Контейнеры стали более динамичными

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

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

Как решить эти проблемы с затратами Kubernetes

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

  1. Найдите инструмент отслеживания затрат для подробного отслеживания затрат - например, на уровне микросервисов.
  2. Когда у вас будет видимость затрат, вы можете установить точные бюджеты и отслеживать такие элементы, как затраты на трафик, чтобы лучше их понимать.
  3. Затем распределите свои затраты по пространству имен, модулю, развертыванию и метке.
  4. Проанализируйте информацию о ценах, чтобы предсказать, сколько вам придется заплатить в следующем месяце.
  5. Продолжайте отслеживать расходы по вашим оценкам и выявлять аномалии затрат или использования для их дальнейшего анализа.

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

Решение: автоматизация управления затратами в Kubernetes

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

Какие обязательные функции следует искать в инструменте автоматизации?

  1. Расширенный анализ счетов за облачные услуги и функция видимости затрат с возможностью анализа затрат вплоть до отдельных микросервисов и получения универсальных показателей для любого поставщика облачных услуг.
  2. Автоматический выбор экземпляров и корректировка.
  3. Использование спотовых инстансов для экономии до 90% затрат.
  4. Прогнозирование расходов для проектов, кластеров, пространств имен и развертываний.

Автоматизированное управление затратами

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

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

Больше контента на plainenglish.io