Модуль 2.2: Менеджер пакетів Helm

Складність: [СЕРЕДНЯ] — основний інструмент розгортання для CKAD

Час на проходження: 45-55 хвилин

Передумови: Модуль 2.1 (Деплойменти), розуміння YAML-шаблонів

---

Результати навчання

Після завершення цього модуля ви зможете:

• Розгортати Helm-чарти з налаштуванням репозиторію, націлюванням на простір імен, власними значеннями та перевіркою для Kubernetes 1.35+.
• Проєктувати стратегії перевизначення значень, які розділяють типові значення чарта, повторно використовувані файли середовищ та перевизначення з командного рядка.
• Діагностувати невдалі релізи Helm, поєднуючи helm status, helm history, згенеровані маніфести, події Kubernetes та операції відкату.
• Оцінювати, коли встановлювати, оновлювати, відкочувати, видаляти чи генерувати чарт локально у сценаріях розгортання у стилі CKAD.
• Порівнювати структуру чарта, ревізії релізу та згенеровані об’єкти Kubernetes, щоб простежити, як значення перетворюється на стан робочого навантаження, що вже працює.

Чому цей модуль важливий

Гіпотетичний сценарій: вам дають простір імен на ім’я web, репозиторій чартів і вимогу розгорнути nginx із двома репліками та внутрішнім сервісом. Якщо ви вручну напишете Deployment, Service, мітки, проби та налаштування ресурсів з пам’яті, ви можете завершити з валідним YAML, але провалити завдання, тому що питання просило саме реліз Helm. Якщо ж ви швидко встановите чарт, але забудете про простір імен, робоче навантаження може запрацювати у default, реліз буде невидимим із запитаного простору імен, а кожна наступна команда виглядатиме оманливо.

Helm вирішує практичну проблему пакування, яка з’являється щойно маніфести Kubernetes перестають бути крихітними. Реальний застосунок рідко складається з одного об’єкта; зазвичай це Deployment, Service, ConfigMap, Secret, ServiceAccount, прив’язка ролей, об’єкт ingress і кілька міток, які мають узгоджуватися між собою. Чарт пакує ці пов’язані ресурси так, щоб їх можна було встановлювати, оновлювати, інспектувати та відкочувати як єдине ціле, а не копіювати вручну між каталогами.

Для того, хто вивчає CKAD, Helm — це не про те, щоб з першого дня стати автором чартів. Ваше безпосереднє завдання — розпізнавати життєвий цикл релізу, обирати правильну команду під тиском часу та доводити, що згенеровані об’єкти Kubernetes відповідають завданню. Це означає, що вам потрібно знати, як репозиторії живлять чарти, як значення змінюють згенеровані маніфести, як простори імен обмежують область релізів і як історія дозволяє відновитися, коли оновлення створює неправильний стан.

Корисна ментальна модель — це магазин застосунків, але з налаштуваннями під контролем версій замість графічного вікна параметрів. Чарти — це запаковані застосунки, репозиторії — каталоги, релізи — встановлені екземпляри, а значення — це налаштування, що адаптують той самий чарт до різних середовищ. Аналогія припиняється там, де починається Kubernetes: Helm не зробить зламаний образ справним, не обійде RBAC і не гарантує, що Service буде доступним. Він генерує й подає ресурси Kubernetes, а кластер далі застосовує кожне звичне правило планування, валідації та готовності.

Helm також дає вам словник для відтворюваності. Без менеджера пакетів фраза «розгорнути nginx» могла б означати застосування випадкового локального YAML-файлу, копіювання маніфесту з туторіалу чи редагування попереднього Deployment, доки він не стане достатньо схожим. З Helm ця фраза стає точною: встановити цей чарт, з цим іменем релізу, у цьому просторі імен, використовуючи цей файл значень і ці перевизначення. Саме така точність дозволяє іншому оператору відтворити вашу роботу.

Компроміс полягає в тому, що Helm додає рівень абстракції, який ви маєте навчитися розкривати. Коли Под падає, не варто автоматично винуватити Helm, але й не варто ігнорувати роль Helm у створенні маніфесту. Надійний оператор може рухатися в обох напрямках: від чарта та значень униз до згенерованого YAML і від живого об’єкта Kubernetes назад угору до значення чи шаблону, що його створив.

Для іспиту CKAD цей рух у двох напрямках економить час, бо завдання зазвичай невеликі та чітко окреслені. Можливо, вам не доведеться пояснювати кожну функцію шаблону, але вам справді потрібно знайти ключ значення, що керує кількістю реплік, встановити реліз у запитаний простір імен і довести, що згенеровані об’єкти відповідають вимозі. Мета — операційна вправність, а не запам’ятовування кожного можливого прапорця Helm.

Модель пакування Helm

Helm починається з розділення між наміром та екземпляром. Чарт описує форму застосунку, значення описують, як має відрізнятися саме це встановлення, а реліз фіксує те, що Helm створив для конкретного імені в конкретному просторі імен. Саме це розділення є причиною того, що той самий чарт nginx може породити і крихітне навчальне навантаження з однією реплікою, і внутрішній сервіс із трьома репліками, і виробничий чарт, прив’язаний до конкретних ресурсів, без копіювання шаблонів.

Словник компактний, але кожне слово має значення під час усунення несправностей. Чарт — це не застосунок, що працює; це пакет. Реліз — це не чарт; це одне встановлення цього чарта. Ревізія — це не тег образу контейнера; це збережений Helm запис однієї події встановлення, оновлення чи відкату для цього релізу. Коли ви тримаєте ці межі чіткими, помилки Helm стають значно зрозумілішими.

Термін	Опис
Чарт (Chart)	Пакет ресурсів Kubernetes (як застосунок)
Реліз (Release)	Встановлений екземпляр чарта
Репозиторій (Repository)	Колекція чартів (як репозиторії apt)
Значення (Values)	Конфігурація для налаштування чарта
Ревізія (Revision)	Версія релізу після оновлення/відкату

Під час рендерингу Helm поєднує шаблони зі значеннями, щоб отримати звичайний YAML Kubernetes. API-сервер ніколи не бачить чарівного об’єкта Helm для вашого Deployment; він бачить маніфест Deployment, який Helm згенерував і подав. Далі Helm зберігає метадані релізу, щоб згодом мати змогу порівнювати, оновлювати, відкочувати та показувати вам, що сталося.

Chart (template) + Values (config) = Release (running app)

┌─────────────────────────────────────────────────────────┐
│                    Helm Workflow                        │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  Repository          Chart            Release           │
│  ┌─────────┐       ┌─────────┐      ┌─────────┐        │
│  │ bitnami │──────▶│  nginx  │─────▶│ my-web  │        │
│  │  repo   │ pull  │  chart  │install│ release │        │
│  └─────────┘       └─────────┘      └─────────┘        │
│                         │                 │            │
│                         ▼                 ▼            │
│                    ┌─────────┐      ┌─────────┐        │
│                    │ values  │      │  Pods   │        │
│                    │  .yaml  │      │Services │        │
│                    └─────────┘      │ConfigMaps│       │
│                                     └─────────┘        │
└─────────────────────────────────────────────────────────┘

Діаграма приховує одну операційну деталь, що стає важливою під час налагодження: об’єкти Kubernetes усе одно є повноцінними ресурсами кластера. Ви можете інспектувати Поди за допомогою kubectl, перевіряти мітки селекторами та читати події, коли трапляються збої планування чи завантаження образу. Helm дає вам контекст релізу, тоді як Kubernetes дає правду про робоче навантаження.

Зробіть паузу й передбачте: якщо чарт генерує Deployment, чий шаблон Под посилається на відсутній тег образу, який інструмент скаже вам, що Helm встановився успішно, а який покаже, що Поди падають потім? Корисна відповідь — обидва: Helm може повідомити про розгорнутий реліз, бо ресурси були прийняті, тоді як kubectl get pods і kubectl describe pod виявляють збій під час виконання після того, як контролери почнуть узгоджувати навантаження.

Це перша старша звичка, яку слід виробити: завжди пов’язуйте стан Helm зі станом Kubernetes. Реліз може існувати, доки його Поди в стані pending, Под може впасти, доки історія Helm виглядає чистою, а відкат може створити нову ревізію, доки стара зламана ревізія залишається видимою в історії. Ставтеся до Helm як до менеджера пакетів, а до Kubernetes як до середовища виконання, і свідомо переходьте між ними.

Метадані релізу Helm корисні, бо дають вам стабільний аудиторський слід для операцій, які інакше виглядають як окремі оновлення Kubernetes. Якщо оновлення одночасно змінює Deployment і Service, Kubernetes може показати кожен об’єкт, але Helm може показати, що обидві зміни належали до однієї ревізії релізу. Саме це групування пояснює, чому helm history часто є найшвидшим способом відновити те, що змінилося під час поспішної лабораторної роботи чи автоматизованого розгортання.

Ім’я релізу є частиною цього аудиторського сліду, тому дисципліна іменування важлива. Два релізи можуть встановити той самий чарт із різними значеннями, і ці релізи можуть створити об’єкти, чиї імена містять ім’я релізу. Якщо ви випадково встановите web, а потім пізніше встановите web-prod, ви не перейменували перший реліз; ви створили другий реліз з окремою історією та потенційно перекривними ресурсами Kubernetes.

Мітки — це міст між двома світами. Багато чартів застосовують спільні мітки, такі як app.kubernetes.io/instance та app.kubernetes.io/name, що дає змогу вибирати Поди, створені релізом, не вгадуючи згенеровані імена ресурсів. Коли завдання просить вас перевірити реліз, запити kubectl на основі міток зазвичай дають чистіші докази, ніж сканування кожного Пода у просторі імен.

Версії чартів та версії застосунків — ще одна межа, яку варто тримати чіткою. Версія чарта описує пакет і шаблони, тоді як версія застосунку часто описує програмне забезпечення, яке постачає чарт. Оновлення чарта може змінити шаблони, типові значення, мітки чи поведінку шаблонів-помічників, навіть коли образ контейнера залишається тим самим. Оновлення лише тегу образу може змінити поведінку під час виконання, тоді як пакет чарта залишається стабільним.

Тому Helm найкраще розглядати як координатор змін, а не як оракул справності. Він може координувати бажану зміну, зберігати ревізії та генерувати маніфести, але контролери все одно вирішують, чи стануть Поди готовими, а Service отримає кінцеві точки. Під час усунення несправностей спершу знайдіть реліз і передбачувану конфігурацію, а потім читайте статус Kubernetes, що доводить, чи прийняв і досягнув кластер цього передбаченого стану.

Встановлення чартів без втрати контексту

Керування репозиторіями — це передня брама до більшості завдань CKAD із Helm. Ви додаєте репозиторій один раз, оновлюєте локальний індекс, шукаєте чарт, а потім встановлюєте за іменем чарта, кваліфікованим репозиторієм. У середовищі іспиту репозиторій може вже існувати, але перевірка helm repo list та оновлення через helm repo update коштують небагато й запобігають плутанині через застарілий індекс чартів.

# Add a repository
helm repo add bitnami https://charts.bitnami.com/bitnami

# Add stable repo
helm repo add stable https://charts.helm.sh/stable

# Update repository cache
helm repo update

# List repositories
helm repo list

# Search for charts
helm search repo nginx
helm search repo bitnami/nginx

# Search with versions
helm search repo nginx --versions

Архівований репозиторій stable з’являється в багатьох старіших прикладах, тож ви маєте його розпізнавати, але надавайте перевагу підтримуваним вендорським репозиторіям, коли завдання дає вам вибір. URL репозиторію — це не місце, де живе реліз; це лише місце, звідки Helm завантажує метадані чарта та пакети. Реліз живе у просторі імен Kubernetes, і це рішення про простір імен супроводжує вас через команди install, list, status, get, history, rollback та uninstall.

Поведінку кешу репозиторію легко не помітити, бо команди Helm відчуваються миттєвими. helm repo add фіксує, де живе репозиторій, тоді як helm repo update оновлює локальний індекс, до якого звертаються команди пошуку та встановлення. Якщо ви додаєте репозиторій і пропускаєте оновлення, ви все ще можете дивитися на той індекс, що вже існував на диску. У чистій лабораторії це може бути нічим; на робочій станції, що працює давно, це може бути застарілою інформацією.

Результати пошуку також слід читати уважно. Коротке ім’я на кшталт nginx може збігтися з кількома чартами в кількох репозиторіях, і перший результат не є автоматично тим чартом, що потрібен для завдання. Використовуйте ім’я, кваліфіковане репозиторієм, наприклад bitnami/nginx, під час встановлення, щоб команда була однозначною. Якщо завдання надає версію чарта, явно зафіксуйте її замість того, щоб дозволяти найновішій версії репозиторію вирішувати, який пакет узяти.

Встановлення чарта — це зобов’язання щодо імені релізу, посилання на чарт, простору імен та набору значень. Ім’я релізу — це держак, який ви використовуватимете пізніше, тож обирайте точне ім’я із завдання, а не імпровізуйте. Простір імен так само важливий, бо Helm обмежує область релізів простором імен; helm list -n web та helm list -n production можуть показувати різні світи, навіть коли в кластері той самий чарт встановлено двічі.

# Install with default values
helm install my-release bitnami/nginx

# Install in specific namespace
helm install my-release bitnami/nginx -n production

# Install and create namespace
helm install my-release bitnami/nginx -n production --create-namespace

# Install with custom values file
helm install my-release bitnami/nginx -f values.yaml

# Install with inline values
helm install my-release bitnami/nginx --set replicaCount=3

# Install with multiple value overrides
helm install my-release bitnami/nginx \
  --set replicaCount=3 \
  --set service.type=NodePort

# Dry-run (see what would be created)
helm install my-release bitnami/nginx --dry-run=client

# Generate name automatically
helm install bitnami/nginx --generate-name

Використовуйте --generate-name лише тоді, коли завдання не переймається стабільним іменем релізу. Більшість оцінювальних і виробничих робочих процесів таки переймаються, бо наступні команди мають передбачувано звертатися до релізу. Згенероване ім’я може бути прийнятним для одноразового димового тесту, але воно погано підходить до вимоги, яка пізніше каже «оновіть реліз на ім’я web» чи «відкотіть frontend до ревізії 1».

Команди встановлення слід писати так, ніби комусь доведеться пояснювати їх пізніше. Ім’я релізу, посилання на чарт, простір імен, файл значень та вбудовані перевизначення — це докази вашого наміру. Команда, скопійована з туторіалу з іншим іменем релізу, може створити валідні ресурси, але все одно провалити вимогу. Команда, яка називає реліз і простір імен точно так, як запитано, дає вам чистий шлях до подальшої перевірки.

Коли чарт створює кілька об’єктів, не припускайте, що всі імена ресурсів точно збігатимуться з іменем релізу. Багато чартів генерують імена через шаблони-помічники, що поєднують ім’я релізу, ім’я чарта, перевизначення повного імені та правила скорочення. Мітки часто стабільніші для перевірки, ніж згенеровані імена. Саме тому лабораторна робота перевіряє Поди за app.kubernetes.io/instance=web, а не припускає конкретний префікс Пода.

Перелік релізів — це ваш орієнтувальний крок після встановлення. Використовуйте прапорець простору імен, коли завдання називає простір імен, і використовуйте всі простори імен, коли ви не впевнені, де реліз було створено. На практиці багато з вигляду невдалих установок Helm — це просто розбіжності просторів імен: чарт встановився правильно, але оператор переглядає реліз із неправильної області.

# List releases in current namespace
helm list

# List in all namespaces
helm list -A

# List in specific namespace
helm list -n production

# List with status
helm list --all

# Filter by status
helm list --failed
helm list --pending

Наступний рівень — це інспекція до та після встановлення. helm show читає метадані чарта та типові значення з джерела чарта, тоді як helm get читає інформацію зі встановленого релізу. Ця відмінність запобігає поширеній помилці налагодження: розглядати типові значення й припускати, що це живі значення. Типові значення — це рецепт; дані релізу — це страва, яку насправді приготували.

# Show chart info
helm show chart bitnami/nginx

# Show default values
helm show values bitnami/nginx

# Show all info
helm show all bitnami/nginx

# Get release values
helm get values my-release

# Get all release info
helm get all my-release

# Get release manifest (rendered YAML)
helm get manifest my-release

# Get release history
helm history my-release

Перш ніж це запускати, який вивід ви очікуєте від helm show values bitnami/nginx порівняно з helm get values my-release після того, як ви встановите з --set replicaCount=3? Перша команда має показати типову конфігурацію чарта, тоді як друга має показати значення, збережені для релізу. Якщо вам потрібне кожне обчислене значення, включно з типовими, використовуйте helm get values <release> -a (або --all), а не припускайте, що надані користувачем значення — це вся картина.

Націлювання на простір імен — це також причина, чому команди перевірки Helm та kubectl мають іти в парі. Якщо ви встановлюєте my-release у web, перевіряйте реліз через helm list -n web, а робоче навантаження — через kubectl get pods -n web. Узгоджене збереження прапорця простору імен робить вашу стенограму легкою для аудиту й не дає вам полювати на об’єкти не в тому місці.

Якщо реліз здається відсутнім, утримайтеся від спокуси негайно перевстановити. Спершу запустіть helm list -A та перевірте простори імен, бо друге встановлення того самого чарта з іншим простором імен може ускладнити прибирання. Якщо реліз знайдено в іншому місці, вирішіть, чи правильна дія — видалити помилковий реліз, чи перевстановити в потрібному просторі імен. Правильна відповідь залежить від завдання, але виявлення має передувати зміні.

Той самий принцип застосовується до інспекції чарта. helm show values корисний перед встановленням, бо повідомляє вам, які регулятори чарт надає, але він не доводить, що використовує встановлений реліз. Після встановлення переходьте до helm get values та helm get manifest, щоб інспектувати реліз, що існує в кластері. Змішування цих двох перспектив — поширене джерело хибної впевненості.

Значення як контракт між чартом і кластером

Значення — це контракт між узагальненим чартом і конкретним станом кластера, який ви хочете отримати. Автор чарта обирає, які регулятори існують, а ви обираєте, як налаштувати ці регулятори для цього середовища. Цей контракт потужний, бо зменшує дублювання, але саме тут починається багато помилок Helm: ключ із друкарською помилкою може мовчки ігноруватися шаблоном, рядок може бути розпарсений як число, а оновлення може ненавмисно скинути попереднє перевизначення.

Helm застосовує значення в порядку пріоритету, де перемагають пізніші та конкретніші вхідні дані. Думайте про типове значення чарта як про заводське налаштування, про файл значень як про профіль середовища, а про --set — як про виправлення з командного рядка для цього одного запуску. Модель проста, але нею легко зловживати, коли ви розкидаєте важливі налаштування довгою командою оболонки, яку ніхто не може переглянути.

Ієрархія значень (від найнижчого до найвищого пріоритету)

1. Типові значення в чарті (values.yaml)
2. Значення батьківського чарта
3. Файл значень, переданий через -f
4. Окремі значення через --set

Ієрархія пояснює, чому вбудоване значення перемагає файл. Вона також пояснює, чому кілька файлів читаються зліва направо, де пізніші файли перевизначають ранніші, коли з’являється той самий ключ. Цей дизайн дозволяє вам тримати базовий values.yaml, накласти production.yaml і все ще застосувати одноразове перевизначення для короткої вправи без редагування файлу.

Приклад файлу значень

my-values.yaml

replicaCount: 3

image:
  repository: nginx
  tag: "1.21"
  pullPolicy: IfNotPresent

service:
  type: NodePort
  ports:
    http: 80

resources:
  limits:
    cpu: 100m
    memory: 128Mi
  requests:
    cpu: 50m
    memory: 64Mi

nodeSelector:
  disktype: ssd

Приклад файлу навмисно бере тег образу в лапки. YAML має правила приведення типів, які можуть вас здивувати, і рядки, що схожі на версії, краще трактувати як рядки. Запити та ліміти ресурсів залишаються величинами Kubernetes, тож їхні одиниці мають значення. Чарт може зробити ці значення зручними для задання, але отриманий Deployment усе одно має бути валідним для API-сервера Kubernetes 1.35+.

Значення не валідуються автоматично, якщо чарт не надає схему або згенеровані маніфести не провалюють валідацію Kubernetes. Це означає, що друкарська помилка може просто не дати жодної зміни, якщо шаблон ніколи не читає ключ із помилкою. Найбезпечніша звичка — інспектувати типові значення, щоб знайти точний шлях, застосувати перевизначення, згенерувати маніфест чи зробити пробний прогін, а потім перевірити, що живий об’єкт містить очікуване поле.

Секретні значення заслуговують на особливу обережність. Helm може генерувати Secret’и, але історія релізу все одно може зберігати згенеровані маніфести та значення у сховищі Kubernetes залежно від команди та поведінки драйвера. Не вписуйте реалістичні облікові дані у приклади й не трактуйте файл значень як безпечний менеджер секретів. Для виробничих систем інтегруйте значення чарта зі схваленим організацією робочим процесом роботи із секретами замість того, щоб вбудовувати чутливий матеріал у повторно використовувані файли.

# Install with values file
helm install my-release bitnami/nginx -f my-values.yaml

# Multiple values files (later overrides earlier)
helm install my-release bitnami/nginx -f values.yaml -f production.yaml

# Combine file and inline
helm install my-release bitnami/nginx -f values.yaml --set replicaCount=5

Файли значень зазвичай є безпечнішим вибором за замовчуванням для всього, що ви захочете повторити. Вони доступні для перегляду, придатні для порівняння й менш схильні до помилок, ніж довгий ланцюжок --set. Вбудовані перевизначення все ще важливі в завданнях у стилі CKAD, бо вони швидкі, але використовуйте їх для невеликих змін, таких як кількість реплік, тип сервісу чи один іменований ключ, а не для цілого профілю середовища.

Є також людський чинник. Файл значень може прочитати той, хто не знає точної команди оболонки, що створила реліз, тоді як довга команда може жити лише в історії термінала. Коли оновлення провалюється, файл дає вам стабільну точку порівняння: очікувані значення, попередні значення та поточні значення релізу. Цього порівняння часто достатньо, щоб виявити, чи помилка — це пропущений ключ, друкарська помилка чи навмисна зміна.

# Simple value
--set replicaCount=3

# Nested value
--set image.tag=1.21

# String value (use quotes for special chars)
--set image.repository="my-registry.com/nginx"

# Array value
--set nodeSelector.disktype=ssd

# Multiple values
--set replicaCount=3,service.type=NodePort

# List items
--set ingress.hosts[0].host=example.com

Зробіть паузу й передбачте: якщо ви передаєте і файл значень з replicaCount: 2, і --set replicaCount=5 в одній команді встановлення, яке значення перемагає? Вбудоване значення --set перемагає, бо це найконкретніший рівень. Така поведінка дозволяє перевизначенням з командного рядка латати повторно використовуваний файл, але це також означає, що поспішна команда оболонки може приховати значення, яке рецензенти очікують побачити в системі контролю версій.

Правило дизайну — тримати тривкий намір у файлі, а тимчасовий намір — у командному рядку. Якщо налаштування пояснює, як має працювати виробниче середовище, помістіть його у файл значень. Якщо налаштування існує лише для того, щоб завершити лабораторну роботу чи перевірити невелику зміну, --set є прийнятним. Ця відмінність робить оновлення безпечнішими, бо ви можете повторно застосувати повний файл замість відтворювати попередні вибори з пам’яті.

Для практики CKAD вивчіть обидві форми, а не обирайте одну назавжди. Завдання з обмеженням часу може винагородити коротке вбудоване перевизначення, тоді як запит на усунення несправностей може вимагати від вас відкрити чи створити файл значень. Навичка — це не «завжди використовувати файли» чи «завжди використовувати --set»; навичка — це узгодження тривалості конфігурації з тривалістю завдання.

Коли задіяно кілька джерел значень, пишіть команду в тому самому порядку, в якому ви хочете, щоб Helm про них міркував. Почніть із широких типових значень через файли, потім додайте найвужче перевизначення останнім. Якщо кінцевий результат вас дивує, спростіть команду й згенеруйте знову. Налагоджувати значення набагато легше, коли кожен рівень має ідентифіковану мету, а не є купою непов’язаних прапорців.

Життєвий цикл релізу: встановлення, оновлення, відкат і видалення

Реліз Helm має історію, і саме ця історія є причиною того, що відкат можливий. Перше встановлення створює ревізію 1. Кожне оновлення створює пізнішу ревізію. Відкат також створює нову ревізію, яка вказує живі ресурси назад до більш раннього стану, тож історія не стирається. Це відрізняється від думки «відкат видаляє погане оновлення»; Helm записує дію відновлення як частину часової шкали.

Історія особливо корисна, коли дві зміни відбуваються близько одна за одною. Уявіть, що одне оновлення змінило replicaCount, а наступне — тег образу. Якщо Поди починають падати після другої зміни, відкат до безпосередньо попередньої ревізії може зберегти зміну реплік, водночас скасувавши зміну образу. Якщо ж ви відкотите надто далеко, ви можете виправити проблему з образом, але також скасувати валідну зміну масштабування. Таблиця історії — це те, як ви приймаєте рішення.

Описи релізів можуть покращити це рішення, коли автоматизація їх використовує, бо вони дають майбутнім операторам контекст поза номером ревізії. Навіть без власних описів статус та позначка часу оновлення можуть скеровувати ваше розслідування. Ключове — читати історію перед дією, а не після. Щойно ви відкотилися, історія знову змінюється, і початкова послідовність стає трохи складнішою для тлумачення новачками.

Оновлення — це місце, де дисципліна значень важить найбільше. Якщо ви запускаєте helm upgrade лише з одним вбудованим значенням, Helm має вирішити, що робити зі значеннями з попереднього релізу та значеннями з типових значень нового чарта. Прапорець --reuse-values каже Helm перенести значення попереднього релізу вперед, а потім застосувати ваші нові перевизначення, що часто є бажаною поведінкою для невеликої зміни.

# Upgrade with new values
helm upgrade my-release bitnami/nginx --set replicaCount=5

# Upgrade with values file
helm upgrade my-release bitnami/nginx -f new-values.yaml

# Upgrade or install if not exists
helm upgrade --install my-release bitnami/nginx

# Reuse existing values and add new ones
helm upgrade my-release bitnami/nginx --reuse-values --set image.tag=1.21

Зупиніться й подумайте: ви запускаєте helm upgrade my-release bitnami/nginx --set replicaCount=5 без --reuse-values. Що вам слід перевірити, перш ніж припускати, що реліз усе ще має кожне налаштування з попереднього встановлення? Інспектуйте значення релізу й порівняйте їх із файлом значень, який ви мали намір зберегти. Помилка не в тому, що Helm оновив; помилка в тому, що оператор не зробив бажаний набір значень явним.

В автоматизованій доставці helm upgrade --install популярний, бо перетворює два можливі стани на один шлях команди. Ця зручність не усуває потреби в явних значеннях, виборі версії чарта, націлюванні на простір імен та перевірці. Команда відповідає на питання «чи має цей реліз існувати після того, як завдання відпрацює?». Вона не відповідає на питання «чи обрали ми точний пакет та конфігурацію, призначені для цього середовища?».

Helm також має прапорці керування збоями, що можуть змінити операційний результат оновлення, але ви маєте розуміти модель релізу, перш ніж покладатися на них. Поведінка відкату-при-збої може допомогти не залишати невдалий реліз як видимий кінцевий стан, проте спроба зміни все одно заслуговує на розслідування. Автоматичний відкат не є заміною читання історії, статусу та подій Kubernetes, коли розгортання провалюється.

Відкат має бути свідомим, а не рефлексом. Спершу прочитайте історію, визначте ревізію, що відповідає останньому відомому справному стану, а потім відкотіться до цієї ревізії. Якщо ви пропустите ревізію, Helm відкочується до попередньої ревізії, що зручно, коли ви знаєте, що останнє оновлення є єдиною проблемою, і ризиковано, коли кілька змін сталися швидко.

# Rollback to previous revision
helm rollback my-release

# Rollback to specific revision
helm rollback my-release 2

# Check history first
helm history my-release

Видалення прибирає ресурси Kubernetes релізу, тоді як --keep-history зберігає метадані історії релізу. У лабораторії іспиту прибирання має значення, бо старі ресурси можуть заважати пізнішим завданням. У виробництві рішення про прибирання потребують більшої обачності, бо PVC, CRD та зовнішні ресурси можуть мати правила життєвого циклу, що переживають сам реліз Helm.

# Uninstall release
helm uninstall my-release

# Uninstall but keep history
helm uninstall my-release --keep-history

# Uninstall from namespace
helm uninstall my-release -n production

Найшвидший повний робочий процес — це встановити, перевірити, оновити, перевірити, відкотити лише за потреби й прибрати, коли завдання виконано. Зверніть увагу, що перевірка з’являється після кожної команди, що змінює стан. Helm може сказати вам, чи відпрацювала операція релізу, але Kubernetes каже вам, чи відповідають Поди, Сервіси, мітки та події бажаному стану.

Ще одна деталь життєвого циклу важлива для прибирання: видалення релізу — це не те саме, що видалення кожного об’єкта, що колись торкався застосунку. Чарти можуть використовувати хуки, політики збереження, персистентні томи чи CRD, що потребують окремої обробки залежно від дизайну чарта. Для вправ із nginx цього модуля звичайного видалення достатньо, але звичка перевіряти ресурси, що залишилися, є цінною, коли ви пізніше працюватимете з базами даних чи операторами.

Якщо чарт містить CRD, зрозумійте, що Helm має особливу поведінку щодо їх встановлення та оновлення. Багато застосункових чартів уникають цієї складності, але платформенні чарти та оператори часто залежать від неї. Практичний висновок для роботи рівня CKAD — розпізнавати, коли чарт створює звичайні навантаження в межах простору імен, а коли — підтримувальні ресурси з областю кластера. Це розпізнавання впливає на прибирання, права доступу та на те, що насправді можуть контролювати прапорці простору імен.

Сценарій 1: Встановлення та налаштування

# Add repo
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

# Install with custom values
helm install my-nginx bitnami/nginx \
  --set replicaCount=2 \
  --set service.type=ClusterIP \
  -n web --create-namespace

# Verify
helm list -n web
kubectl get pods -n web

Цей перший сценарій демонструє, чому --create-namespace корисний і чому він не повинен замінювати чітке мислення про простори імен. Прапорець створює цільовий простір імен за потреби, але кожна пізніша команда Helm та Kubernetes усе одно потребує того самого простору імен. Якщо завдання просить web, послідовно пишіть -n web, щоб ваші перевірки релізу та навантаження збігалися.

Сценарій 2: Оновлення та відкат

# Check current release
helm list -n web
helm get values my-nginx -n web

# Upgrade
helm upgrade my-nginx bitnami/nginx --reuse-values --set replicaCount=3 -n web

# Verify upgrade
helm history my-nginx -n web
kubectl get pods -n web

# Something goes wrong - rollback
helm rollback my-nginx 1 -n web

# Verify
helm list -n web

Цей другий сценарій навмисно вузький: змінюється лише кількість реплік, бо --reuse-values переносить вперед попереднє перевизначення service.type=ClusterIP. Пропуск --reuse-values під час оновлення, яке передає лише --set replicaCount=3, повторно застосовує типові значення чарта для кожного значення, не зазначеного в цьому командному рядку (наприклад, service.type може повернутися до LoadBalancer). У реальному середовищі ви зазвичай надавали б перевагу файлу значень або --reuse-values, щоб оновлення не залежало від запам’ятовування кожного попереднього перевизначення. На іспиті важлива звичка — перевіряти значення та історію перед тим, як вживати дій з відновлення, бо відкат до неправильної ревізії марнує час і може приховати справжню помилку.

Сценарій 3: Інспекція перед встановленням

# See what you're installing
helm show values bitnami/nginx | head -50

# Dry run to see generated manifests
helm install test bitnami/nginx --dry-run=client | head -n 50

# Then install
helm install test-nginx bitnami/nginx

Пробні прогони — це дешевий спосіб виловити очевидні несподіванки з рендерингом і конфігурацією. Helm 4 також розрізняє клієнтську та серверну поведінку пробного прогону, але операційна ідея та сама: інспектуйте згенеровані маніфести, перш ніж робити зміну в кластері, коли завдання неоднозначне. Пам’ятайте, що пробний прогін може показати згенеровані Secret’и, тож не вставляйте чутливий вивід у тикети чи чат-системи.

Фіксація версій чартів — ще один елемент керування життєвим циклом, що важить більше поза лабораторією з обмеженням часу. Типові значення репозиторію рухаються в міру того, як супровідники публікують нові пакети, тож «встановіть найновіший чарт» не є відтворюваним, якщо найновіший справді не є вимогою. Реальний конвеєр доставки зазвичай має фіксувати версії чартів, переглядати примітки до релізу та навмисно оновлювати пакет чарта. У вправі CKAD дотримуйтеся версії, яку дає запит, якщо вона є.

Структура чарта та робочий процес налагодження

Вам не потрібно бути автором повного чарта для цього модуля, але структура чарта пояснює, що ви інспектуєте. Chart.yaml описує метадані, values.yaml визначає типові значення, templates/ містить маніфести Kubernetes із шаблонними виразами, а charts/ зберігає залежності. Коли Helm генерує результат, він читає ці частини разом і породжує звичайні маніфести, які API-сервер Kubernetes може валідувати.

my-chart/
├── Chart.yaml          # Chart metadata
├── values.yaml         # Default configuration
├── charts/             # Dependency charts
├── templates/          # Kubernetes manifests
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── _helpers.tpl    # Template helpers
│   └── NOTES.txt       # Post-install notes
└── README.md

Дерево також пояснює, чому налагодження має рухатися від широкого до конкретного. Спершу запитайте, чи існує реліз в очікуваному просторі імен. Потім запитайте, які значення зберіг Helm. Потім згенеруйте чи отримайте маніфест і порівняйте поля згенерованого ресурсу із завданням. Нарешті, скористайтеся kubectl, щоб інспектувати живі об’єкти та події, бо збої під час виконання належать контролерам Kubernetes, а не лише пакету чарта.

Шаблони-помічники варто розпізнавати, навіть якщо ви ніколи не редагуєте їх у цьому модулі. Файли на кшталт _helpers.tpl часто визначають імена, мітки та фрагменти селекторів, повторно використовувані в кількох шаблонах. Якщо згенеровані Deployment і Service спільно використовують селектор, ця узгодженість може походити з такого помічника. Якщо мітки виглядають інакше, ніж ви очікували, помічник — одна з причин, чому чарт може породжувати імена, що не точно дзеркалять ім’я релізу.

NOTES.txt — ще один файл чарта з операційною цінністю. Він не створює об’єктів Kubernetes, але може надрукувати корисні інструкції після встановлення, URL сервісів, тестові команди чи специфічні для чарта застереження. Коли реліз встановлюється успішно, а ви не знаєте, як до нього дістатися, helm get notes може бути швидшим за вгадування, який порт Service чи мітку автор чарта мав на увазі для вас.

Що сталося б, якби ви запустили helm install my-app bitnami/nginx у просторі імен default, а потім пізніше запустили helm list у просторі імен production? Ви не побачили б my-app у переліку, обмеженому простором імен production, бо записи релізів Helm обмежені простором імен. Це має значення під час іспиту, бо правильний реліз у неправильному просторі імен усе одно є неправильним для вимоги, прив’язаної до простору імен.

# Release stuck in pending-install
helm list --pending
helm uninstall stuck-release

# See what's wrong
helm get manifest my-release | kubectl apply --dry-run=server -f -

# Debug template rendering
helm template my-release bitnami/nginx --debug

# Check release status
helm status my-release

Конвеєр helm get manifest особливо корисний, коли реліз уже існує. Він дозволяє вам отримати точний маніфест, який Helm зберіг для цього релізу, і попросити API-сервер Kubernetes валідувати його. Це не доводить, що навантаження справне, але може виявити проблеми зі схемою та допуском без вгадування, який шаблон чи значення породили проблемне поле.

Налагодження згенерованого маніфесту має залишатися пов’язаним із володінням. Якщо ви вручну відредагуєте керований Helm Deployment через kubectl edit, Helm не дізнається про це автоматично як про зміну значення. Пізніше оновлення може перезаписати ручне редагування, бо Helm генерує з чарта та значень знову. Для керованих ресурсів надавайте перевагу виправленню вхідного значення чи версії чарта, щоб майбутні операції Helm відтворювали бажаний стан.

# See rendered templates
helm template my-release bitnami/nginx > rendered.yaml

# Validate without installing
helm install my-release bitnami/nginx --dry-run=client --debug

# Get notes (post-install instructions)
helm get notes my-release

helm template генерує результат локально й чудово підходить для розуміння того, як значення перетворюються на YAML. helm install --dry-run=client --debug симулює шлях встановлення й друкує діагностичний контекст. helm get notes легко проігнорувати, але багато чартів вміщують там інструкції після встановлення, включно з підказками щодо виявлення сервісів чи заповнювачами для типових облікових даних, що пояснюють, як безпечно протестувати застосунок.

Практична послідовність налагодження для роботи CKAD: перелічіть реліз, отримайте статус, отримайте значення, отримайте маніфест, інспектуйте об’єкти Kubernetes за міткою, а потім прочитайте події з Пода, що падає. Не починайте зі сліпої зміни значень. Найшвидше виправлення — це зазвичай те, що доводить, чи є збій вибором чарта, областю простору імен, пріоритетом значень, згенерованим YAML чи поведінкою під час виконання.

Та сама послідовність працює, коли сам статус релізу — pending чи failed. Стани pending можуть походити з хуків, поведінки очікування, недоступних ресурсів чи перерваних операцій, тож читайте helm status перед прибиранням. Якщо ви вирішите видалити застряглий реліз, перевірте, чи залишаються після цього будь-які Поди, Job’и чи Сервіси. Прибирання без інспекції може приховати корисні докази чи залишити об’єкти, що заважатимуть наступному встановленню.

Нарешті, тримайте вивід команд обмеженим. helm get all може бути корисним, але може бути галасливим, а галасливий вивід палить час іспиту. Спершу використовуйте вузьку команду: values при налагодженні конфігурації, manifest при налагодженні згенерованого YAML, notes при пошуку інструкцій доступу та history при відновленні попереднього стану. Правильна вузька команда дає вам чистішу відповідь, ніж широке звалище, яке доводиться переглядати.

Патерни та антипатерни

Патерни та антипатерни корисні лише тоді, коли вони змінюють вашу наступну команду. Для Helm різниця між надійним і крихким робочим процесом — це зазвичай не синтаксис helm install; це те, чи тримає оператор значення придатними до перегляду, простори імен явними, а перевірку пов’язаною зі станом і Helm, і Kubernetes. Таблиця нижче перетворює ці звички на правила прийняття рішень, які ви можете застосовувати під час лабораторних робіт і реальних розгортань.

Патерн	Коли його використовувати	Чому він працює	Міркування щодо масштабування
Файл значень як контракт середовища	Повторювані встановлення чи оновлення для dev, staging чи production	Тримає тривкі налаштування придатними до перегляду й відтворюваними	Зберігайте файли разом із репозиторієм застосунку чи платформи, щоб оновлення чартів можна було переглядати
Команди з явним простором імен	Будь-яке завдання поза default чи будь-який кластер з кількома командами	Не дає пошуку релізу та перевірці навантаження розходитися	Використовуйте скрипти чи змінні CI, щоб передавати простір імен послідовно
Інспектувати перед зміною	Невідомий чарт, неясні типові значення чи ризиковане оновлення	helm show values, пробний прогін і вивід template розкривають згенерований намір	Додайте валідацію рендерингу в конвеєри перед змінами в кластері
Відкат із пріоритетом історії	Невдале оновлення чи підозра на погану ревізію релізу	Уникає відкату до неправильної ревізії під тиском	Тримайте описи релізів змістовними, коли автоматизація виконує оновлення

Антипатерн	Що йде не так	Краща альтернатива
Довгі неповторювані ланцюжки --set	Важливі налаштування зникають з перегляду й їх легко неправильно надрукувати	Перенесіть тривкі налаштування у файл значень і резервуйте --set для невеликих змін
Перелік без контексту простору імен	Валідний реліз здається відсутнім, або інспектується неправильний реліз	Використовуйте helm list -A для виявлення, потім повторюйте -n <namespace> у сфокусованих командах
Трактування успіху Helm як справності застосунку	Реліз існує, доки Поди падають, залишаються в pending чи провалюють готовність	Поєднуйте перевірки Helm із kubectl get pods, kubectl describe та селекторами на основі міток
Відкат без історії	Відновлення націлюється на неправильну ревізію чи приховує початковий збій	Запустіть helm history й оберіть ревізію навмисно

Старша звичка, що лежить в основі обох таблиць, — це послідовність доказів. Helm має достатньо команд, щоб ви завжди могли запустити ще одну команду, але ще одна команда не є автоматично корисною. Обирайте команду, що звужує область збою: репозиторій, чарт, значення, історія релізу, згенерований маніфест чи живий об’єкт Kubernetes. Коли кожен крок має мету, Helm стає швидким, а не галасливим.

Рамка прийняття рішень

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

Ситуація	Перша команда	Наступна команда	Правило прийняття рішення
Ви не знаєте, де живе реліз	helm list -A	helm status <release> -n <namespace>	Виявляйте глобально, потім працюйте в точному просторі імен
Вам потрібні типові опції чарта	helm show values <chart>	helm show chart <chart>	Прочитайте типові значення чарта перед вибором ключів перевизначення
Вам потрібні живі налаштування релізу	helm get values <release> -n <namespace>	helm get manifest <release> -n <namespace>	Інспектуйте збережений стан релізу, а не лише типові значення чарта
Вам потрібне перше розгортання	helm install <release> <chart> -n <namespace>	kubectl get pods -n <namespace>	Встановіть, потім перевірте об’єкти навантаження в Kubernetes
Вам потрібне відтворюване розгортання	helm upgrade --install <release> <chart>	helm history <release> -n <namespace>	Використовуйте ідемпотентний upgrade/install, коли автоматизація може запуститися двічі
Вам потрібна невелика зміна	helm upgrade <release> <chart> --reuse-values --set key=value	helm get values <release> -n <namespace>	Переносьте попередні налаштування вперед, доки ви навмисно не заміните їх
Вам потрібне відновлення	helm history <release> -n <namespace>	helm rollback <release> <revision> -n <namespace>	Оберіть відому справну ревізію, потім перевірте Поди та Сервіси

Рамка також каже вам, коли Helm є неправильним першим інструментом. Якщо Поди вже створені й провалюють завантаження образів, починайте з подій Kubernetes після підтвердження, що реліз існує. Якщо Service недосяжний, інспектуйте згенерований Service та вибрані Поди. Якщо сам реліз у стані pending чи failed, залишайтеся в Helm достатньо довго, щоб прочитати статус і маніфест, потім перехресно перевірте об’єкти Kubernetes, які створив Helm.

Який підхід ви обрали б тут і чому: одноразова лабораторна робота просить вас задати replicaCount=3, тоді як ваше виробниче розгортання потребує реплік, запитів ресурсів, типу сервісу, селектора нод та тегу образу? Лабораторна робота може використати --set, бо перевизначення невелике й одноразове. Виробниче розгортання має використати файл значень, бо налаштування визначають довготривалий операційний намір, що заслуговує на перегляд і відтворюваність.

Чи знали ви?

• Helm 3 прибрав Tiller. Helm 2 використовував серверний компонент під назвою Tiller, який зазвичай потребував широких прав у кластері, тоді як Helm 3 і пізніші використовують облікові дані Kubernetes користувача безпосередньо з клієнтського робочого процесу.
• Helm 4 — це поточна головна лінія в офіційній документації. Документація Helm тепер показує функції Helm 4, такі як server-side apply для нових релізів, тоді як релізи Helm 3 можуть продовжувати використовувати свою наявну поведінку client-side apply після оновлення.
• helm upgrade --install є ідемпотентним. Він встановлює, коли реліз не існує, та оновлює, коли він є, що робить його корисним для завдань CI/CD та повторюваних практичних скриптів для іспиту.
• Helm зберігає історію релізу у сховищі Kubernetes. Типовий драйвер зберігає ревізії як Secret’и, ось чому відкат може націлюватися на старіші ревізії й чому область простору імен має значення для виявлення релізу.

Типові помилки

Помилка	Чому вона трапляється	Як її виправити
Забути helm repo update	Локальний індекс репозиторію застарілий, тож пошук і встановлення можуть не відображати поточних метаданих чарта	Запускайте helm repo update після додавання репозиторію та перед тим, як покладатися на результати пошуку
Неправильний простір імен	Команди Helm типово використовують поточний простір імен, тоді як завдання може вимагати web, production чи іншу ціль	Послідовно використовуйте -n namespace та використовуйте helm list -A при виявленні невідомого релізу
Друкарські помилки в --set	Значення чарта є ключовими, тож шлях із помилкою може не змінити поле, яке ви мали на увазі	Перевірте helm show values, зробіть пробний прогін та інспектуйте helm get values після встановлення
Забути --reuse-values	Оновлення, призначене для зміни одного поля, може втратити попередні налаштування, коли не надано повний набір бажаних значень	Використовуйте повний файл значень або додайте --reuse-values для невеликих подальших змін
Не перевірити історію перед відкатом	Попередня ревізія може не бути останнім відомим справним станом після кількох змін	Запустіть helm history та відкотіться до конкретної ревізії, коли ціль важить
Сплутати типові значення чарта зі значеннями релізу	helm show values читає чарт, а не встановлений реліз	Використовуйте helm get values <release> -n <namespace> для живої конфігурації релізу
Трактувати згенерований YAML як доказ роботи	Маніфест може бути валідним, доки Поди провалюють завантаження образів, планування чи готовність	Поєднуйте helm get manifest із kubectl get pods, kubectl describe та подіями

Тест

Питання 1: Вашому конвеєру CI/CD потрібно розгорнути чарт, який може бути або не бути вже встановленим у кластері. Він має встановлювати під час першого запуску та оновлювати під час пізніших запусків, не провалюючись на наявному релізі. Який патерн Helm вам слід використати?

Використовуйте helm upgrade --install my-release bitnami/nginx із правильним простором імен та вхідними значеннями. Прапорець --install робить шлях оновлення ідемпотентним, бо Helm встановлює, коли релізу немає, та оновлює, коли він уже існує. Звичайний helm install провалився б після першого успішного запуску, тоді як звичайний helm upgrade провалився б до того, як реліз існує. Для безпечнішої автоматизації додайте версію чарта та файл значень, який ви маєте намір зробити авторитетним, замість того, щоб залежати від мінливих типових значень репозиторію.

Питання 2: Колега оновив реліз через `helm upgrade my-app bitnami/nginx --set replicaCount=5`, і тепер `service.type` повернувся до типового значення чарта замість попереднього значення `ClusterIP`. Що вам слід діагностувати і як слід писати майбутні оновлення?

Спершу діагностуйте значення релізу через helm get values my-app -n <namespace> та порівняйте їх із файлом значень чи командою встановлення, що створила попередню ревізію. Імовірна помилка в тому, що оновлення надало лише одне вбудоване значення й не перенесло вперед попередні власні налаштування. Майбутні оновлення мають використовувати повний файл значень або --reuse-values під час застосування невеликого додаткового перевизначення. Відкат може відновити попередню ревізію, але тривке виправлення — це зробити бажані значення явними.

Питання 3: Під час завдання на іспиті реліз `web-prod` існує у просторі імен `frontend`, але `helm get values web-prod` повертає помилку release-not-found. Що вам слід перевірити, перш ніж змінювати чарт?

Перевірте область простору імен, перш ніж щось змінювати. Релізи Helm обмежені простором імен, тож команда має бути helm get values web-prod -n frontend, якщо тільки ваш поточний контекст уже не вказує туди. Використовуйте helm list -A, коли ви не впевнені, де живе реліз, потім повторіть виявлений простір імен у командах status, values, history, rollback та uninstall. Зміна значень перед підтвердженням контексту простору імен марнує час і може створити другий реліз у неправильному просторі імен.

Питання 4: Ви встановили чарт, і Поди входять у цикл падінь (crash-loop). Вам потрібно інспектувати точний YAML Kubernetes, який згенерував Helm, а потім вирішити, чи проблема в рендерингу, чи в поведінці під час виконання. Яку послідовність вам слід використати?

Почніть із helm get manifest <release> -n <namespace>, щоб отримати згенерований YAML, збережений для релізу. Якщо маніфест виглядає підозріло, валідуйте чи згенеруйте знову через helm template чи пробний прогін із тими самими значеннями. Якщо маніфест правильний, переходьте до перевірок Kubernetes, таких як kubectl get pods -n <namespace> та kubectl describe pod, щоб прочитати події, стан контейнера та деталі готовності. Helm може показати, що він подав, але Kubernetes пояснює, чому навантаження не справне.

Питання 5: Вам потрібно розгорнути nginx у новий простір імен `web` із двома репліками та внутрішнім сервісом. Які частини команди захищають вас від двох найпоширеніших помилок?

Використовуйте явні прапорці простору імен та створення, наприклад helm install my-nginx bitnami/nginx --set replicaCount=2 --set service.type=ClusterIP -n web --create-namespace. Прапорець простору імен не дає релізу опинитися в default, а --create-namespace обробляє випадок, коли web ще не існує. Вбудовані значення задають потрібну кількість реплік і тип сервісу для цього невеликого завдання. Перевірка все одно має включати helm list -n web та kubectl get pods -n web.

Питання 6: Оновлення провалилося, і колега хоче негайно запустити `helm rollback my-app` без аргументу ревізії. Яку інформацію вам слід зібрати спершу, і коли скорочена форма прийнятна?

Спершу запустіть helm history my-app -n <namespace>, щоб ви могли побачити послідовність ревізій та визначити останній відомий справний стан. Скорочена форма без ревізії прийнятна лише тоді, коли ви впевнені, що безпосередньо попередня ревізія є бажаною ціллю. Якщо нещодавно сталося кілька оновлень чи відкатів, явна ревізія безпечніша, бо уникає відновлення до іншого поганого стану. Після відкату перевірте і статус Helm, і справність навантаження Kubernetes.

Питання 7: Ви обираєте між файлом значень та `--set` для розгортання, що включає ресурси, тип сервісу, тег образу, селектор нод та кількість реплік. Який підхід вам слід обрати і чому?

Оберіть файл значень для цього розгортання, бо конфігурація тривка, складається з кількох ключів і варта перегляду як повний контракт середовища. Довга команда --set легко друкується з помилкою й важко відтворюється під час наступного оновлення. Вбудовані перевизначення все ще корисні для невеликих тимчасових змін, таких як одне коригування реплік у лабораторії. Для більшого розгортання збережіть файл значень, встановлюйте чи оновлюйте через -f та інспектуйте значення релізу опісля.

Практична вправа

Сценарій вправи: розгорніть і керуйте релізом nginx, керованим через Helm, потім доведіть, що ви вмієте інспектувати значення, безпечно оновлювати, свідомо відкочувати й прибирати, не залишаючи розкиданих ресурсів. Робочий процес використовує чарт nginx від Bitnami, бо він надає достатньо значень, щоб попрактикувати реальну поведінку перевизначення без необхідності бути автором чарта. Запускайте команди в одноразовому лабораторному кластері Kubernetes 1.35+ чи в пов’язаному середовищі Killercoda.

Підготовка:

# Add repository
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

Завдання 1: Інспектування та встановлення

Прочитайте доступні значення перед встановленням, потім розгорніть реліз на ім’я web із двома репліками та сервісом ClusterIP. Це завдання тренує звичку спершу інспектувати чарт, потім застосовувати невелике перевизначення й перевіряти і стан Helm, і Поди Kubernetes після встановлення. Якщо типові значення чарта вже відповідають частині вимоги, усе одно задайте запитані значення, щоб ваша стенограма команд була явною.

# See available values
helm show values bitnami/nginx | head -30

# Install with custom values
helm install web bitnami/nginx \
  --set replicaCount=2 \
  --set service.type=ClusterIP

# Verify installation
helm list
kubectl version --short
kubectl get pods -l app.kubernetes.io/instance=web

Нотатки до розв'язання Завдання 1

Реліз має з’явитися в helm list, а селектор Подів має повернути Поди з міткою app.kubernetes.io/instance=web. Якщо Поди не з’являються, перевірте, чи реліз не було встановлено в простір імен, відмінний від вашого поточного контексту. Якщо Поди з’являються, але не готові, опишіть один Под і прочитайте події перед зміною значень Helm.

Завдання 2: Оновлення

Оновіть той самий реліз до трьох реплік, водночас переносячи вперед наявне власне налаштування сервісу. Важлива частина — не просто збільшення кількості реплік; це збереження попереднього наміру під час подальшої команди. Після оновлення скористайтеся історією, щоб підтвердити, що існує нова ревізія, та скористайтеся Kubernetes, щоб підтвердити, що Deployment узгодив запитану кількість Подів.

# Upgrade replicas
helm upgrade web bitnami/nginx --reuse-values --set replicaCount=3

# Check history
helm history web

# Verify pods
kubectl get pods -l app.kubernetes.io/instance=web

Нотатки до розв'язання Завдання 2

helm history web має показати пізнішу ревізію після оновлення. Кількість Подів має рухатися до запитаної кількості реплік, хоча Kubernetes може взяти трохи часу на створення чи завершення Подів. Якщо налаштування сервісу несподівано змінилося, інспектуйте helm get values web та перегляньте, чи ваше оновлення повторно використало, чи замінило попередні значення.

Завдання 3: Відкат

Відкотіть реліз до ревізії 1, потім знову інспектуйте значення та Поди. Це завдання закріплює, що відкат — це операція релізу зі спостережуваними наслідками для Kubernetes. Не трактуйте відкат як невидимий; він створює ще один запис історії й просить кластер узгодити ресурси назад до згенерованого стану вибраної ревізії.

# Rollback to revision 1
helm rollback web 1

# Verify reverted
helm get values web
kubectl get pods -l app.kubernetes.io/instance=web

Нотатки до розв'язання Завдання 3

Після відкату helm get values web має відображати значення, збережені для цільової ревізії. Кількість Подів може знову змінитися, оскільки Deployment узгоджується. Якщо значення виглядають правильно, а Поди — ні, переходьте до подій Kubernetes та статусу Deployment, а не сліпо повторюйте команди відкату.

Завдання 4: Прибирання

Видаліть реліз після завершення робочого процесу. Прибирання є частиною вправи, бо застарілий реліз може зробити пізніші тренування заплутаними, особливо коли селектори повертають старі Поди чи helm install провалюється, бо ім’я релізу вже зайняте. Якщо ви встановлювали в недефолтний простір імен, додайте той самий прапорець простору імен під час видалення.

helm uninstall web

Нотатки до розв'язання Завдання 4

helm list більше не має показувати реліз у просторі імен, де його було встановлено. Якщо об’єкти навантаження залишаються, перевірте, чи їх було створено хуками, збережено політикою чарта чи встановлено в інший простір імен. Для цього базового робочого процесу nginx звичайне видалення має прибрати об’єкти, керовані релізом.

Тренувальні вправи

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

Вправа 1: Керування репозиторієм (Ціль: 2 хвилини)

# Add bitnami repo
helm repo add bitnami https://charts.bitnami.com/bitnami

# Update
helm repo update

# Search for mysql
helm search repo mysql

# List repos
helm repo list

Вправа 2: Базове встановлення (Ціль: 2 хвилини)

# Install nginx
helm install drill2 bitnami/nginx

# List releases
helm list

# Check status
helm status drill2

# Cleanup
helm uninstall drill2

Вправа 3: Встановлення зі значеннями (Ціль: 3 хвилини)

# Create values file
cat << 'EOF' > /tmp/values.yaml
replicaCount: 2
service:
  type: ClusterIP
EOF

# Install with values file
helm install drill3 bitnami/nginx -f /tmp/values.yaml

# Verify values applied
helm get values drill3

# Cleanup
helm uninstall drill3

Вправа 4: Оновлення та відкат (Ціль: 4 хвилини)

# Install
helm install drill4 bitnami/nginx --set replicaCount=1

# Verify install
helm status drill4

# Upgrade
helm upgrade drill4 bitnami/nginx --set replicaCount=3

# Check history
helm history drill4

# Rollback
helm rollback drill4 1

# Verify
helm get values drill4

# Cleanup
helm uninstall drill4

Вправа 5: Операції з простором імен (Ціль: 3 хвилини)

# Install in new namespace
helm install drill5 bitnami/nginx -n helm-test --create-namespace

# List in namespace
helm list -n helm-test

# Get pods in namespace
kubectl get pods -n helm-test

# Cleanup
helm uninstall drill5 -n helm-test
kubectl delete ns helm-test

Вправа 6: Повний сценарій (Ціль: 6 хвилин)

Сценарій: Розгорніть готовий до виробництва nginx.

Щоб зробити розгортання готовим до виробництва, ми збільшуємо кількість реплік для високої доступності, використовуємо NodePort для забезпечення зовнішньої доступності та застосовуємо суворі ліміти ресурсів, щоб запобігти споживанню застосунком надлишкової ємності кластера. У реальній виробничій системі ви зазвичай переглядали б ці значення у файлі та фіксували б версію чарта; ця вправа тримає фокус на життєвому циклі релізу Helm.

# 1. Create values file
cat << 'EOF' > /tmp/prod-values.yaml
replicaCount: 3
service:
  type: NodePort
  nodePorts:
    http: 30080
resources:
  limits:
    cpu: 100m
    memory: 128Mi
  requests:
    cpu: 50m
    memory: 64Mi
EOF

# 2. Dry-run first
helm install prod-web bitnami/nginx -f /tmp/prod-values.yaml --dry-run=client

# 3. Install
helm install prod-web bitnami/nginx -f /tmp/prod-values.yaml

# 4. Verify
helm list
helm get values prod-web
kubectl get pods -l app.kubernetes.io/instance=prod-web

# 5. Upgrade with more replicas
helm upgrade prod-web bitnami/nginx -f /tmp/prod-values.yaml --set replicaCount=5

# Verify upgrade
helm status prod-web
kubectl get pods -l app.kubernetes.io/instance=prod-web

# 6. Something wrong - rollback
helm rollback prod-web 1

# 7. Cleanup
helm uninstall prod-web

Критерії успіху

• Ваш кластер повідомляє про Kubernetes 1.35+ (kubectl version показує сумісну версію сервера).
• Ви можете додати й оновити репозиторій Bitnami, не покладаючись на попередньо налаштоване середовище.
• Ви можете розгорнути іменований реліз Helm із власними значеннями та перевірити його і через Helm, і через kubectl.
• Ви можете пояснити, яке значення перемагає, коли типові значення, файли значень та --set визначають той самий ключ.
• Ви можете оновити реліз, навмисно зберігаючи попередні значення.
• Ви можете інспектувати історію релізу та відкотитися до конкретної ревізії.
• Ви можете прибрати релізи та простори імен, не залишаючи застарілих лабораторних ресурсів.

Перевірка для учня

Пропуск --reuse-values під час оновлення, яке передає лише --set replicaCount=3, повторно застосовує типові значення чарта для кожного значення, не зазначеного в цьому командному рядку (наприклад, service.type може повернутися до LoadBalancer).

Джерела

• https://docs.helm.sh/docs/
• https://docs.helm.sh/docs/overview/
• https://docs.helm.sh/docs/intro/using_helm/
• https://docs.helm.sh/docs/topics/charts/
• https://docs.helm.sh/docs/chart_best_practices/values/
• https://docs.helm.sh/docs/helm/helm_install/
• https://docs.helm.sh/docs/helm/helm_upgrade/
• https://docs.helm.sh/docs/helm/helm_rollback/
• https://docs.helm.sh/docs/helm/helm_history/
• https://docs.helm.sh/docs/helm/helm_get_values/
• https://docs.helm.sh/docs/helm/helm_get_manifest/
• https://docs.helm.sh/docs/helm/helm_template/
• https://docs.helm.sh/docs/helm/helm_uninstall/
• https://artifacthub.io/packages/helm/bitnami/nginx
• https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/
• https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/
• https://www.cncf.io/training/certification/ckad/

Наступний модуль

Модуль 2.3: Kustomize — налаштовуйте ресурси Kubernetes без шаблонів.