[uk] Best practices - custom_resource_definitions.md

Signed-off-by: Andrii Holovin <[email protected]>

Author: Andygol

i18n/uk/docusaurus-plugin-content-docs/current/chart_best_practices/custom_resource_definitions.md

@@ -0,0 +1,38 @@
+---
+title: Custom Resource Definitions
+description: Як створювати та використовувати CRDs (Custom Resource Definitions).
+sidebar_position: 7
+---
+
+Цей розділ Посібника з найкращих практик присвячений створенню та використанню обʼєктів Custom Resource Definition.
+
+При роботі з Custom Resource Definitions (CRDs) важливо розрізняти два різні аспекти:
+
+- Існує декларація CRD. Це YAML файл, який має `kind: CustomResourceDefinition`.
+- Потім є ресурси, які _використовують_ CRD. Наприклад, якщо CRD визначає `foo.example.com/v1`, будь-який ресурс, який має `apiVersion: example.com/v1` і `kind: Foo`, є ресурсом, що використовує цей CRD.
+
+## Встановлення декларації CRD перед використанням ресурсу {#install-a-crd-declaration-before-using-the-resource}
+
+Helm оптимізований для швидкого завантаження якомога більшої кількості ресурсів у Kubernetes. За дизайном Kubernetes може обробити цілий набір маніфестів і активувати їх усі (це називається процедурою узгодження).
+
+Але є різниця з CRDs.
+
+Для CRD декларація повинна бути зареєстрована до того, як будь-які ресурси цього типу CRD можуть бути використані. Процес реєстрації іноді займає кілька секунд.
+
+### Метод 1: Нехай `helm` зробить це за вас {#method-1-let-helm-do-it-for-you}
+
+З приходом Helm 3 ми видалили старі `crd-install` хуки на користь простішої методології. Тепер існує спеціальна тека `crds`, яку ви можете створити у вашому чарті для зберігання CRDs. Ці CRDs не підлягають шаблонізації, але будуть стандартно встановлені під час виконання `helm install` для чарту. Якщо CRD вже існує, його буде пропущена з попередженням. Якщо ви бажаєте пропустити крок встановлення CRD, ви можете використовувати прапорець `--skip-crds`.
+
+#### Декілька застережень (і пояснень) {#some-caveats-and-explanations}
+
+Зараз не підтримується оновлення або видалення CRDs за допомогою Helm. Це було зроблено після тривалого обговорення у спільноті через небезпеку випадкової втрати даних. Крім того, наразі немає консенсусу в спільноті щодо того, як управляти CRDs та їх життєвим циклом. Як це буде розвиватися, Helm додасть підтримку для цих випадків.
+
+Прапорець `--dry-run` для `helm install` і `helm upgrade` наразі не підтримується для CRDs. Мета "Dry Run" полягає в перевірці того, що вивід чарту дійсно працюватиме, якщо буде надіслано на сервер. Але CRDs є модифікацією поведінки сервера. Helm не може встановити CRD під час тестового запуску, тому клієнт виявлення не дізнається про цей Custom Resource (CR), і перевірка не пройде. Ви можете перемістити CRDs до окремого чарту або використовувати `helm template` замість цього.
+
+Ще один важливий момент, який слід врахувати в обговоренні підтримки CRD, — це те, як обробляється рендеринг шаблонів. Одним з явних недоліків методу `crd-install`, що використовувався в Helm 2, була неспроможність правильно перевіряти чарти через зміну доступності API (CRD фактично додає ще один доступний API до вашого кластера Kubernetes). Якщо чарт встановлював CRD, `helm` більше не мав дійсного набору версій API, з якими можна було працювати. Це також є причиною видалення підтримки шаблонізації для CRDs. З новим методом `crds` для встановлення CRD ми тепер забезпечуємо, що `helm` має абсолютно достовірну інформацію про поточний стан кластера.
+
+### Метод 2: Окремі чарти {#method-2-separate-charts}
+
+Ще один спосіб зробити це — помістити визначення CRD в один чарт, а потім розмістити будь-які ресурси, які використовують цей CRD, в _іншому_ чарті.
+
+В цьому методі кожен чарт потрібно встановлювати окремо. Однак цей робочий процес може бути більш корисним для адміністраторів кластерів, які мають права адміністратора на кластер.