Add Ukrainian translation for Helm documentation

config.toml

@@ -400,6 +400,43 @@ weight = 5
 [languages.ru.params]
 language_alternatives = ["en"]
 
+# Ukrainian
+[languages.uk]
+title = "Helm"
+description = "Helm — Менеджер Пакунків Kubernetes."
+contentDir = "content/uk"
+languageName = "Українська"
+weight = 9
+
+[[languages.uk.menus.main]]
+name = "Головна"
+url = "/"
+weight = 1
+
+[[languages.uk.menus.main]]
+name = "Документація"
+url = "/docs"
+weight = 2
+
+[[languages.uk.menus.main]]
+name = "Чарти"
+url = "https://artifacthub.io/"
+weight = 3
+external = "yes"
+
+[[languages.uk.menus.main]]
+name = "Блог"
+url = "https://helm.sh/blog"
+weight = 4
+
+[[languages.uk.menus.main]]
+name = "Спільнота"
+url = "https://github.com/helm/community"
+weight = 5
+
+[languages.uk.params]
+language_alternatives = ["en"]
+
 # Chinese
 [languages.zh]
 title = "Helm"

content/uk/docs/_index.md

@@ -0,0 +1,17 @@
+---
+title: "Документація"
+description: "Все, що вам потрібно знати про те, як організована документація."
+---
+
+# Ласкаво просимо {#welcome}
+
+Ласкаво просимо до документації [Helm](https://helm.sh/). Helm —  це менеджер пакунків для Kubernetes, і ви можете прочитати детальну довідкову інформацію у [звіті CNCF Helm Project Journey](https://www.cncf.io/cncf-helm-project-journey/).
+
+# Як організована документація {#how-the-documentation-is-organized}
+
+Helm має багато документації. Загальний огляд того, як все організовано допоможе вам зрозуміти, де шукати певні речі:
+
+- [Підручники](chart_template_guide/getting_started/) проведуть вас через низку кроків для створення вашого першого чарту Helm. Почніть тут, якщо ви новачок у Helm.
+- [Тематичні посібники](topics) обговорюють ключові теми та концепції на досить високому рівні та надають корисну довідкову інформацію та пояснення.
+- [Настанови для спільноти](community) обговорюють теми, повʼязані зі спільнотою Helm. Почніть тут, якщо ви хочете дізнатися більше про процес розробки Helm і про те, як ви можете до нього долучитися.
+- [Посібники](howto) — це рецепти. Вони проведуть вас через кроки, повʼязані з розвʼязанням ключових проблем та варіантів використання. Вони більш докладні, ніж підручників і передбачають певні знання про те, як працює Helm.

content/uk/docs/chart_best_practices/_index.md

@@ -0,0 +1,11 @@
+---
+title: "Найкращі практики"
+sidebar: true
+weight: 4
+---
+
+# Посібник з найкращих практик створення чартів
+
+Цей посібник охоплює найкращі практики, рекомендовані командою Helm, для створення чартів. Основна увага приділяється тому, як повинні бути структуровані чарти.
+
+Ми зосереджуємось головним чином на найкращих практиках для чартів, які можуть бути опубліковані публічно. Ми розуміємо, що багато чартів використовуються виключно для внутрішніх потреб, і автори таких чартів можуть вважати, що їхні внутрішні інтереси переважають наші рекомендації тут.

content/uk/docs/chart_best_practices/conventions.md

@@ -0,0 +1,42 @@
+---
+title: "Загальні домовленості"
+description: "Загальні домовленості для чартів."
+weight: 1
+---
+
+Ця частина Посібника з найкращих практик пояснює загальні домовленості.
+
+## Назви чартів {#chart-names}
+
+Назви чартів повинні складатися з літер нижнього регістру та цифр. Слова _можуть_ бути розділені дефісами (-):
+
+Приклади:
+
+```none
+drupal
+nginx-lego
+aws-cluster-autoscaler
+```
+
+У назвах чартів не можна використовувати великі літери та підкреслення. Також не слід використовувати крапки.
+
+## Номери версій {#version-numbers}
+
+По можливості, Helm використовує [SemVer 2](https://semver.org) для позначення номерів версій. (Зверніть увагу, що теґи Docker-образів не завжди відповідають SemVer і тому вважаються невдалим винятком з правила.)
+
+Коли версії SemVer зберігаються в мітках Kubernetes, ми умовно змінюємо символ `+` на `_`, оскільки мітки не допускають використання знака `+` як значення.
+
+## Форматування YAML {#formatting-yaml}
+
+Файли YAML повинні використовувати відступи у _два пробіли_ (і ніколи табуляцією).
+
+## Використання слів Helm і Chart {#usage-of-the-words-helm-and-chart}
+
+Існує кілька конвенцій щодо використання слів _Helm_ і _helm_.
+
+- _Helm_ відноситься до проєкту в цілому
+- `helm` відноситься до клієнтської команди
+- Термін `chart` не потрібно писати з великої літери, оскільки це не власна назва
+- Однак `Chart.yaml` необхідно писати з великої літери, оскільки назва файлу чутлива до регістру
+
+У разі сумніву використовуйте _Helm_ (з великої літери "H").

content/uk/docs/chart_best_practices/custom_resource_definitions.md

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

content/uk/docs/chart_best_practices/dependencies.md

@@ -0,0 +1,62 @@
+---
+title: "Залежності"
+description: "Охоплює найкращі практики для залежностей Charts."
+weight: 4
+---
+
+Цей розділ посібника охоплює найкращі практики для `залежностей`, оголошених у `Chart.yaml`.
+
+## Версії {#versions}
+
+По можливості використовуйте діапазони версій замість привʼязки до точної версії. Рекомендоване стандартне значення — це використання відповідності на рівні патчу:
+
+```yaml
+version: ~1.2.3
+```
+
+Це буде відповідати версії `1.2.3` та будь-яким патчам для цього випуску. Іншими словами, `~1.2.3` є еквівалентом `>= 1.2.3, < 1.3.0`.
+
+Для повної синтаксичної відповідності версій див. [документацію semver](https://github.com/Masterminds/semver#checking-version-constraints).
+
+### Попередні версії {#prereleases-versions}
+
+Вищезгадані обмеження версій не будуть відповідати попереднім версіям. Наприклад, `version: ~1.2.3` буде відповідати `version: ~1.2.4`, але не `version: ~1.2.3-1`. Наступне забезпечує відповідність як попередніх версій, так і на рівні патчу:
+
+```yaml
+version: ~1.2.3-0
+```
+
+### URL-адреси репозиторіїв {#repository-urls}
+
+По можливості використовуйте URL-адреси репозиторіїв `https://`, далі `http://`.
+
+Якщо репозиторій був доданий до файлу індексу репозиторіїв, імʼя репозиторію може бути використане як псевдонім URL. Використовуйте `alias:` або `@`, за яким слідують імена репозиторіїв.
+
+URL-адреси файлів (`file://...`) вважаються "особливим випадком" для чартів, які збираються фіксованим процесом розгортання.
+
+При використанні [втулків завантажувача]({{< ref "../topics/plugins#downloader-plugins" >}}) схема URL буде специфічною для втулка. Зверніть увагу, що користувачеві чарту буде потрібно мати втулок, що підтримує схему, встановлений для оновлення або побудови залежності.
+
+Helm не може виконувати операції управління залежностями для залежності, коли поле `repository` залишено порожнім. У цьому випадку Helm припускатиме, що залежність знаходиться в підтеці теки `charts` з іменем, яке відповідає властивості `name` для залежності.
+
+## Умови та теґи {#conditions-and-tags}
+
+Умови або теґи слід додавати до будь-яких залежностей, які _є необовʼязковими_.
+
+Бажана форма умови є такою:
+
+```yaml
+condition: somechart.enabled
+```
+
+Де `somechart` є іменем чарту залежності.
+
+Коли кілька субчартів (залежностей) разом забезпечують необовʼязкову або замінну функцію, ці чарт можуть мати спільні теґи.
+
+Наприклад, якщо як `nginx`, так і `memcached` разом забезпечують оптимізації продуктивності для основного застосунку в чарті та вони потрібні, щоб обидва були присутні, коли ця функція увімкнена, то вони повинні мати розділ теґів як цей:
+
+```yaml
+tags:
+  - webaccelerator
+```
+
+Це дозволяє користувачеві вмикати або вимикати цю функцію за допомогою одного теґу.