Знайомство з 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 обріс кількома серйозними нововведеннями. З'явилося управління доступом на основі ролей (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'ом у 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. Інший контент просто ігнорується. Це дозволяє користувачам повторно використовувати та обмінюватися фрагментами коду, які можна задіяти у багатьох чартах, тим самим уникнувши дублювання та дотримуючись принципу СУХИЙ.

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 від перекладача

Читайте також у нашому блозі:

• «Пакетний менеджер для Kubernetes - Helm: минуле, сучасне, майбутнє»;
• «Тверезий погляд на Helm 2: „Ось такий, який є…“»;
• «Практичне знайомство з пакетним менеджером для Kubernetes - Helm»;
• «Kubernetes tips & tricks: переклад ресурсів, що працюють у кластері, під управління Helm 2»;
• «Практика з dapp. Частина 2. Деплой Docker-образів у Kubernetes за допомогою Helm».

Джерело: habr.com