Услед за мы прадстаўляем яго старэйшага брата - . Гэта Open Source-праект, які выкарыстоўваецца для ўстаноўкі ў кластар Kubernetes сістэмных кампанентаў, якія можна назваць агульным словам - дапаўненні.
Навошта ўвогуле нейкія дапаўненні?
Не сакрэт, што Kubernetes гэта не гатовы прадукт усё-у-адным, і для пабудовы "дарослага" кластара спатрэбяцца розныя дапаўненні. Addon-operator дапаможа ўсталяваць, наладзіць і падтрымліваць гэтыя дадаткі ў актуальным стане.
Неабходнасць дадатковых кампанентаў у кластары расчынена ў калегі . Сцісла, сітуацыя з Kubernetes на дадзены момант такая, што для простай усталёўкі «пагуляцца» можна абыйсціся кампанентамі са скрынкі, для распрацоўнікаў і тэставанні можна дадаць Ingress, а вось для паўнавартаснай усталёўкі, пра якую можна сказаць «ваш production гатовы», неабходна дадаць з дзясятак розных дадаткаў: нешта для маніторынгу, нешта для логаў, не забыцца ingress і cert-manager, вылучыць групы вузлоў, дадаць сеткавыя палітыкі, заправіць наладамі sysctl і pod autoscaler'ам…
У чым спецыфіка працы з імі?
Як паказвае практыка, адной устаноўкай справа не абмяжоўваецца. Для камфортнай працы з кластарам дадаткі трэба будзе абнаўляць, адключаць (выдаляць з кластара), а нешта захочацца пратэставаць перад усталёўкай у production-кластар.
Дык, можа, тут і Ansible хопіць? Магчыма. Але паўнавартасныя дапаўненні ў агульным выпадку не жывуць без настроек. Гэтыя налады могуць адрознівацца ў залежнасці ад варыянту кластара (aws, gce, azure, bare-metal, do, …). Некаторыя налады нельга задаць загадзя - іх трэба атрымліваць з кластара. А кластар не статычны: для некаторых налад давядзецца сачыць за зменамі. І тут ужо Ansible бракуе: патрэбна праграма, якая жыве ў кластары, г.зн. Kubernetes Operator.
Тыя, хто паспрабаваў у працы , скажуць, што задачы ўстаноўкі і абнаўлення дапаўненняў і сачэння за наладамі цалкам можна вырашыць з дапамогай для shell-operator. Можна напісаць скрыпт, які будзе рабіць умоўны kubectl apply і сачыць, напрыклад, за ConfigMap, дзе будуць захоўвацца налады. Прыкладна гэта і рэалізавана ў addon-operator.
Як гэта арганізавана ў addon-operator?
Ствараючы новае рашэнне, мы зыходзілі з наступных прынцыпаў:
- Усталёўшчык дадаткаў павінен падтрымліваць шаблонізацыю і дэкларатыўную канфігурацыю. Не які робіцца магічных скрыптоў, якія ўсталёўваюць дадаткі. Addon-operator выкарыстоўвае Helm для ўстаноўкі дапаўненняў. Для ўсталёўкі трэба стварыць чарт і вылучыць values, якія будуць скарыстаны для налады.
- Настройкі можна генераваць пры ўстаноўцы, іх можна атрымаць з кластара, Альбо атрымліваць абнаўлення, сочачы за рэсурсамі кластара. Гэтыя аперацыі можна рэалізаваць з дапамогай хукаў.
- Настройкі можна захоўваць у кластары. Для захоўвання налад у кластары ствараецца ConfigMap/addon-operator і Addon-operator сочыць за зменамі гэтага ConfigMap. Addon-operator дае хукам доступ да налад з дапамогай простых пагадненняў.
- Дадатак залежыць ад налад. Калі налады змяніліся, то Addon-operator выкочвае Helm-чарт з новымі values. Аб'яднанне Helm-чарта, values для яго і хукаў мы назвалі модулем (падрабязней гл. ніжэй).
- Стейджаванне. Няма магічных рэліз-скрыптоў. Механізм абнаўленняў аналагічны звычайнаму з дадаткам - сабраць дапаўненні і addon-operator у вобраз, пратэгаваць і выкаціць.
- Кантроль выніку. Addon-operator умее аддаваць метрыкі для Prometheus.
Што такое дадатак у addon-operator?
Дадаткам можна лічыць усё, што дадае ў кластар новыя функцыі. Напрыклад, усталёўка Ingress - выдатны прыклад дадатку. Гэта можа быць любы аператар ці кантролер са сваім CRD: prometheus-operator, cert-manager, kube-controller-manager, і т.д. Ці нешта невялікае, але якое спрашчае эксплуатацыю — напрыклад, secret copier, які капіюе registry-сакрэты ў новыя прасторы імёнаў, або sysctl tuner, які наладжвае параметры sysctl на новых вузлах.
Для рэалізацыі дадаткаў Addon-operator падае некалькі канцэпцый:
- Дыяграма руля выкарыстоўваецца, каб усталёўваць у кластар рознае ПА - напрыклад, Prometheus, Grafana, nginx-ingress. Калі ў патрэбнага кампанента ёсць Helm-чарт, тое ўсталяваць яго з дапамогай Addon-operator будзе вельмі проста.
- Сховішча values. У Helm-чартаў звычайна ёсць шмат розных налад, якія могуць мяняцца з часам. Addon-operator падтрымлівае захоўванне гэтых налад і ўмее сачыць за іх зменамі, каб пераўсталяваць Helm-чарт з новымі значэннямі.
- Хукі - гэта выкананыя файлы, якія Addon-operator запускае па падзеях і якія атрымліваюць доступ да сховішча values. Хук можа сачыць за зменамі ў кластары і абнаўляць значэння ў сховішча values. Г.зн. з дапамогай хукаў можна зрабіць discovery, каб збіраць значэння з кластара пры старце або па раскладзе, а можна і continuous discovery, збіраючы значэння з кластара па зменах у кластары.
- модуль - гэта аб'яднанне Helm-чарта, сховішчы values і хукаў. Модулі можна ўключаць і адключаць. Адключэнне модуля - гэта выдаленне ўсіх рэлізаў Helm-чарта. Модулі могуць уключаць самі сябе дынамічна, напрыклад, калі ўключаны ўсе неабходныя яму модулі або калі discovery у хуках знайшоў патрэбныя параметры - гэта робіцца з дапамогай дапаможнага enabled-скрыпту.
- Глабальныя хукі. Гэта хукі "самі па сабе", яны не ўключаны ў модулі і маюць доступ да глабальнага сховішча values, значэнні з якога даступна ўсім хукам у модулях.
Як гэтыя часткі працуюць разам? Разгледзім карцінку з дакументацыі:
Сцэнарыя працы два:
- Глабальны хук запускаецца па падзеі - напрыклад, пры змене рэсурсу ў кластары. Гэты хук апрацоўвае змены і запісвае новыя значэнні ў глабальнае сховішча values. Addon-operator заўважае, што глабальнае сховішча змянілася і запускае ўсе модулі. Кожны модуль з дапамогай сваіх хукаў вызначае, ці трэба яму ўключацца, і абнаўляе сваё сховішча values. Калі модуль уключаны, то Addon-operator запускае ўсталёўку Helm-чарта. Helm-чарту пры гэтым даступныя values са сховішча модуля і з глабальнага сховішча.
- Другі сцэнар прасцей: модульны хук запускаецца па падзеі, змяняе значэнні ў сховішчы values модуля. Addon-operator гэта заўважае і запускае Helm-чарт з абноўленымі values.
Дадатак можа быць рэалізавана выглядзе аднаго адзінага хука ці як адзін Helm-чарт, ці нават як некалькі залежных модуляў - гэта залежыць ад складанасці усталёўванага ў кластар кампанента і ад патрэбнага ўзроўня гнуткасці налад. Напрыклад, у рэпазітары () ёсць дадатак sysctl-tuner, якое рэалізавана як у выглядзе простага модуля з хукам і Helm-чартам, так і з выкарыстаннем сховішчы values, што дае магчымасць дадаваць налады праз рэдагаванне ConfigMap.
Дастаўка абнаўленняў
Некалькі слоў пра арганізацыю абнаўленняў кампанентаў, якія ўстанаўлівае Addon-operator.
Каб запусціць Addon-operator у кластары, трэба сабраць вобраз з дапаўненнямі у выглядзе файлаў хуков і Helm-чартаў, дадаць бінарны файл addon-operator і ўсё, што спатрэбіцца хукам: bash, kubectl, jq, python і г.д. Далей гэта выява можна выкочваць у кластар як звычайнае прыкладанне і хутчэй за ўсё вы захочаце арганізаваць тую ці іншую схему тэгавання. Калі кластараў няшмат, можа падысці той жа падыход, што і з праграмамі: новы рэліз, новая версія, пайсці па ўсіх кластарах і паправіць image у Pod'ов. Аднак, у выпадку выкату на адчувальную колькасць кластараў, нам больш падышла канцэпцыя самаабнаўлення з канала.
У нас гэта зроблена так:
- Канал - гэта па сутнасці ідэнтыфікатар, які можна задаваць любым (напрыклад, dev/stage/ea/stable).
- Імя канала - гэта тэг выявы. Калі трэба выкаціць абнаўленні ў канал, тое збіраецца новая выява і тэгуецца імем канала.
- Калі ў registry з'яўляецца новая выява, Addon-operator рэстартуецца і запускаецца з новай выявай.
Гэта не best practice, пра што напісана ў . Так рабіць не рэкамендуецца, але гаворка ідзе пра звычайнае дадатак, якое жыве ў адным кластары. У выпадку Addon-operator дадатак – гэта мноства Deployments, якія былі раскіданыя па кластарах, і самаабнаўленне вельмі моцна дапамагае і спрашчае жыццё.
Каналы дапамагаюць і у тэсціраванні: калі ёсць дапаможны кластар, можна наладзіць яго на канал stage і катаць абнаўленні ў яго перад выкатам у каналы ea и stable. Калі з кластарам на канале ea адбылася памылка, можна яго пераключыць на stable, пакуль ідзе расследаванне праблемы з гэтым кластарам. Калі кластар выведзены з актыўнай падтрымкі, ён перамыкаецца на свой "застылы" канал - напрыклад, freeze-2019-03-20.
Апроч абнаўленняў хукаў і Helm-чартаў можа спатрэбіцца абнавіць і іншы кампанент. Напрыклад, вы заўважылі памылку ва ўмоўным node-exporter і нават прыдумалі, як яго прапатчыць. Далей адкрылі PR і чакаеце новага рэлізу, каб прайсціся па ўсіх кластарах і павялічыць версію выявы. Каб не чакаць нявызначаны час, можна сабраць свой node-exporter і пераключыцца на яго да прыняцця PR.
Увогуле, гэта можна і без Addon-operator зрабіць, але з Addon-operator модуль для ўсталёўкі node-exporter будзе навідавоку ў адным рэпазітары, Dockerfile для зборкі сваёй выявы можна трымаць тут жа, усім удзельнікам працэсу становіцца прасцей разумець, што адбываецца… А калі кластараў некалькі, тое становіцца прасцей як тэставаць свой PR, так і накатваць новую версію!
Гэтая арганізацыя абнаўлення кампанентаў працуе паспяхова ў нас, але можна рэалізаваць і любую іншую прыдатную схему - бо у дадзеным выпадку Addon-operator з'яўляецца простым бінарным файлам.
Заключэнне
Прынцыпы, рэалізаваныя ў Addon-operator, дазваляюць выбудаваць празрысты працэс стварэння, тэставанні, усталёўкі і абнаўленні дадаткаў у кластары, аналагічны працэсам распрацоўкі звычайных прыкладанняў.
Дадаткі для Addon-operator у фармаце модуляў (Helm-чарт + хукі) можна выкладваць у шырокі доступ. Мы, кампанія Флант, плануем выкласці на працягу лета нашы напрацоўкі ў выглядзе такіх дадаткаў. Далучайцеся да распрацоўкі на GitHub (, ), спрабуйце зрабіць свой дадатак на аснове и , чакайце навін на Хабры і на нашым !
PS
Чытайце таксама ў нашым блогу:
- «»;
- «.
Крыніца: habr.com