🥇Запознаване с 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;
репозитории на чартовете;
управление на релизите;
промени в зависимостите на чартовете;
библиотечни чартове;
какво следва?

История на създаването на Helm

Раждане

Helm 1 започна като проект с отворен код, създаден от компанията Deis. Ние бяхме малък стартъп, погълнат от Microsoft през пролетта на 2017 година. Нашият друг проект с отворен код, също наречен 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 беше избран синтаксиса YAML за описание на ресурси в Kubernetes, а при писането на конфигурации се поддържаха шаблони 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 обогати с редица сериозни нововъведения. Появи се управление на достъпа, базирано на роли (RBAC), което в крайна сметка замени контрола на достъпа, базиран на атрибути (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 в продукция стана по-сложна. Поради огромния брой възможни политики за сигурност, нашата позиция беше да предлагаме разрешителна конфигурация по подразбиране. Това позволяваше на новаците да експериментират с Helm и Kubernetes без необходимостта първо да се запознават с настройките за сигурност. За съжаление, тази разрешителна конфигурация можеше да предостави на потребителите твърде широк диапазон от разрешения, които не им бяха необходими. Инженерите DevOps и SRE трябваше да изучават допълнителни оперативни стъпки при инсталирането на Tiller в многопотребителски кластер.

Като научихме как представители на общността използват Helm в конкретни ситуации, осъзнахме, че системата за управление на версиите Tiller не трябва да разчита на вътрешнокластерен компонент, за да поддържа състояния или да функционира като централен хъб с информация за версиите. Вместо това можехме просто да получаваме информация от API сървера на Kubernetes, да генерираме чарт от страна на клиента и да запазваме записа за инсталацията в Kubernetes.

Основната задача на Tiller може да бъде постигната и без него, затова едно от първите ни решения по отношение на Helm 3 беше пълното отказване от Tiller.

С напускането на Tiller, моделът на сигурност на Helm значително се опрости. Helm 3 вече поддържа всички съвременни методи за сигурност, идентификация и авторизация на текущия Kubernetes. Правата на Helm се определят с помощта на файла kubeconfig. Администраторите на кластера могат да ограничават правата на потребителите с всякаква степен на детайлност. Версиите все още се запазват вътре в клъстера, а останалата функционалност на Helm остава.

Хранилища на чартове

На високо ниво, хранилището на чартове е място, където могат да се съхраняват и споделят чартове. Клиентът на Helm опакова и изпраща чартове в хранилището. По-просто казано, хранилището на чартове е примитивен HTTP сървър с файл index.yaml и някои опаковани чарта.

Въпреки че има някои предимства, когато API-то на хранилището на чартове отговаря на основните изисквания за хранилище, то има и някои недостатъци:

Репозиториите за чарта не са съвместими с повечето реализации на сигурност, необходими в продукционна среда. Наличието на стандартен API за удостоверяване и авторизация е изключително важно в продукционни сценарии.
Инструментите на Helm за проследяване на произхода на чарта, използвани за подписване, проверка на целостта и произхода на чарта, са опционална част от процеса на публикуване на чарта.
В многопотребителски сценарии един и същ чарт може да бъде качен от друг потребител, удвоявайки необходимото пространство за съхранение на същото съдържание. За решаването на този проблем бяха разработени по-умни репозитории, но те не са част от формалната спецификация.
Използването на един единствен индексиращ файл за търсене, съхранение на метаданни и получаване на чартове усложни разработването на сигурни многопотребителски реализации.

Проект Docker Distribution (известен също като Docker Registry v2) е наследник на Docker Registry и всъщност представлява набор от инструменти за упаковка, изпращане, съхранение и доставка на Docker образи. Много големи облачни услуги предлагат продукти, изградени на базата на Distribution. Поради увеличеното внимание, проектът Distribution е спечелил от многогодишни усъвършенствания, най-добри практики в областта на сигурността и тестове в „боеви“ условия, което го е превърнало в един от най-успешните неизвестни герои на света на Open Source.

Но знаете ли, че проектът Distribution е разработен за разпространение на всякаква форма на съдържание, а не само на образи на контейнери?

Благодарение на усилията Open Container Initiative (или OCI), Helm чартовете могат да бъдат разположени на всеки екземпляр на Distribution. В момента този процес е експериментален. Работата по поддръжката на влизания и други функции, необходими за пълноценен Helm 3, все още не е завършена, но ние сме много развълнувани от възможността да учим от откритията, направени от екипите на OCI и Distribution през годините. А благодарение на техните менторства и ръководство, ние научаваме какво означава експлоатация на высокодостъпен сервис в голям мащаб.

По-подробно описание на някои предстоящи промени в репозиторията на Helm чартовете е достъпно от връзката.

Управление на релизи

В Helm 3 състоянието на приложението се следи в рамките на клъстера чрез двойка обекти:

обект на релация — представлява екземпляр на приложението;
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 бяха обединени в един обект, известен като ревизия. Ревизии се съхраняваха в същото пространство на имената като 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). Този чарт се използва от други чартове, но сам по себе си не създава никакви артефакти на релиз. Шаблоните на библиотечните чартове могат да декларират само елементи define. Друго съдържание просто се игнорира. Това позволява на потребителите да повторно използват и обменят фрагменти от код, които могат да бъдат използвани в много чартове, като по този начин избегнат дублиране и спазват принципа DRY.

Library чартовете се декларират в раздела 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 схеми за проверка на стойностите на чартовете. Планираме също да пречистим кодовата база и да актуализираме тези части, които не бяха забелязвани през последните три години.

Ако смятате, че нещо сме пропуснали, ще се радваме да чуем вашите мисли!

Присъединете се към дискусията в нашите Slack канали:

#helm-users за въпроси и обикновено общуване с общността;
#helm-dev за обсъждане на pull requests, код и грешки.

Можете също да се свържете в нашите ежеседмични Public Developer Calls в четвъртък в 19:30 MSK. Срещите са посветени на обсъждането на задачите, по които работят ключови разработчици и общността, както и на темите за обсъждане през седмицата. Всеки може да се присъедини и да участва в срещата. Линкът е наличен в Slack канала #helm-dev.

P.S. от преводача

Прочетете също в нашия блог:

Източник: habr.com