Короткий вступ у Kustomize

Прим. перев.: Статтю написав Scott Lowe - інженер з великим стажем в ІТ, який є автором/співавтором семи друкованих книг (переважно за VMware vSphere). Зараз він працює в її дочірній організації VMware - Heptio (поглинена в 2016 році), спеціалізуючись на хмарних обчисленнях та Kubernetes. Сам же текст є ємним і простим для розуміння введенням в управління конфігураціями для Kubernetes за допомогою технології Налаштувати, що нещодавно увійшла до складу K8s.

Kustomize – це інструмент, що дозволяє користувачам «налаштовувати прості та вільні від шаблонів файли YAML під різні цілі, залишаючи оригінальний YAML незайманим та придатним для використання» (опис запозичений прямо з репозиторія kustomize на GitHub). Kustomize можна запускати безпосередньо або, починаючи з Kubernetes 1.14, використовувати kubectl -k для доступу до його функцій (хоча станом на Kubernetes 1.15 окремий бінарник більш новий, ніж можливості, вбудовані в kubectl). (Прим. перев.: А з недавнім релізом Кубернети 1.16 налаштувати підтримується ще і в утиліті kubeadm.) У цій публікації я хочу познайомити читачів з основами kustomize.

У своїй простій формі/застосуванні kustomize — це просто набір ресурсів (YAML-файлів, які визначають об'єкти Kubernetes: Deployments, Services тощо) плюс список інструкцій щодо змін, які необхідно внести до цих ресурсів. Подібно до того, як make використовує набір інструкцій, що міститься в Makefile, а Docker збирає контейнер на основі інструкцій з Dockerfile, kustomize використовує kustomization.yaml для зберігання розпоряджень про те, які зміни користувач хоче внести до набору ресурсів.

Ось приклад файлу kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Не намагатимуся розповісти про всі можливі поля у файлі kustomization.yaml (про це непогано написано тут), але проведу коротке пояснення конкретного прикладу:

• Поле resources Вказує, що (які ресурси) змінюватиме kustomize. У цьому випадку він шукатиме ресурси у файлах deployment.yaml и service.yaml у своєму каталозі (за потреби можна вказувати повні чи відносні шляхи).
• Поле namePrefix наказує kustomize'у додавати певний префікс (у даному випадку - dev-) до атрибуту name всіх ресурсів, визначених у полі resources. Таким чином, якщо у Deployment'і є name зі значенням nginx-deployment, kustomize зробить з нього dev-nginx-deployment.
• Поле namespace наказує kustomize'у додавати заданий простір імен до всіх ресурсів. У цьому випадку, Deployment та Service потраплять у простір імен development.
• Зрештою, поле commonLabels містить набір лейблів, який буде додано до всіх ресурсів. У нашому прикладі kustomize надасть ресурсам мітку з назвою environment та значенням development.

Якщо користувач виконає kustomize build . у директорії з файлом kustomization.yaml та необхідними ресурсами (тобто файлами deployment.yaml и service.yaml), то на виході він отримає текст із змінами, прописаними в kustomization.yaml.

Прим. перев.: Ілюстрація з документації проекту «простого» використання kustomize.

Висновок можна перенаправити, якщо необхідно зафіксувати зміни:

kustomize build . > custom-config.yaml

Вихідні дані детерміновані (при однакових даних на вході будуть виходити одні й самі результати на виході), тому можна не зберігати результат у файл. Натомість його можна відразу передати в іншу команду:

kustomize build . | kubectl apply -f -

Доступ до функцій kustomize також можна отримати через kubectl -k (Починаючи з версії 1.14 Kubernetes). Однак майте на увазі, що окремий пакет kustomize швидше оновлюється, ніж інтегрований в kubectl (принаймні так справи з релізом Kubernetes 1.15).

Читачі можуть запитати: "Навіщо потрібні всі ці складності, якщо можна відредагувати файли безпосередньо?" Чудове питання. У нашому прикладі справді можна модифікувати файли deployment.yaml и service.yaml прямо, але що, якщо вони є форком чийогось проекту? Безпосередня зміна файлів ускладнює (якщо взагалі не унеможливлює) rebase форка, коли вносяться зміни в джерело/вихідник. Використання kustomize дозволяє централізувати ці зміни у файлі kustomization.yaml, залишивши оригінальні файли недоторканими і, таким чином, полегшуючи при необхідності відновити вихідні файли.

Переваги kustomize стають очевидними у більш складних випадках використання. У наведеному вище прикладі kustomization.yaml та ресурси знаходяться в одній і тій же директорії. Однак kustomize підтримує сценарії використання, коли є базова конфігурація та безліч її варіантів, також відомих як накладки. Наприклад, користувач захотів взяти Deployment та Service для nginx, які я використав як приклад, і створити development-, staging- та production-версії (або варіанти) тих файлів. Для цього йому знадобляться згадані вище overlays і, власне, самі базові ресурси.

Щоб проілюструвати ідею overlays та базових ресурсів (base resources), припустимо, що директорії мають таку структуру:

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

У файлі base/kustomization.yaml користувачі за допомогою поля resources просто оголошують ресурси, які повинні включити кустоміз.

У кожному із файлів overlays/{dev,staging,prod}/kustomization.yaml користувачі посилаються на базову конфігурацію у полі resources, а потім вказують конкретні зміни для даного оточення. Наприклад, файл overlays/dev/kustomization.yaml може виглядати як приклад, наведений раніше:

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

При цьому файл overlays/prod/kustomization.yaml може бути зовсім іншим:

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

Коли користувач запустить kustomize build . у каталозі overlays/dev, kustomize згенерує варіант розвитку. Якщо ж запустити kustomize build . у каталозі overlays/prod - Вийде варіант production. І все це — без внесення будь-яких змін до початкових (база) файли, і все це – декларативним та детермінованим способом. Можна об'єднати базову конфігурацію та оверлейні директорії прямо в систему керування версіями, знаючи, що на основі цих файлів у будь-який момент можна відтворити потрібну конфігурацію.

Прим. перев.: Ілюстрація з документації проекту з використання overlays у kustomize.

Kustomize вміє набагато більше, ніж зазначено у цій статті. Втім, сподіваюся, вона стане хорошим запровадженням.

Додаткові ресурси

Є багато хороших статей та публікацій про kustomize. Ось кілька, які я вважав особливо корисними:

• Зміна base YAML config for different environments prod/test using Kustomize;
• Kustomize — The right way to at the templating in Kubernetes;
• Declarative Management of Kubernetes Objects Using Kustomize;
• Customizing Upstream Helm Charts with Kustomize.

Прим. перев.: Також можна порадити блок посилань, опублікованих як ресурси на сайті утиліти і наступну за ними колекцію відео з останніми доповідями про kustomize.

Якщо у вас є питання або пропозиції щодо покращення цього матеріалу, я завжди відкритий до зворотного зв'язку. Зв'язатися зі мною можна в Twitter або у Slack-каналі Kubernetes. Отримуйте задоволення, модифікуючи свої маніфести за допомогою kustomize!

PS від перекладача

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

• «Інструменти для розробників додатків, які запускаються в Kubernetes»;
• «Kubernetes 1.14: огляд основних нововведень»;
• «П'ять головних підсумків Helm Summit 2019 в Амстердамі»;
• «Практичне знайомство з пакетним менеджером для Kubernetes - Helm».

Джерело: habr.com