Контейнерный хостинг своими руками или чем Kubernetes лучше Docker Swarm

Приветствие

Привет, дорогие хабровчане! В данной статье хочу поделиться своим опытом создания сервиса предоставляющего услуги контейнерного хостинга, в процессе работы над которым узнал много нового, для себя, в этой области. Теперь хочу поделиться с вами и постараюсь сделать так, чтобы вы не были разочарованы если дочитаете до конца.

Планировалось одно, а получилось…

Изначально, на этапе планирования, была задача строить инфраструктуру вокруг Kubernetes, но сейчас пришли к тому, что сервис работает на Docker, управляется через docker compose файлы и Docker-API. В настоящее время без режима Swarm. Почему так получилось и какие проблемы приходится решать, не используя Kubernetes, я вам сейчас расскажу.

Почему не Docker Swarm?

Во первых, как минимум, сразу напрашивается вопрос, почему без режима Swarm, ведь горизонтальное масштабирование не лишнее? Режим swarm пока не используется, так как в настоящее время мы располагаем только одним сервером и если вдруг сервер перестанет отвечать, то всё равно все реплики перестанут работать, поэтому и смысла от них нет. Однако, естественно надеюсь это не постоянная ситуация, поэтому всегда держали в голове режим Swarm и не включали того, что не будет работать в Swarm, чтобы потом было легче мигрировать.

Почему не Kubernetes?

Почему не использовали Kubernetes? Ответ прост, но принять решение было не просто. На момент начала разработки у меня совсем не было опыта работы с ним. Да и сейчас пока нет, только в теории. Плюс, из интернета я так и не понял, чем он конкретно круче Swarm кроме того, что он может работать с гораздо большим количеством контейнеров. Так как, чтобы это проверить, нужно столько ресурсов каких у меня пока что нет, я решил двигаться в сторону Swarm, а когда появятся ресурсы и спрос, а главное понимание зачем это нужно, то уже возможно переписывать на Kubernetes.

Что стало известным по ходу проекта

Спустя год разработки и три месяца нагрузочных тестов я во многом пересмотрел свои изначальные мысли. Сейчас я перечислю несколько моментов, которые мне удалось накопать в процессе и которые, на мой взгляд, вносят лепту в сравнение Swarm и Kubernetes.

1. Сети Docker не бесконечные

Если вы просто будете создавать сети по умолчанию, то через определенное количество сетей Docker перестает выделять новые подсети IP адресов, по причине того, что сеть по умолчанию исчерпывает возможное количество выделяемых IP адресов для подсетей. Если вы настроите пулл адресов Docker таким образом, чтобы увеличить это ограничение, то всё равно спустя какое-то количество сетей Docker перестает выделять адекватные IP адреса для сетей. Эта проблема решается только через создание сетей с указанием подсети --subnet.

docker network create --subnet=172.17.0.0/24 network_name

Из коробки Docker, следит за уникальностью подсетей только до определенного количества сетей. Swarm и Kubernetes решают эту проблему Docker.

2. Перезапуск Docker может быть большой проблемой

Если в вашей системе большое количество контейнеров и вы указываете restart как always или on-failure, то это означает, что при старте демон docker начнет отвечать только после того как запустятся все эти контейнеры. В зависимости от ресурсов оборудования и количества контейнеров такой запуск может длиться часами. А если от каких-либо контейнеров зависит работа чувствительных для вашего приложения сервисов, то это недопустимо.

Я не нашел как Swarm решает эту проблему, скорей всего никак, так у него все те же always и on-failure, если верить GPT то Kubernetes это решает поэтапным запуском.

Эту проблему в нашем проекте решили тем что сделали restart:no, а при старте сервера, сначала запускает все проекты, при этом подписывается на события падения контейнеров и поднимает их. Получается Docker с ключевыми сервисами запускается сразу за пару минут, а затем сервер параллельно запускает весь массив проектов.

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

3. Собирать статистику нужно легко

Когда у вас много контейнеров, собирать поминутную статистику с них становится настоящим испытанием.

Если просто каждую минуту опрашивать по Docker-API статистику, такую как использование памяти, процессора, сети и диска, то всё хорошо будет работать лишь до определенного количества контейнеров, а дальше начинается такое, что время обработки запроса превышает минуту и демон docker перегружается запросам и перестает быть отзывчивым.

Kubernetes для сбора статистики использует cAdvisor, у меня были попытки его использовать, но тип данных который он возвращает совсем не подошёл, либо я не смог его правильно настроить, но было достаточно увидеть как он работает и что он, все равно, работает через Docker-API, было принято решение в отказе от него, как от лишнего слоя. В итоге, методом проб и ошибок, подобрал алгоритм, который выполняет свою задачу с большим количеством контейнеров. Разбивает на чанки по времени, опрашивает параллельно и отменяет зависший запрос по конкретному контейнеру через таймаут.

4. Настройки системы по умолчанию не сработают

Если вы напишете облачный сервис и он будет работать с 10 контейнерами, то скорей всего что-то сломается когда контейнеров станет больше 100 например, а потом ещё что-нибудь когда их станет больше 200 например и так далее. Поэтому нужно заранее тестировать на максимальной нагрузке, прежде чем приглашать реальных пользователей. Это всё потому, что настройки ОС по умолчанию, ориентированы на отказоустойчивость и когда ресурсы оборудования позволяют запускать много всего, то эти настройки не дают серверу разогнаться, так как для среднестатистического железа это перебор и система блокирует операции, ломая выполнение приложений.

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

Вывод

В рамках этого проекта, хотя и увидел «чем Kubernetes лучше Docker Swarm», но всё же пока эти недостатки кажутся мне незначительными учитывая сложность Kubernetes. В любом случае, нужно подбирать инструмент исходя из потребностей, а в моем случае Docker Swarm предпочтительнее из-за более плавного перехода от docker compose. Однако когда в распоряжении будет больше серверов и возможность тестировать 1000+ контейнеров, возможно я изменю своё мнение.

Вот такие моменты, относительно этого вопроса, мне удалось отметить. Надеюсь кому-нибудь они были интересны, а может даже полезны.

Приглашение

Всех дочитавших приглашаю на наш Контейнерный Хостинг conhos.ru, где мы стараемся держать соотношение цены и качества на выгодном уровне! Видео демонстрацию работы сервиса можно посмотреть на странице conhos.ru/about.

Благодарности и пожелания

Благодарю за внимание, успехов вам в ваших проектах!

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