Дзяўчына на скутэры. Ілюстрацыя , лагатып Nomad ад
Kubernetes - гэта 300-кілаграмовая гарыла для аркестроўкі кантэйнераў. Яна працуе ў некаторых самых буйных кантэйнерных сістэмах у свеце, але дорага абыходзіцца.
Асабліва дорага для невялікіх каманд, якім давядзецца выдаткаваць шмат часу на падтрымку і крутую крывую навучання. Для нашай каманды з чатырох чалавек гэта зашмат накладных выдаткаў. Таму мы сталі шукаць альтэрнатывы - і закахаліся ў .
Чаго жадаецца
Наша каманда падтрымлівае шэраг тыповых сэрвісаў для маніторынгу і аналізу прадукцыйнасці: канчатковыя кропкі API для метрык, напісаных на Go, экспарт Prometheus, парсер логаў, такія як Logstash і , а таксама базы дадзеных, такія як InfluxDB або Elasticsearch. Кожная з гэтых службаў працуе ва ўласным кантэйнеры. Нам патрэбная простая сістэма, каб падтрымліваць усё гэта ў працоўным стане.
Мы пачалі са спісу патрабаванняў для аркестроўкі кантэйнераў:
- Запуск набору сервісаў на многіх машынах.
- Агляд запушчаных службаў.
- Сувязі паміж службамі.
- Аўтаматычны перазапуск, калі сэрвіс падае.
- Абслугоўванне інфраструктуры невялікай камандай.
Акрамя таго, наступныя рэчы будуць прыемнымі, але не абавязковымі дапаўненнямі:
- Пазнака машын па іх магчымасцях (напрыклад, пазнака машын з хуткімі дыскамі для цяжкіх сэрвісаў уводу-вываду).
- Магчымасць запуску службаў незалежна ад аркестратара (напрыклад, падчас распрацоўкі).
- Агульнае месца для абмену канфігурацыямі і сакрэтамі.
- Канчатковая кропка для метрык і логаў.
Чаму Kubernetes нам не падыходзіць
Пры стварэнні прататыпа з Kubernetes мы заўважылі, што сталі дадаваць усё больш складаныя пласты логікі, на якую безумоўна належылі.
У якасці прыкладу, Kubernetes падтрымлівае ўбудаваныя канфігурацыі сэрвісаў праз . Вы можаце хутка заблытацца, асабліва пры зліцці некалькіх файлаў канфігурацыі ці даданні дадатковых службаў у pod. Kubernetes (або у дадзеным выпадку) дазваляе ўкараняць дынамічна вонкавыя канфігурацыі для падзелу інтарэсаў. Але гэта прыводзіць да жорсткай утоенай сувязі паміж вашым праектам і Kubernetes. Зрэшты, Helm і ConfigMaps з'яўляюцца дадатковымі опцыямі, таму вам не абавязкова іх выкарыстоўваць. Вы можаце проста скапіяваць канфігурацыю ў выяву Docker. Тым не менш, прывабна пайсці па гэтым шляху і пабудаваць непатрэбныя абстракцыі, аб чым потым можаце пашкадаваць.
Акрамя таго, экасістэма Kubernetes хутка развіваецца. Патрабуецца шмат часу і энергіі, каб заставацца ў курсе лепшых практык і найноўшых інструментаў. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - спіс працягваецца і працягваецца. У пачатку працы неабходны не ўсе гэтыя прылады, але вы не ведаеце, што спатрэбіцца, таму трэба быць у курсе за ўсё. З-за гэтага крывая навучаньне даволі крутая.
Калі выкарыстоўваць Kubernetes
У нас у кампаніі многія выкарыстоўваюць Kubernetes і цалкам задаволены гэтым. Гэтыя інстансы кіруюцца Google ці Amazon, у якіх хапае рэсурсаў на падтрымку.
Kubernetes пастаўляецца з , якія робяць больш кіраванай маштабную аркестроўку кантэйнераў:
- Дэталізаванае .
- дадаюць логіку ў кластар. Гэта проста праграмы, якія размаўляюць з Kubernetes API.
- ! Kubernetes умее маштабаваць сэрвісы па патрабаванні, выкарыстоўваючы сэрвісныя метрыкі і не патрабуючы ручнога ўмяшання.
Пытанне ў тым, ці сапраўды вам патрэбны ўсе гэтыя функцыі. Не атрымаецца толькі спадзявацца на абстракцыі; .
Наша каманда дае большасць сэрвісаў выдалена (з-за цеснай сувязі з асноўнай інфраструктурай), таму мы не хацелі паднімаць уласны кластар Kubernetes. Мы хацелі проста прадастаўляць паслугі.
Батарэі не ўключаны
Nomad - гэта 20% аркестроўкі, якія даюць 80% неабходнага. Усё, што ён робіць, гэта кіруе дэплоямі. Nomad клапоціцца пра дэплоі, перазапускае кантэйнеры ў выпадку памылак… і гэта ўсё.
Увесь сэнс Nomad у тым, што ён робіць мінімум: ніякага дэталізаванага кіравання правамі або , так спецыяльна задумана. Гэтыя кампаненты прадастаўляюцца з боку ці не прадастаўляюцца зусім.
Думаю, што Nomad знайшоў ідэальны кампраміс паміж прастатой выкарыстання і карыснасцю. Ён добры для невялікіх, незалежных сервісаў. Калі трэба больш кантролю, то давядзецца падняць іх самастойна або выкарыстоўваць іншы падыход. Nomad - гэта проста аркестратар.
Самае лепшае ў Nomad тое, што яго лёгка замяніць. Прывязка да вендару практычна адсутнічае, паколькі яго функцыі лёгка інтэгруюцца ў любую іншую сістэму, якая кіруе сэрвісамі. Ён працуе проста як звычайны бінарнік на кожнай машыне ў кластары, вось і ўсё!
Экасістэма Nomad са слаба звязаных кампанентаў
Рэальная сіла Nomad у яго экасістэме. Ён вельмі добра інтэгруецца з іншымі - цалкам неабавязковымі - прадуктамі, такімі як (сховішча ключ-значэнне) або (апрацоўка сакрэтаў). Усярэдзіне файла Nomad ёсць часткі для вымання дадзеных з гэтых службаў:
template {
data = <<EOH
LOG_LEVEL="{{key "service/geo-api/log-verbosity"}}"
API_KEY="{{with secret "secret/geo-api-key"}}{{.Data.value}}{{end}}"
EOH
destination = "secrets/file.env"
env = true
}
Тут мы чытаем ключ service/geo-api/log-verbosity з Consul і ў працэсе працы прадстаўляем яго зменнай асяроддзі LOG_LEVEL. Мы таксама прадстаўляем ключ secret/geo-api-key з Vault як API_KEY. Проста, але магутна!
Дзякуючы сваёй прастаце Nomad лёгка пашыраецца з дапамогай іншых сэрвісаў праз API. Напрыклад, падтрымліваюцца тэгі для заданняў. Мы пазначаем усе службы з метрыкамі тэгам trv-metrics. Такім чынам, Prometheus лёгка знаходзіць гэтыя службы праз Consul і перыядычна правераць канчатковую кропку /metrics на прадмет новых дадзеных. Тое ж самае можна зрабіць, напрыклад, для логаў, выкарыстоўваючы .
Ёсць шмат іншых прыкладаў пашыральнасці:
- Запуск задання Jenkins з дапамогай хука, а Consul адсочвае паўторны дэплой задання Nomad пры зменах канфігурацыі службы.
- Ceph дадае ў Nomad размеркаваную файлавую сістэму.
- для балансавання нагрузкі.
Усё гэта дазваляе без асаблівай прывязкі да вендару.
Сумленнае папярэджанне
Ні адна сістэма не дасканалая. Не раю адразу ўкараняць у прадакшн самыя новыя функцыі. Вядома, ёсць памылкі і адсутныя функцыі, але тое ж самае адносіцца да Kubernetes.
У параўнанні з Kubernetes, супольнасць Nomad не так вялікая. У Kubernetes ужо каля 75 000 комітаў і 2000 кантрыбутараў, у той час як у Nomad каля 14 000 комітаў і 300 кантрыбутараў. Nomad будзе цяжка ўтрымацца і ня адставаць па хуткасці ад Kubernetes, але, магчыма, гэта і не трэба! Гэта больш спецыялізаваная сістэма, а меншая супольнасць таксама азначае, што ваш пул-рэквест хутчэй заўважаць і прымуць, у параўнанні з Kubernetes.
Рэзюмэ
Выснова: не выкарыстоўвайце Kubernetes толькі таму, што так робяць усё. Старанна ацаніце свае патрабаванні і праверце, якая прылада выгодней.
Калі плануеце разгарнуць масу аднастайных службаў на буйнамаштабнай інфраструктуры, то Kubernetes - добры варыянт. Проста памятайце аб дадатковай складанасці і эксплуатацыйных выдатках. Некаторых выдаткаў можна пазбегнуць, выкарыстоўваючы кіраванае асяроддзе Kubernetes, такую як або .
Калі проста шукаеце надзейны аркестратар, просты ў падтрымцы і пашыраецца, чаму б не паспрабаваць Nomad? Магчыма, вы здзівіцеся, як далёка гэта вас завядзе.
Калі Kubernetes параўнаць з машынай, Nomad будзе скутэрам. Часам вам трэба адно, а часам іншае. Абодва маюць права на існаванне.
Крыніца: habr.com