Вы когда-нибудь чувствовали, что затраты на все доступные управляемые услуги или сторонние установки превышают то, что вы были готовы потратить? Или что вам дали бюджет, в котором мало места для игр?

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

Эта статья специально предназначена для экземпляров и развертываний GKE (Google Kubernetes Engine). В статье предполагается, что вы настроили проект в GCP (Google Cloud Platform) и имеете доступ через интерфейс командной строки к кластеру через kubectl. Если нет, прочтите эту статью о кластеризации с kubectl и эту статью о настройке облачных проектов Google и возвращайтесь!

1. Общие сведения о биллинге

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

Navigation menu (hamburger) > Billing > Cost table

Выберите месяц, о котором идет речь, и все подробности будут доступны. В крайнем левом столбце вы можете щелкнуть название своего проекта, и отобразятся все службы. Интересны сервисы Kubernetes Engine и Compute Engine. По сути, для того, чтобы кластер работал, мы должны платить как за управление кластером (в рамках Kubernetes Engine), так и за виртуальные машины узла кластера (в рамках Compute Engine).

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

Звучит неплохо, но если эта зона, в частности, не работает, ваш сервер и служба также будут отключены. Однако он полезен для создания прототипов и тестирования.

2. Пространства имен

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

Допустим, нам нужны производственный сервер и тестовый сервер. Имея это в виду, мы могли бы создать два кластера, чтобы разделить их. Это означает удвоение затрат на работу кластеров, и если вы не используете службу более 1 миллиона пользователей в день (плюс-минус), вероятно, останется неиспользованным много ОЗУ и ЦП. Что, если бы эти две службы могли быть в одном кластере, чтобы сэкономить деньги, и разделены, чтобы не мешать? Пространства имен в Kubernetes - это решение.

Создавая пространство имен, мы эффективно защищаем части кластера друг от друга, имитируя несколько кластеров. По умолчанию все команды, выполняемые с помощью kubectl, будут нацелены на пространство имен по умолчанию default. Действие, такое как

$ kubectl get pods

даст только то, какие модули работают в пространстве имен по умолчанию. Мы можем использовать это, добавляя флаг --namespace (-n для краткости) в каждую команду. Начните с создания нового пространства имен

$ kubectl create namespace test-space

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

$ kubectl create secret generic test-space-key --from-literal=key=value --namespace test-space

и принеси это с помощью

$ kubectl get secret --namespace test-space

Помните, что при отсутствии флага —-namespace наш вновь созданный секрет не будет отображаться, поскольку пространства имен различны! Это означает, что вам всегда нужно добавлять одно и то же пространство имен для ресурсов, которые будут использовать друг друга. Например, если развертывание использует только что созданный секрет, они должны находиться в одном пространстве имен. Обходной путь - изменить пространство имен в вашем контексте kubectl.

kubectl config set-context --current --namespace test-space

Отсутствие флага пространства имен теперь будет использовать пространство имен test-space вместо пространства имен по умолчанию default.

3. Ограничения ресурсов

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

Здесь мы сначала запрашиваем половину ЦП (m представляет тысячную долю ЦП) и 512 МБ ОЗУ. Затем мы ограничиваем использование нашего модуля более 1 ЦП и 1 ГБ ОЗУ. Это эффективный способ спланировать пространство на ваших узлах.

Подробнее о ресурсах читайте здесь.

4. Развертывание руля

Последний совет - использовать репозиторий Helm для более сложных приложений. Может возникнуть соблазн запустить среду Airflow. Это может быть проблемой, поскольку Airflow состоит из трех рабочих процессов, потенциально очереди сообщений Redis и базы данных. Это довольно много ресурсов, которые нужно создать самому, не считая работы по созданию контейнеров Docker и их размещению.

В GCP этот сервис называется Cloud Composer. Однако в соответствии с их ценами с вас взимается плата не только за услугу, но и за кластер, который они запускают для вас. В их собственном примере это будет означать ~ 75 долларов в месяц за услугу плюс ~ 150 долларов в месяц для кластера с самыми маленькими узлами. . Обратите внимание, что этот кластер запускается рядом с вашим другим кластером (ами), и вы не можете с ним взаимодействовать.

Вместо этого, если у вас есть доступные ресурсы, разместите службу самостоятельно! Helm - пакетный менеджер для кластеров Kubernetes, который имеет широкий спектр продуктов, в том числе Airflow. Продукты, Диаграммы, созданы сообществом, и каждый может внести свой вклад.

Сам Helm - это инструмент командной строки, который существует для большинства менеджеров пакетов (например, Homebrew):

$ brew install helm

Затем Helm подключается к вашему kubectl context и управляет всеми ресурсами за вас. Установка пакета выполняется с помощью

helm install <your-name> <repo>/<package> --namespace <your-namespace>

Это установит указанный пакет _в указанном пространстве имен_. Вы можете взаимодействовать со всеми ресурсами, которые развертывает Helm, и при необходимости настраивать их. Часто тег resources отображается в файле конфигурации для упрощения настройки. Об этом подробнее здесь".

В будущем планируется разместить среду Jupyter Lab, общий сервер NFS и несколько прокси NginX в одном кластере.

Собираем все вместе

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

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