🥇Запознаване с 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 изискваше фиксиран списък с манифест файлове и изпълняваше само малка фиксирана последователност от действия. Ползването му беше толкова трудно, че екипът за изследвания и разработки на 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 в многопотребителски (multi-tenant) клъстер.

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

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

С напускането на 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 версия секрет — представлява желаното състояние на приложението в конкретен момент от времето (например, релиз на нова версия).

Извикването helm install Създава release обект и release версия секрет. Извикването helm upgrade изисква наличието на release обект (който може да променя) и създава нов release версия секрет, съдържащ нови стойности и подготвен манифест.

Release обект съдържа информация за релиза, където релизът — конкретна инсталация на именуван чарт и стойности. Този обект описва метаданни на високо ниво за релиза. Release обектът се запазва през целия жизнен цикъл на приложението и е собственик на всички release версия секрети, както и на всички обекти, които се създават директно от Helm чарта.

Release версия секрет свързва релиза с поредица от ревизии (инсталация, актуализации, откат, изтриване).

В Helm 2 ревизиите бяха изцяло последователни. Извикването helm install създава v1, следващото обновление (upgrade) — v2, и така нататък. Release и release версия секрет бяха свити в един обект, известен като ревизия. Ревизията се съхраняваше в същото пространство от имена, което и Tiller, което означаваше, че всеки релиз беше „глобален“ по отношение на пространството от имена; в резултат на това можеше да се използва само един екземпляр на име.

В Helm 3 всеки релиз е свързан с един или няколко release версия секрети. Release обектът винаги описва текущия релиз, разположен в Kubernetes. Всеки release версия секрет описва само една версия на този релиз. Актуализация (upgrade), например, ще създаде нов release версия секрет и след това ще промени release обекта, за да сочи към тази нова версия. В случай на откат (rollback) могат да се използват предишни release версия секрети, за да се върне релизът към предишното състояние.

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

Библиотечните чартове се декларират в областта 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