Чаму Docker Swarm, а не Kubernetes: досвед рэальнага выбару
Калі гаворка заходзіць пра аркестрацыю кантэйнераў, звычайна маецца на ўвазе Kubernetes. Гэта галіновы стандарт, за ім стаіць велізарная экасістэма, і менавіта яго вывучаюць па туторыялах. Я таксама пачынаў з яго — і ў выніку выбраў Docker Swarm. Вось як гэта было.
Кантэкст: невялікая каманда, рэальныя тэрміны
Некалькі гадоў таму я будаваў інфраструктуру для ўласнага праекта — мабільны дадатак з некалькімі мікрасэрвісамі і API. Каманда невялікая: прадакт, дызайнер, Android-распрацоўшчык і я — бэкенд і інфра ў адной асобе. З самага пачатку патрэбна была аўтаматызацыя, балансоўка нагрузкі і магчымасць маштабаваць сэрвісы. Пры гэтым рэсурсы сціплыя: два хасты сярэдняй магутнасці і абмежаваны час.
На папярэдняй працы я пісаў код на Java і краем вока назіраў, як каманда мігруе на Kubernetes. Тады інфраструктурныя дэталі мяне асабліва не цікавілі — галоўнае, каб маё асяроддзе працавала. Але калі прыйшоў час самому будаваць інфру з нуля, менавіта з Kubernetes я і пачаў разбірацца.
Kubernetes: магутна, але не для нас
Я чытаў дакументацыю, эксперыментаваў у minikube, спрабаваў разабрацца як кіраваць кластэрам самастойна. Гатовых рашэнняў для разгортвання дастаткова — але каб імі карыстацца, трэба спачатку зразумець базу. А часу на гэта амаль не было: большая частка сыходзіла ў напісанне кода, а не ў інфраструктуру.
Паступова прыйшло разуменне: Kubernetes для нашага маштабу будзе залішне цяжкім. Два хасты сярэдняй магутнасці, частка рэсурсаў сыйдзе проста на падтрыманне самога Kubernetes. А ўвесь мільён магчымасцяў, якія ён дае — нам па факце не патрэбны. Разгортваць малекулярную лабараторыю, каб проста ўскіпяціць ваду — overkill.
Nomad я паглядзеў бегла. Здалося складаней, чым хацелася б, а тэрміны ціснулі — не стаў паглыбляцца.
Як знайшоў Swarm
Адказ прыйшоў нечакана — з абмеркавання на форуме, дзе я шукаў інфармацыю па тэме аркестрацыі. Людзі апісвалі рэальныя кейсы: невялікія каманды і кампаніі, кластары ад дзесяці да пяцідзесяці нод, умераныя патрабаванні да маштабавання. І ўсё гэта вырашалася Docker Swarm без лішняй складанасці.
Пачаў капаць у яго бок і здзівіўся, што не вывучаў яго раней. За пару дзён падняў кластар, разгарнуў рэпазіторый і YouTrack. Гэта было менавіта тое, што трэба.
Чаму Swarm аказаўся правільным выбарам
Для нашага маштабу Swarm даваў неабходны і дастатковы функцыянал:
- Балансоўка і скейлінг — ёсць, працуе з кораба
- Натыўная інтэграцыя з Docker — не трэба вучыць асобную абстракцыю паверх ужо знаёмага інструмента
- Прастата аперацый — адзін чалавек можа кіраваць кластарам без глыбокай спецыялізацыі менавіта на інфры
- Нізкія накладныя выдаткі — Swarm не з'ядае рэсурсы кластара ў такім аб'ёме, як Kubernetes
Да паўнавартаснай аўтаматызацыі зборкі тады рукі не дайшлі — дэплой ішоў праз кансольныя скрыпты з ручным пулам з git і пушам у рэестр. Але аснова была закладзена.
Што стала далей
Той праект на паўзе да лепшых часоў — не знайшлося фінансавання. Затое падвярнулася бягучая праца: інфраструктурны хаос, кожны робіць па-свойму, патрэбен парадак. Таго досведу са Swarm хапіла, каб выбудаваць агульную структуру, потым дакруціць зборку праз Drone CI, дадаць маніторынг праз Grafana + Prometheus + Loki.
Зараз кластар вырас да 20+ нод, у актыўнай распрацоўцы пяць праграмістаў, у пікавыя перыяды было да дваццаці. Swarm спраўляецца. Дзе не хапала функцыяналу — дадаў свае рэалізацыі, дзесці навучыўся жыць без тонкасцяў, якія ёсць у Kubernetes. Гэта рабочы кампраміс, а не часовае рашэнне.
Калі Swarm — правільны выбар
Калі коратка: калі ў вас не тысяча нод і не сотня каманд, якія адначасова дэплояць сэрвісы.
Swarm добра падыходзіць, калі:
- Кластэр да ~50 нод
- Невялікая каманда або адзін чалавек на інфры
- Патрэбна аўтаматызацыя і аркестрацыя, але не хочацца несці накладныя выдаткі Kubernetes
- Ужо выкарыстоўваеце Docker і хочаце мінімальны парог уваходу
Kubernetes — выдатны інструмент. Але інструмент павінен адпавядаць задачы. Часам правільны выбар — гэта не самы магутны, а дастатковы.