Как Kubernetes помогает подготовиться к масштабированию в начале разработки
В этой статье рассказываем, как в начале разработки предусмотреть возможность для масштабирования даже на слабом железе, используя highload-подходы.
Предположим, вы еще в начале пути. Для проекта хватает одного сервера, обновляете его без деплой-системы, да и разработчиков можно пересчитать по пальцам. Когда из-за временных неполадок ваш боевой сервер перестает отвечать на запросы, бизнес не несет убытков. Вы просто откатываетесь к стабильной версии, откладывая разработку корректной инфраструктуры на потом. Когда нагрузка возрастет — тогда и займемся.
В Evrone не согласны с таким подходом. К нам обращаются за помощью владельцы серьезных сервисов с десятками тысяч пользователей с криком «Спасите». Мы видим, как им больно, когда из-за ошибок и непродуманности инфраструктуры за считанные минуты неработающего сервера они теряют миллионы рублей.
Разработку и продумывание инфраструктуры откладывают на будущее, потому что предполагают, что это дорого и сложно. Дорого и сложно создавать, еще дороже — поддерживать уже созданную систему. Но если задуматься об инфраструктуре на самом старте разработки — все может быть по-другому. В Evrone, начиная проект, используют highload-подход с первой строчки кода.
Как работает Kubernetes
Docker отделяет код от железа, давая возможность легко и бегло тиражировать приложение, разворачивая его в любой системе. Kubernetes — делает все еще проще. Это пакетная работа с docker-images: группировка, управление и настройка, одновременный запуск на множестве виртуальных машин. Чем больше у вас сервисов, тем заметнее Kubernetes экономит время и, как следствие, нервы и деньги.
Kubernetes отлично подходит не только для для оркестровки контейнерами в облаке, но и на bare-metal серверах. В наиболее популярных системах он встроен по умолчанию: как в зарубежных Azure от Микрософт, Google Cloud, Alibaba Cloud, Amazon WS, так и в российских Яндекс.Облаке или Облаке Mail.ru.
При этом все еще сохраняется ошибочное мнение, что Kubernetes непрост в использовании, да и стоит слишком много.
Легко ли использовать Kubernetes?
Наш ответ — да. Во-первых, у Kubernetes очень подробная официальная документация. Во-вторых, благодаря популярности у Kubernetes есть сообщество сторонников и приличное число наработок.
Для максимального комфорта при развертывании существует менеджер пакетов Helm (наподобие Yum или Apt для unix систем). Helm создает «чарты» — комплексы параметров для создания образцов в кластере Kubernetes.
Чарты в Helm — это шаблоны. Под большинство задач уже есть готовые решения, которые вы можете найти в сети. Например, в главном каталоге приложений Kubernetes — Kubeapps.
Как итог — развертывание приложения настраивается одним нажатием. Разумеется, вы можете создать свой шаблон с нуля, но для 95% задач уже существует готовый чарт. Даже если он будет не полностью подходит персонально под ваш случай — используйте его как пример, чтобы разработать свой.
Сколько нужно заплатить за железо для Kubernetes?
Говорят, Kubernetes тяжелый. Ноды (так в терминах Kubernetes называются сервера в кластере) — требовательны к ресурсам, т.к. включают в себя приличное количество компонентов. 6 серверов с процессорами в 2 ядра и памятью RAM в 4 Гб — минимальная сборка для хорошей работы. Если нагрузка ожидается высокой (что обычное дело для Evrone) — на главной ноде используем оперативную память от 8 Гб. Такие требования никак не коррелируют с тем, что мы обещали вначале — с запуском даже на слабом сервере.
Все дело в K3S. Это новый дистрибутив, опубликованный в середине 2019 года. Мы применяем его при разработке, когда технические показания серверов явно не дотягивают до требований классического Kubernetes.
K3S — это Kubernetes, сжатый практически в 5 раз (по словам разработчиков). Бинарный файл весит около 40 МБ, а на рабочей ноде дистрибутив использует около 75 Мб, требуя оперативки в 512. Всю изящность и небольшой размер K3S легко вообразить, если знать, что он без проблем встает на Raspberry Pi. И, разумеется, он запустится и на боевом старичке вашей компании.
Что конкретно ужали разработчики? Как раз те части Kubernetes, которые потребляли больше всего памяти. Это облачный контроллер (Cloud-Controller Manager) и система хранения данных ETCD. На локальном сервере Cloud-Controller не нужен — ведь в облаках есть свой менеджер. Распределенное ETCD-хранилище без проблем сменяется любой встраиваемой базой данных на ваш выбор, например SQLite.
В результате, после всех сокращений, K3S выглядит так:
Максимально легкий дистрибутив можно сделать еще легче — отказаться от Docker. K3S работает с Containerid — в прошлом элементом Docker, а сегодня независимым решением. Containerid — создает исполняемую среду, в которой запускаются контейнеры. Создатели Containerid сделали упор на упрощение при сохранении надежности и масштабируемости. При этом вы вполне можете в настройках дистрибутива K3S вернуть Docker как среду контейнеризации — для упрощения возможного будущего переноса в облако.
Kubernetes — практика использования Evrone
В первый раз мы применили Kubernetes при создании Vexor. Это было CI/CD-решение для внутреннего использования, которое переросло в коммерческий сервис (сейчас мы прекратили его развитие). Раньше мы запускали архитектуру одновременно на нескольких виртуалках. С помощью Kubernetes мы скомпоновали ее в единое окружение. Вместо того, чтобы оперировать масштабами виртуальных серверов, мы начали использовать сущность единого окружения, где ресурсы были масштабируемыми.
Еще одним преимуществом стала легкость миграции контейнеров. Все внутренние сервисы проекта обменивались данными через брокер RabbitMQ, связи между ними стали менее тесными. В результате мы не просто без проблем мигрировали контейнеры с одного сервера на другой — подстраиваясь под ресурсную необходимость, — но и не влазили вручную в механизмы миграции. Kubernetes отвечал за всю миграцию, запросный роутинг, отслеживание цикла проекта и scheduling. Это было мощно.
После первого раза все последующие разработки мы начинали в окружении Kubernetes, не сортируя проекты по сложности или весу. Более того, мы начали перемещать в Kubernetes уже работающие сервисы на docker-swarm и Nomad.
Следует отметить, что Kubernetes отлично подходит и для работы на bare-metal серверах. Сложнее, чем в облаке (ведь нет возможности получить стандартную машину со стандартной конфигурацией). Но Evrone имеет опыт работы и настройки на конкретном железе. Требуется уделять внимание распределению трафика, созданию новых нод, поиске места на диске для хранения данных и т.д.
Более того, мы запускали окружение Kubernetes в режиме одной ноды (на одном bare-metal сервере). Мы использовали K3S — единственной возможный вариант в условиях такой нехватки ресурсов. Окружение было развернуто в защищенном контуре, попасть внутрь можно было лишь по VPN, а трафик шел сквозь http-proxy. Дистрибутив K3S позволил эффективно работать, признаемся честно, на очень слабом сервере. А в случае развития проекта благодаря дистрибутиву вы сможете беспроблемно переехать на большой кластер, не нуждаясь при этом в переписывании всего стека.
Kubernetes — и горизонтально, и вертикально
Надеемся, что убедили вас: думать о будущем масштабировании следует на уже старте проекта. При использовании контейнеризации, как только возникнет необходимость в миграции, вы сделаете это легко и изящно. Kubernetes развивается стремительно и уже доступен практически на всех известных и авторитетных облачных сервисах. Если ваш проект упакован в контейнеры с самого начала — Kubernetes позволит вам масштабироваться как горизонтально, так и вертикально.
При использовании горизонтального метода Kubernetes позволяет распараллеливать трафик между репликами, автоматически увеличивая их количество. В результате нагрузка на каждую из них уменьшается. Более того, как только общий трафик уменьшится, Kubernetes сократит лишние реплики, позволив не переплачивать за используемые ими ресурсы.
Вертикальный метод масштабирования более сложный. если в облаке есть возможность закупки виртуальных машин, то специальное ПО для Kubernetes либо выделяет более производительные машины, либо выключает недозагруженные. Возможны одновременно оба варианта действий — зависит от ситуации и ресурсоемкости сервиса. Заказывая характеристики машин, разработчики часто действуют по внутренним ощущениям. Да тут 4 Гб с головой, 100%! Может случиться так, что спецификации не были вовремя пересмотрены. Итог — либо вы снимаете чересчур дорогие сервера с избытком памяти, либо не учитываете самые высокие нагрузки и «падаете» в часы пик.
Вдумайтесь, как сильно надо выложиться программистам, чтобы в случае срочной надобности быстро масштабировать проект на пике трафика — а значит, полный юзеров и каждую минуту приносящий прибыль. Используйте статистику, чтобы посчитать, сколько стоит для бизнеса минута простоя вашего проекта. В отдельных случаях, если архитектура не была продумана изначально, в процессе масштабирования сервер может не работать несколько часов. Именно поэтому мы советуем highload подход с использованием Kubernetes. Он гарантирует, что, когда масштабирование понадобится, оно пройдет идеально.
Начало работы с Kubernetes
Остались вопросы по Kubernetes? Александр Кириллов, CTO Evrone, на видео с DevOps митапа в рамках конференции Metaconf рассказывает более подробно.