🥇 Ви го претставуваме Helm 3

Забелешка. превод.: 16 мај оваа година е значајна пресвртница во развојот на менаџерот на пакети за Kubernetes - Helm. На денешен ден беше претставено првото алфа издание на идната голема верзија на проектот, 3.0. Неговото објавување ќе донесе значајни и долгоочекувани промени во Helm, за кои многумина во заедницата Кубернетес имаат големи надежи. Ние самите сме меѓу нив, бидејќи активно го користиме Helm за распоредување апликации: го интегриравме во нашата алатка за имплементирање CI / CD верф и од случај до случај даваме остварлив придонес во развојот на возводно. Овој превод комбинира 7 белешки од официјалниот блог Helm кои се посветени на првото алфа издание на Helm 3 и раскажуваат за историјата на проектот и главните карактеристики на Helm 3. Нивниот автор е Мет „баконгоблер“ Фишер, вработен во Microsoft и еден од клучните одржувачи на Хелм.

На 15 октомври 2015 година се роди проектот сега познат како Хелм. Само една година по нејзиното основање, заедницата Хелм се приклучи на Кубернетес додека активно работеше на Хелм 2. Во јуни 2018 година, Хелм се приклучи на CNCF како проект за инкубација. Брзо напред кон сегашноста и првото алфа издание на новиот Helm 3 е на пат. (ова издание веќе се одржа во средината на мај - прибл. превод.).

Во оваа статија, ќе разгледам како започна сè, како стигнавме до каде што е денес, ќе воведам некои од уникатните функции достапни во првото алфа издание на Helm 3 и ќе објаснам како планираме да продолжиме напред.

Резиме:

историјата на создавањето на Хелм;
нежно збогување со Тилер;
складишта на графикони;
управување со ослободување;
промени во зависностите на графиконот;
библиотечни графикони;
што е следно?

Историја на Хелм

Раѓањето на

Helm 1 започна како проект со отворен код создаден од Deis. Бевме мал стартап апсорбира Мајкрософт во пролетта 2017 година. Нашиот друг проект со отворен код, исто така наречен Деис, имаше алатка deisctlшто се користеше (меѓу другото) за инсталирање и управување со платформата Deis во Кластер на флота. Во тоа време, Fleet беше една од првите платформи за оркестрација на контејнери.

Во средината на 2015 година, решивме да го промениме курсот и го префрливме Deis (тогаш преименуван во Deis Workflow) од Fleet во Kubernetes. Еден од првите беше редизајнираната алатка за инсталација deisctl. Го користевме за инсталирање и управување со Deis Workflow на Fleet кластер.

Helm 1 е создаден според сликата и сличноста на познатите менаџери на пакети како Homebrew, apt и yum. Неговата главна цел беше да ги поедностави задачите како пакување и инсталирање апликации во Кубернетес. Helm беше официјално претставен во 2015 година на конференцијата KubeCon во Сан Франциско.

Нашиот прв обид со Хелм успеа, но не беше без сериозни ограничувања. Тој зеде комплет Кубернетес манифести со вкус на генератори како воведни YAML блокови. (предна работа)* и ги постави резултатите на Кубернетес.

* Забелешка. превод.: Од првата верзија на Helm, синтаксата YAML беше избрана за да ги опише ресурсите на Kubernetes, а шаблоните од Jinja и скриптите на Python беа поддржани при пишување конфигурации. Напишавме повеќе за ова и воопшто за уредот на првата верзија на Helm во поглавјето „Кратка историја на Helm“ овој материјал.

На пример, за да замените поле во датотека YAML, би ја додале следната конструкција на вашиот манифест:

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

Убаво е што постојат мотори за шаблони денес, нели?

Од многу причини, овој ран инсталатер на Кубернетес бараше хард-кодирана листа на датотеки со манифест и извршуваше само мала, фиксна низа на настани. Беше толку тешко да се искористи што тимот за истражување и развој на Deis Workflow имаше тешко време кога се обидоа да го пренесат својот производ на оваа платформа - сепак, семето на идејата веќе беше посеано. Нашиот прв обид беше одлична можност за учење бидејќи сфативме дека сме навистина страсни за градење прагматични алатки кои решаваат секојдневни проблеми за нашите корисници.

Врз основа на искуството од минатите грешки, го започнавме развојот на Helm 2.

Изработка на кормила 2

На крајот на 2015 година бевме контактирани од тимот на Google. Тие работеа на слична алатка за Kubernetes. Управникот за распоредување за Kubernetes беше пристаниште на постоечка алатка што се користи за Google Cloud Platform. „Дали сме подготвени“, прашаа тие, „да поминеме неколку дена разговарајќи за сличностите и разликите?

Во јануари 2016 година, тимовите на Helm и Deployment Manager се состанаа во Сиетл за да разменат идеи. Разговорите кулминираа со амбициозен план за спојување на двата проекти за создавање Helm 2. Заедно со Deis и Google, момците од SkipBox (сега дел од Битнами - прибл. превод.), и почнавме да работиме на Helm 2.

Сакавме да ја задржиме леснотијата на користење на Helm, но го додадеме следново:

шаблони за графикони за прилагодување;
интракластерско управување за тимови;
врвно складиште за графикони;
стабилен формат на пакет со можност за потпишување;
силна посветеност на семантичко верзии и одржување на компатибилност помеѓу верзиите.

За да се постигнат овие цели, додаден е втор елемент во екосистемот Хелм. Оваа компонента во кластерот беше наречена Tiller и беше одговорна за инсталирање и управување со табелите на Helm.

Од објавувањето на Helm 2 во 2016 година, Kubernetes забележа неколку големи иновации. Воведена е контрола на пристап заснована на улоги (RBAC), што на крајот ја замени контролата за пристап базирана на атрибути (ABAC). Беа воведени нови типови ресурси (распоредувањата во тоа време сè уште беа во бета верзија). Беа измислени прилагодени дефиниции за ресурси (првично наречени ресурси од трета страна или TPR). И што е најважно, се појави збир на најдобри практики.

Покрај сите овие промени, Helm продолжи верно да им служи на корисниците на Kubernetes. По три години и многу нови дополнувања, беше јасно дека е време да се направат значителни промени во основата на кодот, така што Хелм може да продолжи да ги задоволува растечките потреби на екосистемот што се развива.

Нежно збогување со Тилер

За време на развојот на Helm 2, го претставивме Tiller како дел од нашата интеграција со Менаџерот за распоредување на Google. Тилер одигра важна улога за тимовите кои работат во заеднички кластер: им овозможи на различни специјалисти кои управуваат со инфраструктурата да комуницираат со истиот сет на изданија.

Бидејќи контролата на пристап заснована на улоги (RBAC) беше стандардно овозможена во Kubernetes 1.6, работата со Tiller во производството стана потешка. Поради големиот број можни безбедносни политики, нашата позиција беше стандардно да понудиме попустлива конфигурација. Ова им овозможи на почетниците да експериментираат со Helm и Kubernetes без претходно да се нурнат во безбедносните поставки. За жал, оваа попустлива конфигурација може да му даде на корисникот премногу широк опсег на дозволи што не му требаат. Инженерите на DevOps и SRE мораа да научат дополнителни оперативни чекори при инсталирање на Tiller во кластер со повеќе станари.

Дознавајќи како заедницата го користи Helm во специфични ситуации, сфативме дека системот за управување со издавање на Tiller не треба да се потпира на компонента во кластерот за да одржува состојби или да дејствува како централен центар за информации за објавување. Наместо тоа, можеме само да добиеме информации од серверот на Kubernetes API, да генерираме графикон на страната на клиентот и да зачуваме запис за инсталација на Kubernetes.

Главната цел на Тилер можеше да се направи без Тилер, така што една од нашите први одлуки во врска со Хелм 3 беше целосно да го напуштиме Тилер.

Со заминувањето на Тилер, безбедносниот модел на Хелм беше радикално поедноставен. Helm 3 сега ги поддржува сите модерни безбедносни, идентификациски и овластувачки карактеристики на денешните Kubernetes. Дозволите на кормилото се дефинирани со kubeconfig датотека. Администраторите на кластерите можат да ги ограничат корисничките права на која било грануларност. Изданијата сè уште се чуваат во кластерот, а остатокот од функционалноста на Helm е зачувана.

Складишта на графикони

На високо ниво, складиштето за графикони е место каде што може да се складираат и споделуваат графиконите. Клиентот Helm ги пакува и ги турка графиконите до складиштето. Едноставно кажано, складиштето за графикони е примитивен HTTP сервер со датотека index.yaml и некои спакувани графикони.

Иако има некои предности на Charts Repository API што ги исполнува најосновните барања за складирање, тој има и неколку недостатоци:

Складиштата на графиконите не се компатибилни со повеќето безбедносни имплементации потребни во производствената средина. Имањето стандарден API за автентикација и овластување е од суштинско значење во сценаријата за производство.
Алатките за потекло на графиконот на Хелм, кои се користат за потпишување, потврдување на интегритетот и потеклото на графиконот, се изборен дел од процесот на објавување на графиконот.
Во сценарија со повеќе корисници, истиот графикон може да се вчита од друг корисник, со што се удвојува просторот потребен за складирање на истата содржина. Развиени се попаметни складишта за да се реши ова прашање, но тие не се дел од формалната спецификација.
Употребата на една индексна датотека за пребарување, складирање метаподатоци и преземање графикони го отежна развојот на безбедни имплементации за повеќе корисници.

Проект Докер дистрибуција (исто така познат како Docker Registry v2) е наследник на Docker Registry и всушност е збир на алатки за пакување, испорака, складирање и дистрибуција на Docker слики. Многу големи облак услуги нудат производи базирани на Дистрибуција. Со ова зголемено внимание, проектот Дистрибуција има корист од годините на усовршување, најдобри безбедносни практики и теренско тестирање што го претворија во еден од најуспешните неопеани херои на светот со отворен код.

Но, дали знаевте дека проектот Дистрибуција беше дизајниран да дистрибуира каква било форма на содржина, а не само слики од контејнери?

Благодарение на напорите Иницијатива за отворен контејнер (или OCI), табелите на кормилото може да се постават на кој било пример на Дистрибуција. Досега овој процес е експериментален. Работата на поддршката за најавување и другите карактеристики потребни за целосна Helm 3 сè уште е во тек, но ние сме возбудени што учиме од откритијата направени од тимовите OCI и Distribution низ годините. И преку нивното менторство и насоки, учиме како е да се управува со високо достапна услуга на размер.

Достапен е подетален опис на некои од претстојните промени во складиштата на Helm Chart. по ссылке.

Управување со издавање

Во Helm 3, состојбата на апликацијата се следи во кластерот со неколку објекти:

ослободувачки објект - претставува пример на апликација;
тајна верзија на издавање - ја претставува посакуваната состојба на апликацијата во одреден момент во времето (на пример, објавување на нова верзија).

Повик helm install создава објект за ослободување и тајна за верзијата за ослободување. Јавете се helm upgrade бара објект за ослободување (кој може да го модифицира) и создава тајна нова верзија на издавање што ги содржи новите вредности и подготвен манифест.

Објектот за ослободување содржи информации за изданието, каде што ослободувањето е специфична инсталација на именуваниот графикон и вредности. Овој објект опишува метаподатоци од највисоко ниво за изданието. Објектот за ослободување опстојува во текот на животниот циклус на апликацијата и е сопственик на сите тајни на верзијата за издавање, како и на сите објекти кои се директно креирани од табелата на Helm.

Тајната верзија на верзијата го поврзува изданието со серија ревизии (инсталација, ажурирања, враќања, бришења).

Во Helm 2, ревизиите беа исклучително конзистентни. Јавете се helm install создадена v1, последователно ажурирање (надградба) - v2, и така натаму. Тајната на верзијата за издавање и издавање се преклопени во еден ентитет познат како ревизија. Ревизиите беа чувани во истиот именски простор како Tiller, што значеше дека секое издание е „глобално“ во однос на именскиот простор; како резултат на тоа, може да се користи само еден пример од името.

Во Helm 3, секое издание е поврзано со една или повеќе тајни за верзијата на изданието. Објектот за ослободување секогаш го опишува тековното издание распоредено на Kubernetes. Секоја тајна на верзијата опишува само една верзија на тоа издание. Надградбата, на пример, ќе создаде тајна нова верзија на изданието, а потоа ќе го промени објектот за издавање за да укаже на таа нова верзија. Во случај на враќање назад, можете да ги користите тајните на претходната верзија за да го вратите изданието во претходната состојба.

По отфрлањето на Tiller, Helm 3 ги складира податоците за објавување во истиот именски простор како и изданието. Таквата промена ви овозможува да инсталирате табела со исто име на издание во различен именски простор, а податоците се зачувуваат помеѓу ажурирањата / рестартирањата на кластерот во итн. На пример, можете да го инсталирате WordPress во именскиот простор „foo“, а потоа во именскиот простор „бар“, и двете изданија може да се нарекуваат „вордпрес“.

Промени во зависност од графиконот

Спакувани графикони (со користење helm package) за употреба со Helm 2 може да се инсталира со Helm 3, но работниот тек за развој на графикони е целосно ремонтиран, така што треба да се направат некои промени за да се продолжи со развивање на графикони со Helm 3. Особено, системот за управување со зависноста од графикони е променет.

Системот за управување со зависноста на графиконот се пресели од requirements.yaml и requirements.lock на Chart.yaml и Chart.lock. Ова значи дека графиконите што ја користеле командата helm dependency, бара одредена конфигурација за да работи во Helm 3.

Ајде да погледнеме на пример. Ајде да додадеме зависност на графиконот во Helm 2 и да видиме што се менува кога се префрламе на Helm 3.

Во кормилото 2 requirements.yaml изгледаше вака:

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

Во Хелм 3 истата зависност ќе се одрази и кај вас Chart.yaml:

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

Табелите сè уште се преземаат и се ставаат во директориумот charts/, па потграфите (потграфи)се наоѓа во директориумот charts/ќе продолжи да работи без промени.

Воведување графикони за библиотеки

Helm 3 поддржува класа на графикони наречени библиотечни графикони (библиотечна табела). Оваа табела се користи од други графикони, но не генерира артефакти за издавање самостојно. Шаблоните на графиконите на библиотеката можат да декларираат само елементи define. Другите содржини едноставно се игнорираат. Ова им овозможува на корисниците повторно да користат и споделуваат фрагменти од код што може да се користат во многу графикони, со што се избегнува дуплирање и придржување до принципот СУВА.

Библиотечните графикони се декларирани во делот dependencies во датотека Chart.yaml. Инсталирањето и управувањето со нив не се разликува од другите графикони.

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

Со нетрпение ги очекуваме случаите на употреба што оваа компонента ќе ги отвори за развивачите на графикони, како и најдобрите практики што можат да произлезат од графиконите на библиотеката.

Што е следно?

Helm 3.0.0-alpha.1 е основата врз која започнуваме да создаваме нова верзија на Helm. Во написот опишав неколку интересни карактеристики на Helm 3. Многу од нив се уште се во раните фази на развој, и тоа е нормално; Поентата на објавувањето на алфа е да се тестира идејата, да се соберат повратни информации од раните усвоени и да се потврдат нашите претпоставки.

Штом ќе излезе алфа верзијата (запомнете дека ова веќе се случи - прибл. превод.), ќе започнеме да прифаќаме закрпи за Helm 3 од заедницата. Треба да се изгради цврста основа за да се овозможи развивање и усвојување на нова функционалност, а корисниците да се чувствуваат вклучени во процесот со отворање билети и правење корекции.

Во оваа статија, се обидов да истакнам некои од главните подобрувања кои доаѓаат на Helm 3, но оваа листа во никој случај не е исцрпна. Целосниот план за Helm 3 вклучува нови функции како што се подобрени стратегии за ажурирање, подлабока интеграција со регистрите OCI и употреба на шеми JSON за валидација на вредностите на графиконот. Исто така, планираме да ја исчистиме базата на кодови и да ги ажурираме оние делови од неа што беа запоставени во последните три години.

Ако се чувствувате како нешто да сме пропуштиле, би сакале да ги слушнеме вашите размислувања!

Придружете се на дискусијата во нашата Запуштени канали:

#helm-users за прашања и едноставна комуникација со заедницата;
#helm-dev да разговараат за барањата за повлекување, кодот и грешките.

Можете исто така да разговарате на нашите неделни Јавни повици за програмери во четврток во 19:30 MSK. Состаноците се посветени на дискусија за задачите на кои работат клучните програмери и заедницата, како и за темите на дискусија за неделата. Секој може да се придружи и да учествува на состанокот. Линкот е достапен во каналот Slack #helm-dev.

PS од преведувач

Прочитајте и на нашиот блог:

Извор: www.habr.com

Вовед во Helm 3