Представяме ви Helm 3

Забележка. превод: 16 май тази година отбелязва важен крайъгълен камък в развитието на пакетния мениджър за Kubernetes - Helm. На този ден беше представена първата алфа версия на бъдещата основна версия на проекта - 3.0. Пускането му ще донесе значителни и дългоочаквани промени в Helm, за които мнозина в общността на Kubernetes имат големи надежди. Ние самите сме един от тях, тъй като активно използваме Helm за внедряване на приложения: интегрирахме го в нашия инструмент за внедряване на CI/CD werf и от време на време даваме своя принос за развитието на upstream. Този превод съчетава 7 бележки от официалния блог на Helm, които са посветени на първото алфа издание на Helm 3 и говорят за историята на проекта и основните характеристики на Helm 3. Техният автор е Мат „bacongobbler“ Фишър, служител на Microsoft и един от ключовите поддържащи на Helm.

На 15 октомври 2015 г. се роди проектът, сега известен като Helm. Само година след основаването си общността на Helm се присъедини към Kubernetes, като същевременно работи активно върху Helm 2. През юни 2018 г. Helm се присъедини към CNCF като развиващ се (инкубиращ) проект. Бързо напред към настоящето и първата алфа версия на новия Helm 3 е на път. (това издание вече се е състояла в средата на май - ок. превод).

В тази статия ще говоря за това откъде започна всичко, как стигнахме до мястото, където сме днес, ще представя някои от уникалните функции, налични в първото алфа издание на Helm 3, и ще обясня как планираме да се развиваме по-нататък.

Резюме:

• историята на създаването на Хелм;
• нежно сбогуване с Тилър;
• хранилища на диаграми;
• управление на освобождаване;
• промени в зависимостите на диаграмата;
• библиотечни диаграми;
• Какво следва?

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

раждане

Helm 1 започна като проект с отворен код, създаден от Deis. Бяхме малък стартъп усвоени Microsoft през пролетта на 2017 г. Другият ни проект с отворен код, също наречен Deis, имаше инструмент deisctl, който беше използван (наред с други неща) за инсталиране и работа с платформата Deis в Клъстер на флота. По това време Fleet беше една от първите платформи за оркестриране на контейнери.

В средата на 2015 г. решихме да променим курса и преместихме Deis (по това време преименуван на Deis Workflow) от Fleet към Kubernetes. Един от първите, които бяха преработени, беше инструментът за инсталиране. deisctl. Използвахме го, за да инсталираме и управляваме Deis Workflow в клъстера Fleet.

Helm 1 е създаден по образа на известни мениджъри на пакети като Homebrew, apt и yum. Основната му цел беше да опрости задачи като опаковане и инсталиране на приложения в Kubernetes. Helm беше официално представен през 2015 г. на конференцията KubeCon в Сан Франциско.

Първият ни опит с Helm проработи, но не беше без някои сериозни ограничения. Той взе набор от манифести на Kubernetes, овкусени с генератори като въвеждащи YAML блокове (предна част)* и зареди резултатите в Kubernetes.

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

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

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

Страхотно е, че шаблонните машини съществуват днес, нали?

По много причини този ранен инсталатор на Kubernetes изискваше твърдо кодиран списък с манифестни файлове и изпълняваше само малка, фиксирана последователност от събития. Беше толкова труден за използване, че екипът на Deis Workflow R&D имаше трудности, когато се опита да прехвърли своя продукт на тази платформа - обаче семената на идеята вече бяха посяти. Първият ни опит беше страхотна възможност за учене: разбрахме, че сме наистина страстни в създаването на прагматични инструменти, които решават ежедневните проблеми на нашите потребители.

Въз основа на опита от минали грешки, ние започнахме да разработваме Helm 2.

Правене на шлем 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). Бяха въведени нови типове ресурси (Внедряването все още беше в бета версия по това време). Бяха измислени персонализирани дефиниции на ресурси (първоначално наричани ресурси на трети страни или TPR). И най-важното, появи се набор от най-добри практики.

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

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

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

Тъй като ролевият контрол на достъпа (RBAC) беше активиран по подразбиране в Kubernetes 1.6, работата с Tiller в производството стана по-трудна. Поради големия брой възможни политики за сигурност, нашата позиция е да предложим разрешителна конфигурация по подразбиране. Това позволи на начинаещите да експериментират с Helm и Kubernetes, без първо да се гмурнат в настройките за сигурност. За съжаление тази конфигурация на разрешения може да даде на потребителя твърде широк набор от разрешения, от които не се нуждае. Инженерите на DevOps и SRE трябваше да научат допълнителни оперативни стъпки при инсталиране на Tiller в клъстер с множество наематели.

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

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

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

Хранилища на диаграми

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

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

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

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

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

Благодарение на усилията Инициатива за отворен контейнер (или OCI), Helm диаграмите могат да бъдат поставени на всяко разпределение. Засега този процес е експериментален. Поддръжката за влизане и други функции, необходими за пълен Helm 3, са в процес на работа, но ние сме развълнувани да се учим от откритията на OCI и екипите за разпространение, направени през годините. И чрез тяхното наставничество и насоки, ние научаваме какво е да оперираш високодостъпна услуга в мащаб.

Налично е по-подробно описание на някои предстоящи промени в хранилищата на диаграмите на Helm по ссылке.

Управление на изданията

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

• release object - представлява екземпляр на приложение;
• release version secret - представлява желаното състояние на приложението в определен момент от време (например пускане на нова версия).

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

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

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

В Helm 2 ревизиите бяха изключително последователни. Обадете се helm install създадена v1, последващата актуализация (ъпгрейд) - v2 и т.н. Изданието и тайната на версията на изданието са свити в един обект, известен като ревизия. Ревизиите се съхраняват в същото пространство от имена като Tiller, което означава, че всяка версия е "глобална" по отношение на пространството от имена; в резултат на това може да се използва само едно копие на името.

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

След като 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/, така че поддиаграми (поддиаграми), намиращ се в каталога charts/, ще продължи да работи без промени.

Представяме ви библиотечни диаграми

Helm 3 поддържа клас диаграми, наречени библиотечни диаграми (диаграма на библиотеката). Тази диаграма се използва от други диаграми, но сама по себе си не създава артефакти за освобождаване. Шаблоните на библиотечните диаграми могат да декларират само елементи 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 схеми за валидиране на стойности на диаграма. Също така планираме да почистим кодовата база и да актуализираме части от нея, които са били пренебрегвани през последните три години.

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

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

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

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

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

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

• «Мениджър на пакети за Kubernetes - Helm: минало, настояще, бъдеще»;
• «Трезвен поглед към Helm 2: „Ето какво е...“»;
• «Практическо въведение в пакетния мениджър за Kubernetes - Helm»;
• «Съвети и трикове на Kubernetes: прехвърляне на ресурси, работещи в клъстер, към управление на Helm 2»;
• «Упражнявайте се с dapp. Част 2. Разполагане на изображения на Docker в Kubernetes с помощта на Helm".

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