🥇Знаёмства з Helm 3

Заўв. перав.: 16 мая гэтага года - значная вяха ў развіцці мэнэджара пакетаў для Kubernetes - Helm. У гэты дзень быў прадстаўлены першы альфа-рэліз будучай буйной версіі праекта - 3.0. Яе выйсце прынясе ў Helm істотныя і доўгачаканыя змены, на якія шматлікія ў Kubernetes-супольнасці ўскладаюць вялікія надзеі. Да такіх ставімся і мы самі, паколькі актыўна выкарыстоўваны Helm для дэплою прыкладанняў: мы інтэгравалі яго ў сваю прыладу для рэалізацыі CI/CD werf і калі-нікалі ўносім пасільны фундуш у развіццё upstream. Гэты пераклад аб'ядноўвае 7 нататак з афіцыйнага блога Helm, што прымеркаваны да першага альфа-рэлізу Helm 3 і распавядаюць аб гісторыі праекта і асноўных фічах Helm 3. Іх аўтар – Matt "bacongobbler" Fisher, супрацоўнік Microsoft і адзін з ключавых мэйнтэйнераў Helm.

15 кастрычніка 2015 г. нарадзіўся праект, цяпер вядомы як Helm. Усяго праз год пасля заснавання супольнасць Helm далучылася да Kubernetes, адначасна актыўна працуючы над Helm 2. У чэрвені 2018 года Helm увайшоў у склад CNCF у якасці які развіваецца (incubating) праекту. Перанясёмся ў сучаснасць і вось ужо на падыходзе першы альфа-рэліз новага Helm 3 (гэты рэліз ужо адбыўся у сярэдзіне траўня - заўв. перав.).

У гэтым гэтым матэрыяле я раскажу пра тое, з чаго ўсё пачыналася, як мы дайшлі да цяперашняй стадыі, прадстаўлю некаторыя ўнікальныя асаблівасці, даступныя ў першым альфа-рэлізе Helm 3, і растлумачу, як мы плануем развівацца далей.

Кароткі змест:

гісторыя стварэння Helm;
далікатнае развітанне з Tiller'ам;
рэпазітары чартаў;
кіраванне рэлізамі;
змены ў залежнасцях чартаў;
library charts;
што далей?

Гісторыя стварэння Helm

нараджэнне

Helm 1 пачынаўся як Open Source-праект, створаны кампаніяй Deis. Мы былі невялікім стартапам, паглынутым Microsoft увесну 2017 гады. У нашага іншага Open Source-праекта, які таксама носіць імя Deis, быў інструмент deisctl, які выкарыстоўваўся (акрамя іншага) для ўстаноўкі і эксплуатацыі платформы Deis ў кластары Fleet. У той час Fleet быў адной з першых платформ для аркестроўкі кантэйнераў.

У сярэдзіне 2015-га мы вырашылі змяніць курс і перавялі Deis (на той момант пераназваны ў Deis Workflow) з Fleet на Kubernetes. Адным з першых быў перапрацаваны інструмент усталёўкі deisctl. Мы выкарыстоўвалі яго для ўсталёўкі і кіравання Deis Workflow у кластары Fleet.

Helm 1 быў створаны па выяве і падабенству вядомых пакетных мэнэджараў, такіх як Homebrew, apt і yum. Яго асноўнай задачай з'яўлялася спрашчэнне такіх задач, як упакоўка і інсталяцыя прыкладанняў у Kubernetes. Афіцыйна Helm быў прадстаўлены ў 2015 годзе на канферэнцыі KubeCon у Сан-Францыска.

Наша першая спроба з Helm спрацавала, аднак не абышлося без сур'ёзных абмежаванняў. Ён браў набор маніфестаў Kubernetes, закрашаных генератарамі ў якасці ўступных YAML-блокаў (front-matter)*, і загружаў вынікі ў Kubernetes.

* Заўв. перав.: З першай версіі Helm для апісання рэсурсаў Kubernetes быў абраны сінтаксіс YAML, а пры напісанні канфігурацый падтрымліваліся шаблоны Jinja і Python-скрыпты. Падрабязней аб гэтым і прыладзе першай версіі Helm наогул мы пісалі ў раздзеле «Кароткая гісторыя Helm» гэтага матэрыялу.

Напрыклад, каб замяніць поле ў YAML-файле, трэба было дадаць у маніфест наступную канструкцыю:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

Класна, што сёння існуюць шаблонізатары, ці не праўда?

Па шматлікіх чынніках гэты ранні Kubernetes-усталёўнік патрабаваў цвёрда прапісаны спіс маніфест-файлаў і выконваў толькі невялікую фіксаваную паслядоўнасць падзей. Карыстацца ім было настолькі цяжка, што R&D-камандзе Deis Workflow прыйшлося несалодка, калі яны паспрабавалі перавесці свой прадукт на гэтую платформу – зрэшты, насенне ідэі ўжо былі пасеяныя. Наша першая спроба стала выдатнай магчымасцю для навучання: мы ўсвядомілі, што па-сапраўднаму захоплены стварэннем прагматычных інструментаў, якія вырашаюць штодзённыя праблемы для нашых карыстальнікаў.

Абапіраючыся на досвед мінулых памылак, мы прыступілі да распрацоўкі Helm 2.

Стварэнне Helm 2

У канцы 2015 года з намі звязалася каманда Google. Яны працавалі над падобнай прыладай для Kubernetes. Deployment Manager для Kubernetes быў портам існуючай прылады, які выкарыстоўваўся для Google Cloud Platform. «Ці не жадаем мы, – спыталі яны, – выдаткаваць некалькі дзён на абмеркаванне падабенстваў і адрозненняў?»

У студзені 2016 каманды Helm'а і Deployment Manager'а сустрэліся ў Сіэтле, каб абмяняцца ідэямі. Перамовы завяршыліся амбіцыйным планам: аб'яднаць абодва праекты, каб стварыць Helm 2. Разам з Deis і Google да каманды распрацоўшчыкаў далучыліся хлопцы з SkippBox (цяпер уваходзіць у склад Bitnami — заўв. перакл.), і мы прыступілі да працы над Helm 2.

Мы хацелі захаваць прастату выкарыстання Helm, але дадаць наступнае:

шаблоны чартаў для кастамізацыі;
унутрыкластэрнае кіраванне для каманд;
першакласны рэпазітар чартаў;
стабільны фармат пакетаў з магчымасцю подпісу;
цвёрдую прыхільнасць семантычнаму версіянаванню і захаванню зваротнай сумяшчальнасці паміж версіямі.

Для дасягнення гэтых мэт у экасістэму Helm быў дададзены другі элемент. Гэты внутрикластерный кампанент называўся Tiller і займаўся інсталяцыяй Helm-чартаў і іх кіраваннем.

З моманту выхаду Helm 2 у 2016-м Kubernetes аброс некалькімі сур'ёзнымі новаўвядзеннямі. З'явілася кіраванне доступам на аснове роляў (РБАК), якое ў канчатковым выніку замяніла кантроль доступу на аснове атрыбутаў (ABAC). Былі прадстаўлены новыя тыпы рэсурсаў (Deployments у той час па-ранейшаму заставаліся ў статуце бэта-версіі). Былі вынайдзены Custom Resource Definitions (першапачаткова яны зваліся Third Party Resources або TPRs). А самае галоўнае - з'явіўся набор лепшых практык.

На фоне ўсіх гэтых зменаў Helm працягваў служыць верай і праўдай карыстальнікам Kubernetes. Пасля трох гадоў і мноства новых дадаткаў стала ясна, што сітавіна ўносіць істотныя змены ў кодавую базу, каб Helm і далей мог задавальняць якія растуць запатрабаванні якая развіваецца экасістэмы.

Далікатнае развітанне з Tiller'ом

Падчас распрацоўкі Helm 2 мы прадставілі Tiller як частка нашай інтэграцыі з Deployment Manager'ам ад Google. Tiller гуляў важную ролю для каманд, якія працуюць у рамках агульнага кластара: ён дазваляў розным адмыслоўцам, якія эксплуатуюць інфраструктуру, узаемадзейнічаць з адным і тым жа наборам рэлізаў.

Паколькі кантроль доступу на аснове роляў (RBAC) быў па змаўчанні ўключаны ў Kubernetes 1.6, праца з Tiller'ам у production станавілася складаней. З-за вялікай колькасці магчымых палітык бяспекі наша пазіцыя складалася ў тым, каб па змаўчанні прапаноўваць дазвольную канфігурацыю. Гэта дазваляла пачаткоўцам праводзіць эксперыменты з Helm і Kubernetes без неабходнасці спачатку апускацца ў налады бяспекі. Нажаль, гэтая дазвольная канфігурацыя магла надзяліць карыстальніка занадта шырокім дыяпазонам дазволаў, якія яму не былі патрэбныя. DevOps-і SRE-інжынерам даводзілася вывучаць дадатковыя эксплуатацыйныя крокі, усталёўваючы Tiller у шматкарыстальніцкі (multi-tenant) кластар.

Даведаўшыся, як прадстаўнікі супольнасці выкарыстоўваюць Helm у канкрэтных сітуацыях, мы зразумелі, што сістэме кіравання рэлізамі Tiller'а не трэба спадзявацца на ўнутрыкластарны кампанент, каб падтрымліваць станы або функцыянаваць у якасці цэнтральнага хаба з інфармацыяй аб рэлізе. Замест гэтага мы маглі б проста атрымліваць інфармацыю ад API-сервера Kubernetes, генераваць чарт на баку кліента і захоўваць запіс аб усталёўцы ў Kubernetes.

Асноўную задачу Tiller'а можна было ажыццявіць і без Tiller'а, таму адным з першых нашых рашэнняў у стаўленні Helm 3 стала поўная адмова ад Tiller'а.

З сыходам Tiller'а мадэль бяспекі Helm радыкальна спрасцілася. Helm 3 зараз падтрымлівае ўсе сучасныя спосабы бяспекі, ідэнтыфікацыі і аўтарызацыі цяперашняга Kubernetes. Дазволы Helm вызначаюцца з дапамогай файла kubeconfig. Адміністратары кластара могуць абмяжоўваць правы карыстальнікаў з любой ступенню дэталізацыі. Рэлізы па-ранейшаму захоўваюцца ўнутры кластара, астатняя функцыянальнасць Helm захоўваецца.

Рэпазітары чартаў

На высокім узроўні рэпазітар чартаў - гэта месца, дзе можна захоўваць і сумесна выкарыстоўваць чарты. Кліент Helm пакуе і адпраўляе чарты ў рэпазітар. Прасцей кажучы, рэпазітар чартаў - гэта прымітыўны HTTP-сервер з файлам index.yaml і некаторымі спакаванымі чартамі.

Хоць ёсць некаторыя перавагі ў тым, што API рэпазітара чартаў адказвае найболей асноўным патрабаванням да сховішча, у яго ёсць і некалькі недахопаў:

Рэпазітары чартаў дрэнна сумяшчальныя з большасцю рэалізацый бяспекі, неабходных у production-акружэнні. Наяўнасць стандартнага API для аўтэнтыфікацыі і аўтарызацыі вельмі важна ў production-сцэнарах.
Інструменты Helm'а для адсочвання паходжання чарта, якія выкарыстоўваюцца для подпісу, праверкі цэласнасці і паходжання чарта, з'яўляюцца неабавязковай часткай працэсу публікацыі Chart'а.
У шматкарыстальніцкіх сцэнарах адзін і той жа чарт можа быць загружаны іншым карыстачом, у два разу павялічваючы аб'ём прасторы, неабходны для захоўвання аднаго і таго ж кантэнту. Для вырашэння гэтай праблемы былі распрацаваны больш разумныя рэпазітары, аднак яны не з'яўляюцца часткай фармальнай спецыфікацыі.
Выкарыстанне адзінага індэкс-файла для пошуку, захоўвання метададзеных і атрымання чартаў ўскладніла распрацоўку бяспечных шматкарыстальніцкіх рэалізацый.

праект Docker Distribution (таксама вядомы як Docker Registry v2) з'яўляецца пераемнікам Docker Registry і фактычна выступае наборам прылад для пакавання, адпраўкі, захоўванні і пастаўкі выяў Docker. Многія буйныя хмарныя сэрвісы прапануюць прадукты на аснове Distribution. Дзякуючы такой падвышанай увазе праект Distribution выйграў ад шматгадовых удасканаленняў, лепшых практык у вобласці бяспекі і тэставанні ў баявых умовах, якія ператварылі яго ў аднаго з самых паспяховых недаспетых герояў міру Open Source.

Але ці ведаеце вы, што праект Distribution быў распрацаваны для распаўсюджвання любой формы кантэнту, а не толькі вобразаў кантэйнераў?

Дзякуючы намаганням Ініцыятыва адкрытага кантэйнера (або OCI), Helm-чарты могуць быць размешчаны на любым экзэмпляры Distribution. Пакуль гэты працэс мае эксперыментальны характар. Праца над падтрымкай лагінаў і іншымі функцыі, неабходнымі для паўнавартаснага Helm 3, яшчэ не скончана, але мы вельмі рады магчымасці вучыцца на адкрыццях, зробленых камандамі OCI і Distribution за гэтыя гады. А дзякуючы іх настаўніцтву і кіраўніцтву мы даведваемся, што такое эксплуатацыя высокадаступнага сэрвісу ў вялікім маштабе.

Больш падрабязнае апісанне некаторых маючых адбыцца змен у рэпазітарах Helm-чартаў даступна па спасылцы.

Упраўленне рэлізамі

У Helm 3 стан прыкладання адсочваецца ўнутры кластара парай аб'ектаў:

release object - уяўляе асобнік прыкладання;
release version secret - уяўляе жаданае стан прыкладання ў пэўны момант часу (напрыклад, рэліз новай версіі).

выклік helm install стварае release object і release version secret. Выклік helm upgrade патрабуе наяўнасці release object (які ён можа змяняць) і стварае новы release version secret, які змяшчае новыя значэнні і падрыхтаваны маніфест.

Release object змяшчае інфармацыю аб рэлізе, дзе рэліз - канкрэтная інсталяцыя названага чарта і значэнняў. Гэты аб'ект апісвае метададзеныя верхняга ўзроўню аб рэлізе. Release object захоўваецца на працягу ўсяго жыццёвага цыклу прыкладання і выступае ўладальнікам усіх release version secret'аў, а таксама ўсіх аб'ектаў, якія непасрэдна ствараюцца Helm-чартам.

Release version secret звязвае рэліз з серыяй рэвізій (усталёўка, абнаўленні, адкаты, выдаленне).

У Helm 2 рэвізіі былі выключна паслядоўнымі. Выклік helm install ствараў v1, наступнае абнаўленне (upgrade) - v2, і гэтак далей. Release і release version secret былі згорнуты ў адзіны аб'ект, вядомы як revision. Revision'ы захоўваліся ў той жа прасторы імёнаў, што і Tiller, што азначала, што кожны рэліз быў "глабальны" у плане прасторы імёнаў; у выніку можна было выкарыстоўваць толькі адзін асобнік імя.

У Helm 3 кожны рэліз злучаны з адным ці некалькімі release version secret'амі. Release object заўсёды апісвае бягучы рэліз, разгорнуты ў Kubernetes. Кожны release version secret апісвае толькі адну версію гэтага рэлізу. Абнаўленне (upgrade), напрыклад, створыць новы release version secret і затым зменіць release object, каб той паказваў на гэтую новую версію. У выпадку адкату (rollback) можна выкарыстоўваць папярэднія release version secret'ы, каб адкаціць рэліз да папярэдняга стану.

Пасля адмовы ад Tiller'а Helm 3 захоўвае дадзеныя аб рэлізе ў адзіным з рэлізам прасторы імёнаў. Падобная змена дазваляе ўсталеўваць чарт з такім жа імем рэлізу ў іншую прастору імёнаў, і дадзеныя захоўваюцца паміж абнаўленнямі/перазагрузкамі кластара ў etcd. Напрыклад, можна ўсталяваць WordPress у прастору імёнаў "foo", а затым у прастору імёнаў "bar", і абодва рэлізу могуць звацца "wordpress".

Змены ў залежнасцях чартаў

Чарты, спакаваныя (з дапамогай helm package) для выкарыстання з Helm 2, можна ўсталеўваць з Helm 3, аднак працоўны працэс распрацоўкі чартаў быў цалкам перагледжаны, таму неабходна ўнесці некаторыя змены, каб працягнуць распрацоўку чартаў з Helm 3. У прыватнасці, змянілася сістэма кіравання залежнасцямі чартаў.

Сістэма кіравання залежнасцямі чарта перайшла з requirements.yaml и requirements.lock на Chart.yaml и Chart.lock. Гэта азначае, што чарты, якія выкарыстоўвалі каманду helm dependency, патрабуюць некаторай наладкі, каб працаваць у Helm 3.

Давайце разгледзім прыклад. Дадамо залежнасць да чарта ў Helm 2 і паглядзім, што зменіцца пры пераходзе да Helm 3.

У Helm 2 requirements.yaml выглядаў наступным чынам:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

У Helm 3 тая ж залежнасць будзе адлюстравана ў вашым Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Чарты па-ранейшаму загружаюцца і змяшчаюцца ў дырэкторыю charts/, таму субчарты (subcharts), якія ляжаць у каталогу charts/, працягнуць працаваць без змен.

Прадстаўляем Library Charts

Helm 3 падтрымлівае клас чартаў, які атрымаў назву чартаў-бібліятэк. (library chart). Гэты чарт выкарыстоўваецца іншымі чартамі, але самастойна не стварае ніякіх артэфактаў рэлізу. Шаблоны library chart'ов могуць аб'яўляць толькі элементы define. Іншы кантэнт проста ігнаруецца. Гэта дазваляе карыстальнікам паўторна выкарыстоўваць і абменьвацца фрагментамі кода, якія можна задзейнічаць у многіх чартах, тым самым пазбегнуўшы дубліравання і прытрымліваючыся прынцыпу. DRY.

Library charts аб'яўляюцца ў раздзеле dependencies у файле Chart.yaml. Ўстаноўка і кіраванне імі не адрозніваюцца ад іншых чартаў.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

Мы з прадчуваннем чакаем варыянтаў выкарыстання, якія гэты кампанент адкрые перад распрацоўшчыкамі чартаў, а таксама лепшых практык, што могуць узнікнуць дзякуючы library charts.

Што далей?

Helm 3.0.0-alpha.1 - аснова, абапіраючыся на якую, мы пачынаем ствараць новую версію Helm. У артыкуле я апісаў некаторыя цікавыя магчымасці Helm 3. Многія з іх пакуль знаходзяцца на ранніх стадыях распрацоўкі і гэта нармальна; сутнасць альфа-рэлізу ў тым, каб праверыць ідэю, сабраць водгукі ад першых карыстальнікаў і пацвердзіць нашыя здагадкі.

Як толькі альфа-версія будзе выпушчана (нагадаем, што гэта ужо адбылося - заўв. перав.), мы пачнем прымаць патчы для Helm 3 ад супольнасці. Неабходна стварыць надзейны падмурак, які дазволіць распрацоўваць і прымаць новыя функцыянальныя магчымасці, а карыстачы змогуць пачувацца ўцягнутымі ў працэс, адчыняючы цікеты і уносячы выпраўленні.

У артыкуле я пастараўся асвятліць некаторыя сур'ёзныя паляпшэнні, якія з'явяцца ў Helm 3, аднак гэты спіс ні ў якім разе нельга назваць вычарпальным. Поўнамаштабны план для Helm 3 уключае ў сябе такія новаўвядзенні, як палепшаныя стратэгіі абнаўлення, глыбейшая інтэграцыя з рэестрамі OCI і выкарыстанне JSON-схем для праверкі значэнняў чартаў. Таксама мы плануем ачысціць кодавую базу і абнавіць тыя яе часткі, якія заставаліся без увагі апошнія тры гады.

Калі адчуваеце, што мы нешта ўпусцілі, будзем рады пачуць вашыя думкі!

Далучайцеся да абмеркавання ў нашых Slack-каналах:

#helm-users для пытанняў і простых зносін з супольнасцю;
#helm-dev для абмеркавання pull requests, кода і багаў.

Вы таксама можаце пагутарыць у нашых штотыднёвых Public Developer Calls па чацвяргах у 19:30 MSK. Сустрэчы прысвечаны абмеркаванню задач, над якімі працуюць ключавыя распрацоўшчыкі і супольнасць, а таксама тэмам абмеркавання на тыдзень. Любы ахвочы можа далучыцца і прыняць удзел у сустрэчы. Спасылка даступна ў Slack-канале #helm-dev.

PS ад перакладчыка

Чытайце таксама ў нашым блогу:

Крыніца: habr.com

Знаёмства з Helm 3