Модуль 0.3: Vim для YAML

Складність: [ШВИДКИЙ] — невеликий набір команд, висока віддача на іспиті

Час на проходження: 25–35 хвилин

Передумови: базова навігація в терміналі, рекомендовано налаштування середовища з Модуля 0.1

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

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

Налаштувати vim так, щоб YAML для Kubernetes використовував відступ у два пробіли, пробіли замість табуляцій та номери рядків, які полегшують пошук помилок парсера.
Діагностувати типові збої, які виникають під час редагування YAML, порівнюючи між собою стан режиму vim, прихований пробільний символ, рівні відступів та результат перевірки через kubectl.
Рефакторити маніфести Kubernetes у vim, копіюючи, видаляючи, зсуваючи та замінюючи блоки без повторного набирання великих фрагментів під тиском іспиту.
Оцінювати, коли vim, nano, kubectl --dry-run чи перенаправлення в оболонці є найшвидшим безпечним способом редагування для конкретного завдання CKA.
Виправляти зламані маніфести Pod та Deployment за допомогою повторюваного циклу «редагуй–перевір–виправ», який працює у середовищі лише з терміналом.

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

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

Ця ситуація насправді не є проблемою самого vim. Це проблема робочого процесу. Робота з Kubernetes дуже часто відбувається саме в терміналі, YAML чутливий до пробільних символів аж до окремого пробілу, і редактор через це стає частиною діагностичного шляху, а не просто інструментом набирання тексту. Учень, який вміє швидко рухатися файлом, бачити номери рядків, зберігати наявні відступи та перевіряти невеликі зміни одразу після внесення, може зосередити увагу на поведінці самого Kubernetes, а не витрачати її на боротьбу з невидимими символами.

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

Середовище іспиту може зробити nano доступним і навіть використовувати його за замовчуванням, залежно від поточного образу. Це не робить vim непотрібним. Vim залишається широко доступним у системах Linux, з’являється в багатьох сесіях усунення несправностей у промисловому середовищі й часто є тим редактором, до якого люди вдаються в мінімальних термінальних оточеннях. Правильний стандарт — це не вірність редактору; правильний стандарт — це те, чи можете ви безпечно відредагувати маніфест під тиском.

Аналогія з кабіною пілота

Режими vim схожі на органи керування в кабіні пілота. Один набір органів керування рухає літак, інший змінює налаштування радіо, а ще інший керує навігацією. Плутати ці органи керування небезпечно, але щойно розмежування стає чітким, кожна дія виконується швидше, бо органи керування спеціалізовані. У vim режим Normal рухає й редагує структуру, режим Insert набирає текст, а режим Command зберігає, виходить, шукає чи змінює поведінку редактора.

Частина 1: Побудуйте ментальну модель vim, перш ніж набирати YAML

Спершу vim здається дивним, бо не сприймає кожне натискання клавіші як введення тексту. Саме цей задум є джерелом і роздратування, і швидкості. У звичайному текстовому полі натискання d вставляє літеру d; у режимі Normal vim натискання dd видаляє рядок. Та сама клавіатура стає поверхнею команд, тож перша навичка — знати, який режим володіє наступним натисканням клавіші.

Найбезпечніша звичка відновлення доволі проста: коли редактор раптом вас здивував якоюсь несподіваною поведінкою, натисніть Esc один чи два рази, перш ніж робити будь-що інше. Натискання Esc гарантовано повертає вас у режим Normal, де команди на кшталт збереження, виходу, скасування, пошуку та видалення рядка поводяться цілком передбачувано. Ця звичка важлива, бо дуже багато помилок на іспиті виникає саме через спробу виконати :wq, перебуваючи ще в режимі Insert, або, навпаки, через спробу набирати YAML, перебуваючи ще в режимі Normal.

+------------------+        i, a, o         +------------------+
|  NORMAL MODE     | ---------------------> |  INSERT MODE     |
|  move/edit lines |                        |  type YAML text  |
|  dd, yy, p, u    | <--------------------- |  letters appear  |
+------------------+          Esc           +------------------+
          |
          | :
          v
+------------------+
|  COMMAND MODE    |
|  :w, :q, :wq     |
|  :set paste      |
|  :%s/old/new/g   |
+------------------+

Діаграма показує, чому Esc є клавішею скидання. Увійти в режим Insert можна кількома командами, але виходите ви з нього завжди однаково. Режим Command досягається з режиму Normal через :, тож надійна послідовність збереження — це завжди Esc, потім :w, потім Enter. Надійна послідовність «зберегти й вийти» — це завжди Esc, потім :wq, потім Enter.

Режим	Як увійти	Що робить	Приклад редагування Kubernetes
Normal	`Esc`	Навігація, видалення, копіювання, вставлення, скасування	Видалити поганий блок `env:` за допомогою `4dd`
Insert	`i`, `a`, `o`, `O`	Набирати текст у файл	Додати `image: nginx:1.25` під контейнером
Command	`:` з режиму Normal	Зберегти, вийти, шукати, замінити, налаштувати vim	Виконати `:%s/nginx:old/nginx:1.25/g`

Зупиніться й передбачте: ви натискаєте j, очікуючи, що курсор переміститься вниз, але літера j з’являється всередині metadata.name. У якому ви режимі, що слід натиснути й що перевірити, перш ніж продовжувати?

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

1.1 Команди, які варто запам’ятати

Більшість завдань CKA з редагування можна виконати компактним набором команд. Мета — не стати швидким у кожній можливості vim. Мета — стати надійним у діях, які прямо відображаються на роботу з маніфестами Kubernetes: вставити поле, видалити блок, скопіювати блок, скоригувати відступ, знайти значення, зберегти й перевірити.

ENTERING INSERT MODE
i        Insert before the cursor
a        Insert after the cursor
o        Open a new line below and enter Insert mode
O        Open a new line above and enter Insert mode

NAVIGATION IN NORMAL MODE
h        Move left
j        Move down
k        Move up
l        Move right
gg       Go to the first line
G        Go to the last line
0        Go to the beginning of the current line
$        Go to the end of the current line
w        Jump forward one word
b        Jump backward one word

EDITING IN NORMAL MODE
x        Delete the character under the cursor
dd       Delete the current line
5dd      Delete five lines starting at the current line
yy       Copy the current line
p        Paste below the current line
P        Paste above the current line
u        Undo the last change
Ctrl+r   Redo the undone change

YAML BLOCK EDITING
>>       Indent the current line one level to the right
<<       Indent the current line one level to the left
V        Start visual line selection
>        Indent the selected lines right
<        Indent the selected lines left
=        Reindent the selected lines using vim's indentation rules

SEARCH AND REPLACE
/pattern            Search forward for pattern
n                   Move to the next match
N                   Move to the previous match
:%s/old/new/g       Replace old with new throughout the file

SAVE AND QUIT
:w       Save the file
:q       Quit if there are no unsaved changes
:wq      Save and quit
:q!      Quit and discard unsaved changes

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

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

1.2 Як команди vim відображаються на структуру YAML

YAML для Kubernetes ієрархічний. Значення рядка залежить від того, наскільки він має відступ відносно сусідніх рядків. Орієнтовані на рядки команди vim добре пасують до цієї структури, бо часто потрібно перемістити чи видалити цілі записи YAML, а не окремі символи. Елемент контейнера, елемент змінної середовища, елемент порту й рядок мітки кожен займають передбачувані блоки рядків.

apiVersion: v1
kind: Pod
metadata:
  name: web
  labels:
    app: frontend
spec:
  containers:
  - name: app
    image: nginx:1.25
    ports:
    - containerPort: 80

У цьому маніфесті видалення лише image: nginx:1.25 залишає контейнер з ім’ям, але без образу, що Kubernetes відхиляє. Видалення цілого елемента контейнера вимагало б видалити рядки - name, image, ports та containerPort разом. Ось чому виділення рядків та порахований delete — це не дрібниці редактора; це те, як ви зберігаєте чи видаляєте повну структуру Kubernetes.

metadata:
  name: web              <- child of metadata
  labels:                <- child of metadata
    app: frontend        <- child of labels
spec:
  containers:            <- child of spec
  - name: app            <- list item under containers
    image: nginx:1.25    <- field in the same container item

Корисна ментальна перевірка — запитати: «Який батьківський елемент володіє цим рядком?» Якщо відповідь несподівано змінюється після редагування, структура YAML змінилася. Переміщення image ліворуч чи праворуч на два пробіли може винести його за межі елемента контейнера або вкласти в інший батьківський елемент. Vim полегшує це переміщення за допомогою >> та <<, але учень усе одно мусить розуміти, що означає відступ.

Зупиніться й вирішіть: у наведеному вище маніфесті, що станеться, якщо image: nginx:1.25 зсунути ліворуч так, щоб він вирівнявся з - name: app? Чи описуватиме це поле образу для контейнера, чи стане іншою структурою?

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

Частина 2: Налаштуйте vim для YAML Kubernetes

Типова інсталяція vim придатна для використання, але не завжди дружня до YAML. YAML трактує табуляції інакше, ніж пробіли, приклади Kubernetes зазвичай використовують відступ у два пробіли, а помилки перевірки часто містять посилання на рядки. Невеликий .vimrc перетворює ці клопоти на значення за замовчуванням, тож кожне редагування починається з безпечнішої відправної точки.

Виконайте цю команду в оболонці, щоб створити сфокусовану конфігурацію vim. Команда придатна для запуску в наведеному вигляді й використовує heredoc у лапках, щоб оболонка не розгортала нічого всередині файлу.

cat << 'EOF' > ~/.vimrc
" Kubernetes YAML editing defaults
set number
set tabstop=2
set softtabstop=2
set shiftwidth=2
set expandtab
set autoindent
set smartindent
set cursorline
set hlsearch
syntax on

" Make hidden whitespace easier to inspect when needed.
set listchars=tab:>-,trail:.,extends:>,precedes:<

" YAML files should always use spaces and two-space indentation.
autocmd FileType yaml setlocal tabstop=2 softtabstop=2 shiftwidth=2 expandtab
autocmd FileType yml setlocal tabstop=2 softtabstop=2 shiftwidth=2 expandtab
EOF

Ця конфігурація не перетворює vim на інтегроване середовище розробки. Вона робить невидимі частини YAML менш ризикованими. set number дає вам систему координат для помилок парсера. set expandtab означає, що натискання клавіші Tab вставляє пробіли замість символу табуляції. set shiftwidth=2 означає, що команди відступу на кшталт >> та < зсувають на ту саму ширину, яку очікують приклади Kubernetes.

Налаштування	Чому це важливо для YAML	Збій, який воно запобігає
`set number`	Показує номери рядків поруч із файлом	Сліпий пошук місць помилок парсера
`set tabstop=2`	Відображає ширину табуляції як два стовпці	Неправильне прочитання візуального вирівнювання під час перевірки
`set softtabstop=2`	Робить Tab і Backspace схожими на кроки в два пробіли	Незграбні часткові правки відступу
`set shiftwidth=2`	Робить так, що `>>`, `<<` та візуальний відступ зсувають на два пробіли	Надмірний відступ блоків великими стрибками
`set expandtab`	Перетворює натискання клавіші Tab на пробіли	Символи табуляції, що ламають відступ YAML
`set autoindent`	Переносить поточний відступ на нові рядки	Перебудова вкладеного відступу з нуля
`set cursorline`	Підсвічує поточний рядок	Редагування не того рядка в щільних маніфестах
`set hlsearch`	Підсвічує збіги пошуку	Пропуск повторюваних значень образу чи мітки

Зупиніться й поясніть: чому tabstop=2 сам по собі недостатній? Передбачте, що станеться, якщо файл містить справжній символ табуляції, а інша машина відображає табуляції з іншою шириною.

tabstop=2 лише змінює те, як відображається табуляція. Він не заважає vim вставити символ табуляції, якщо також не ввімкнено expandtab. YAML дбає про фактичні символи, а не про ваші візуальні вподобання, тож маніфест може виглядати вирівняним в одному терміналі й зазнати збою чи ввести вас в оману в іншому. expandtab змінює те, що записується у файл, а саме цю поведінку бачить перевірка Kubernetes.

2.1 Перевірте конфігурацію, а не довіряйте їй

Робочий процес сеньйора перевіряє припущення. Після запису .vimrc відкрийте чорновий YAML-файл, натисніть Tab на початку рядка, збережіть і огляньте файл інструментами, які виявляють приховані символи. Ця коротка перевірка доводить, що ваш редактор записує пробіли, а не просто відображає щось, що схоже на пробіли.

cat << 'EOF' > vimrc-check.yaml
apiVersion: v1
kind: Pod
metadata:
  name: vimrc-check
spec:
  containers:
  - name: app
    image: nginx:1.25
EOF

vim vimrc-check.yaml
cat -A vimrc-check.yaml
rm -f vimrc-check.yaml

У виводі cat -A символи табуляції зазвичай з’являються як ^I. Якщо ви бачите ^I усередині відступу, замініть табуляції чи виправте налаштування редактора, перш ніж починати серйозну роботу з YAML. Якщо ви бачите $ наприкінці рядків, це нормально; cat -A використовує його, щоб показати, де закінчується кожен рядок.

Існує також метод перевірки на боці vim. Усередині vim виконайте :set list, щоб показати табуляції та кінцеві пробіли за допомогою конфігурації listchars. Виконайте :set nolist, коли завершите огляд. Це корисно, коли маніфест виглядає нормально у звичайному вигляді, але перевірка постійно вказує на ділянки, чутливі до пробільних символів.

2.2 Компроміс режиму вставлення

Старі налаштування vim у терміналі можуть неправильно обробляти вставлені блоки, коли активний autoindent. Режим вставлення тимчасово вимикає деяке автоматичне форматування, тож vim приймає вставлений текст буквальніше. Компроміс полягає в тому, що режим вставлення також вимикає деяку корисну поведінку вставляння, тож його слід вимикати після вставлення.

:set paste

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

:set nopaste

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

Підтримка дужкового вставлення (bracketed paste) у сучасних терміналах часто зменшує цю проблему, але безпечний для іспиту принцип залишається тим самим: після будь-якого вставленого YAML перевіряйте результат. Вставлені маніфести можуть містити табуляції, нерозривні пробіли, довгі перенесені рядки чи поля з іншої версії API. Безпека редактора зменшує ризик; перевірка через kubectl підтверджує об’єкт.

Частина 3: Створюйте, редагуйте й перевіряйте маніфест у тісному циклі

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

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

kubectl version --client

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

3.1 Приклад: додайте мітку й перевірте Pod

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

cat << 'EOF' > pod-edit.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-edit
spec:
  containers:
  - name: app
    image: nginx:1.25
EOF

kubectl apply -f pod-edit.yaml --dry-run=client

Тепер відкрийте файл у vim і ставтеся до першої правки як до контрольованого експерименту, а не до вільного набирання. Файл дійсний, перш ніж ви його торкнетеся, тож будь-який збій перевірки після наступного збереження має вказувати прямо на блок мітки, який ви щойно додали.

vim pod-edit.yaml

Натисніть Esc, щоб переконатися, що ви в режимі Normal, потім перейдіть до рядка metadata:. Натисніть o, щоб відкрити новий рядок під ним і увійти в режим Insert. Наберіть блок мітки нижче, зберігаючи відступ у два пробіли під metadata та чотири пробіли під labels.

  labels:
    app: web

Натисніть Esc, наберіть :wq і натисніть Enter, потім знову перевірте файл, перш ніж вносити будь-які інші зміни. Негайний крок перевірки — це те, що перетворює редагування у vim на інженерний цикл: одна зміна, одна перевірка, один чіткий результат.

kubectl apply -f pod-edit.yaml --dry-run=client

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

3.2 Приклад: відновлення після поганої правки відступу

Тепер навмисно створіть зламану версію. Така навмисна поломка корисна, бо дає змогу практикувати шлях відновлення до того, як іспит створить для вас тиск.

cat << 'EOF' > broken-pod-edit.yaml
apiVersion: v1
kind: Pod
metadata:
  name: broken-pod-edit
labels:
    app: web
spec:
  containers:
  - name: app
    image: nginx:1.25
EOF

kubectl apply -f broken-pod-edit.yaml --dry-run=client

Цей файл може розібратися як YAML, але він не описує задуманий об’єкт Kubernetes. Поле labels вирівняне на верхньому рівні, замість того щоб перебувати під metadata. Kubernetes очікує мітки під metadata.labels, тож виправлення структурне: зсуньте labels: на два пробіли праворуч, а також app: web, щоб воно залишилося дочірнім елементом labels.

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

vim broken-pod-edit.yaml

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

Натисніть Esc, щоб увійти в режим Normal.
Перейдіть до рядка labels:.
Натисніть V, щоб виділити поточний рядок.
Натисніть j один раз, щоб включити app: web.
Натисніть > один раз, щоб зробити відступ обох виділених рядків на shiftwidth, який ваш .vimrc встановив на два пробіли.
Натисніть Esc, наберіть :wq і натисніть Enter.

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

kubectl apply -f broken-pod-edit.yaml --dry-run=client
rm -f pod-edit.yaml broken-pod-edit.yaml

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

3.3 Матриця рішень для редагування

Не кожне завдання заслуговує на той самий підхід до редагування. На іспиті з обмеженим часом правильний інструмент — це той, що безпечно дає бажаний маніфест із найменшим когнітивним навантаженням. Vim чудовий для зміни наявних файлів та виправлення структури. Перенаправлення в оболонці часто швидше для створення крихітного файлу з нуля. kubectl create чи kubectl run з --dry-run=client -o yaml може згенерувати правильний каркас швидше, ніж пам’ять.

Ситуація	Найкращий стартовий інструмент	Чому це зазвичай найшвидше
Створити простий Pod з нуля	`kubectl run ... --dry-run=client -o yaml`	Kubernetes генерує дійсну структуру та поля API
Редагувати наявний маніфест	`vim file.yaml`	Ви можете зберегти більшу частину структури й змінити лише цільові поля
Вставити довгий фрагмент документації	`vim` із дисципліною вставлення чи heredoc	Ви можете оглянути й перевірити після вставлення
Замінити повторювані теги образів	пошук і заміна у vim	Одна команда послідовно змінює кожне повторюване значення
Видалити зламаний блок YAML	візуальне виділення чи порахований delete у vim	Орієнтовані на рядки правки відповідають блоковій структурі YAML
Створити короткий чорновий файл	`cat << 'EOF' > file.yaml`	Уникає накладних витрат редактора для невеликого відомого вмісту

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

Частина 4: Рефакторте блоки YAML без повторного набирання

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

Ключ — копіювати повний семантичний блок. Копіювання лише частини елемента списку створює зламану структуру. Копіювання забагато може продублювати поля, які мають залишатися унікальними. Перш ніж натиснути yy, V чи p, визначте найменший повний блок, який представляє ту частину об’єкта Kubernetes, яку ви хочете продублювати.

env:
- name: LOG_LEVEL
  value: info
- name: FEATURE_FLAG
  value: "true"

У прикладі вище кожен елемент змінної середовища займає два рядки. Копіювання лише - name: FEATURE_FLAG створює змінну без значення. Копіювання лише value: "true" створює значення без імені. Копіювання обох рядків зберігає елемент списку, і тоді ви можете відредагувати продубльоване ім’я та значення.

4.1 Дублювання блоку контейнера

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

cat << 'EOF' > multi-container-edit.yaml
apiVersion: v1
kind: Pod
metadata:
  name: multi-container-edit
spec:
  containers:
  - name: app
    image: nginx:1.25
    ports:
    - containerPort: 80
EOF

Відкрийте файл і визначте повний елемент контейнера, перш ніж щось копіювати. Корисний блок починається з - name: app і включає кожне дочірнє поле, яке має подорожувати разом із цим контейнером.

vim multi-container-edit.yaml

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

Натисніть Esc.
Перейдіть до рядка - name: app.
Натисніть V, щоб почати візуальне виділення рядків.
Натисніть j тричі, щоб включити image, ports та containerPort.
Натисніть y, щоб скопіювати (yank) виділений блок.
Перейдіть до рядка - containerPort: 80.
Натисніть p, щоб вставити скопійований блок нижче.
Відредагуйте вставлений блок так, щоб другий контейнер мав ім’я sidecar і використовував busybox:1.36.
Видаліть скопійовані рядки ports із sidecar’а за допомогою 2dd.
Збережіть за допомогою :wq.

Очікуваний результат — це Pod з двома записами під тим самим списком containers:. Зверніть увагу, що другий - name вирівнюється з першим, тоді як image залишається з відступом як дочірнє поле контейнера sidecar.

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-edit
spec:
  containers:
  - name: app
    image: nginx:1.25
    ports:
    - containerPort: 80
  - name: sidecar
    image: busybox:1.36

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

kubectl apply -f multi-container-edit.yaml --dry-run=client
rm -f multi-container-edit.yaml

Контрольна точка активного навчання: перш ніж перевіряти, передбачте, чи потрібне sidecar’у власне поле ports. Поясніть свої міркування з точки зору схеми Pod, а не команди редактора, яку ви використали.

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

4.2 Пошук і заміна без побічної шкоди

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

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

cat << 'EOF' > version-replace.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: version-replace
spec:
  replicas: 2
  selector:
    matchLabels:
      app: version-replace
  template:
    metadata:
      labels:
        app: version-replace
    spec:
      containers:
      - name: web
        image: nginx:1.25
      - name: metrics
        image: busybox:1.36
        command: ["sh", "-c", "sleep 3600"]
EOF

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

vim version-replace.yaml

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

/image:

Натискайте n, щоб рухатися рядками образів. Якщо завдання — змінити лише тег образу nginx, широкий шаблон :%s/1.25/1.26/g може бути прийнятним у цьому файлі, але :%s/nginx:1.25/nginx:1.26/g безпечніший, бо прив’язує заміну до імені образу. У більших маніфестах така додаткова конкретність запобігає випадковим правкам незв’язаних полів версій.

:%s/nginx:1.25/nginx:1.26/g

Збережіть, перевірте й приберіть після перевірки заміни звичайною командою оболонки. Крок перевірки перехоплює помилки YAML та схеми, тоді як перевірка через grep перехоплює помилку наміру — зміну забагато чи замало.

kubectl apply -f version-replace.yaml --dry-run=client
grep "nginx:1.26" version-replace.yaml
rm -f version-replace.yaml

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

4.3 Видаляйте блоки за структурою, а не з паніки

Видалення блоку поширене, коли видаляють неправильний розділ volumeMount, env, resources чи ports. Помилка — гатити Delete чи Backspace у режимі Insert, доки файл «не виглядатиме краще». Такий підхід часто залишає осиротілі елементи списку чи поля під неправильним батьківським елементом. Vim дає вам чистіші варіанти.

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

cat << 'EOF' > delete-block.yaml
apiVersion: v1
kind: Pod
metadata:
  name: delete-block
spec:
  containers:
  - name: app
    image: nginx:1.25
    env:
    - name: KEEP_ME
      value: stable
    - name: REMOVE_ME
      value: temporary
EOF

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

vim delete-block.yaml

Блок для видалення — це рівно два рядки: - name: REMOVE_ME та value: temporary. Перейдіть до рядка - name: REMOVE_ME, натисніть Esc і наберіть:

2dd

Збережіть і перевірте, щойно дворядковий елемент зник, потім огляньте решту списку env:, якщо перевірка повідомить про сусідню проблему. Чисте видалення має залишити KEEP_ME як повний елемент списку й не має залишати позаду висяче поле value.

kubectl apply -f delete-block.yaml --dry-run=client
rm -f delete-block.yaml

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

Частина 5: Діагностуйте збої YAML як оператор

Збій YAML може походити з трьох різних рівнів. Файл може бути недійсним YAML, тобто парсер не може його прочитати. Файл може бути дійсним YAML, але недійсним Kubernetes, тобто об’єкт не відповідає схемі API. Об’єкт може бути дійсним Kubernetes, але неправильним для вашого наміру, тобто він успішно застосовується, але не робить того, що вимагає завдання.

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

+----------------------+     +------------------------+     +----------------------+
| YAML PARSER          | --> | KUBERNETES SCHEMA      | --> | OPERATOR INTENT      |
| Can the file be read?|     | Is this object valid?  |     | Is this the right    |
| spaces, colons, tabs |     | fields, types, apiVersion |  | behavior for task?  |
+----------------------+     +------------------------+     +----------------------+

Корисний цикл усунення несправностей — почати з найдешевшої перевірки. Збережіть файл. Виконайте dry-run на боці клієнта. Уважно прочитайте першу помилку. Відкрийте файл на вказаному рядку, якщо такий надано. Виправте одну причину. Збережіть і знову виконайте dry-run. Повторення цього циклу краще за кілька спекулятивних змін, бо кожен запуск перевірки дає вам менший, чіткіший фрагмент проблеми.

kubectl apply -f some-file.yaml --dry-run=client

5.1 Помилка парсера: приховані табуляції

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

printf 'apiVersion: v1\nkind: Pod\nmetadata:\n\tname: tab-pod\nspec:\n\tcontainers:\n\t- name: app\n\t  image: nginx:1.25\n' > tabs-pod.yaml

cat tabs-pod.yaml
cat -A tabs-pod.yaml
kubectl apply -f tabs-pod.yaml --dry-run=client

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

vim tabs-pod.yaml

Усередині vim замініть табуляції двома пробілами, потім перегляньте зачеплений блок перед збереженням. Механічна заміна табуляцій зазвичай правильна для цього невеликого прикладу, але більші файли все ще можуть потребувати огляду батьківсько-дочірньої структури згодом, бо табуляції могли представляти різні візуальні ширини.

:%s/\t/  /g

Збережіть, перевірте й видаляйте файл лише після того, як перевірки парсера й схеми погодяться з виправленою структурою. Якщо перевірка все ще скаржиться, використовуйте номери рядків та :set list, щоб оглянути найменшу ділянку навколо повідомленої помилки.

kubectl apply -f tabs-pod.yaml --dry-run=client
rm -f tabs-pod.yaml

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

5.2 Помилка схеми: правильний YAML, неправильна форма поля

Файл може бути цілком дійсним YAML і все одно не пройти перевірку Kubernetes. Це трапляється, коли структура читабельна, але об’єкт не відповідає API Kubernetes. Для роботи з CKA це поширене, коли елементи списку розміщені під неправильним батьківським елементом, рядки використовуються там, де очікуються цілі числа, або поле належить template.spec, але розміщене під верхньорівневим spec Deployment’а.

Створіть приклад із неправильним типом containerPort, щоб практикувати відокремлення дійсності YAML від дійсності API Kubernetes. Файл навмисно читабельний як YAML, тож цікавий збій походить від схеми, яка очікує ціле число за цим шляхом поля.

cat << 'EOF' > schema-error.yaml
apiVersion: v1
kind: Pod
metadata:
  name: schema-error
spec:
  containers:
  - name: app
    image: nginx:1.25
    ports:
    - containerPort: "80"
EOF

kubectl apply -f schema-error.yaml --dry-run=client

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

vim schema-error.yaml

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

    ports:
    - containerPort: 80

Перевірте й приберіть після виправлення типу, щоб вправа завершилася підтверджено справним файлом, а не файлом, який припускають справним. Ця звичка важлива під час CKA, бо пізніше завдання може ґрунтуватися на маніфесті, який ви відредагували кілька хвилин тому.

kubectl apply -f schema-error.yaml --dry-run=client
rm -f schema-error.yaml

Урок не в тому, що лапки завжди погані. Багато полів Kubernetes є рядками й мають бути взяті в лапки, коли значення схожі на булеві значення, числа чи URL. Урок у тому, що схема Kubernetes визначає очікуваний тип. containerPort є цілим числом; значення value змінної середовища є рядком. Хороше редагування означає знати, коли синтаксис YAML та схема Kubernetes є окремими питаннями.

5.3 Помилка наміру: дійсний об’єкт, неправильне розташування

Помилки наміру найтонші, бо перевірка може пройти. Припустімо, завдання просить вас додати мітку до шаблону Pod у Deployment, але ви додаєте її лише до метаданих об’єкта Deployment. YAML дійсний, об’єкт Kubernetes дійсний, і команда може виконатися успішно, але селектор ReplicaSet чи мітки Pod можуть не поводитися як вимагалося.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: label-location
  labels:
    app: web
spec:
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
        tier: frontend
    spec:
      containers:
      - name: web
        image: nginx:1.25

metadata.labels угорі описують об’єкт Deployment. Блок spec.template.metadata.labels описує Pod’и, створені Deployment’ом. Редагування неправильного блоку мітки може залишити поведінку застосунку незмінною, навіть якщо маніфест застосовується. Коли завдання згадують Pod’и, створені Deployment’ом, вибір сервісу чи поведінку розгортання, огляньте блок шаблону перед редагуванням.

Що сталося б, якби ви змінили лише верхньорівневий metadata.labels.app на api, але залишили spec.selector.matchLabels.app та spec.template.metadata.labels.app як web? Чи створював би Deployment усе ще Pod’и, які вибираються його власним селектором?

Deployment міг би залишитися структурно дійсним, бо мітка об’єкта верхнього рівня незалежна від зв’язку селектора Pod’а. Pod’и все одно вибиралися б на основі селектора та міток шаблону, обидва з яких залишаються web. Це класична дійсна-але-неправильна правка: поле змінилося, але не те поле, яке контролювало потрібну поведінку.

Частина 6: Патерни редагування на швидкості іспиту

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

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

kubectl run generated-web --image=nginx:1.25 --dry-run=client -o yaml > generated-web.yaml
vim generated-web.yaml
kubectl apply -f generated-web.yaml --dry-run=client
rm -f generated-web.yaml

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

kubectl apply -f broken.yaml --dry-run=client
vim broken.yaml
kubectl apply -f broken.yaml --dry-run=client

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

/nginx
:%s/nginx:1.25/nginx:1.26/g

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

Esc
u
:set paste

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

:set nopaste
:w

6.1 Nano як дійсний запасний варіант

Nano — це дійсний редактор для CKA, якщо він доступний і ви швидші з ним. Мета — не довести вищість vim. Мета — створити правильні маніфести під тиском часу. Видима панель скорочень nano може зменшити плутанину режимів, але операції режиму Normal у vim швидші для блокових правок, щойно їх опановано.

Створіть мінімальну конфігурацію nano, якщо nano — ваш обраний запасний варіант, і тримайте її на тих самих стандартах YAML, що й vim. Простіший інтерфейс редактора не усуває потреби в пробілах, номерах рядків, перевірці та свідомому огляді батьківсько-дочірньої структури.

cat << 'EOF' > ~/.nanorc
set tabsize 2
set tabstospaces
set autoindent
set linenumbers
EOF

Основи nano прості: Ctrl+O записує файл, Enter підтверджує ім’я файлу, а Ctrl+X виходить. Ctrl+K вирізає рядок, а Ctrl+U вставляє його. Якщо ви обираєте nano для іспиту, практикуйте той самий цикл «редагуй–перевір». Вибір редактора змінює натискання клавіш; він не змінює структуру YAML, схему Kubernetes чи потребу перевіряти.

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

Чи знали ви?

Vim часто наявний у мінімальних системах Linux, бо він малий, нативний для терміналу й корисний через SSH. Це робить навичку переносною за межі іспиту CKA, особливо під час сесій усунення несправностей у промисловому середовищі, де графічні інструменти недоступні.
Відступ YAML семантичний, а не косметичний. Переміщення рядка на два пробіли може змінити те, який батьківський елемент володіє цим полем, навіть коли файл усе ще успішно розбирається.
vimtutor — це інтерактивний інструмент для практики, що встановлюється з багатьма пакетами vim. Запуск vimtutor на півгодини навчає рухам, редагуванню, скасуванню, пошуку та звичкам збереження в керованому середовищі.
Dry-run на боці клієнта — це супутник редагування. kubectl apply --dry-run=client -f file.yaml може перехопити багато помилок синтаксису та схеми, перш ніж ви витратите час на застосування зламаного об’єкта до кластера.

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

Помилка	Чому це трапляється	Як це виправити
Набирання команд, перебуваючи ще в режимі Insert	`:wq`, `dd` чи текст пошуку з’являється всередині файлу YAML	Спершу натисніть `Esc`, потім виконайте команду з режиму Normal
Довіра до візуального вирівнювання за наявності табуляцій	Файл виглядає вирівняним, але перевірка YAML чи Kubernetes зазнає збою	Використовуйте `set expandtab`, оглядайте за допомогою `cat -A` чи обережно виконуйте `:%s/\t/ /g`
Вставлення довгого YAML без дисципліни вставлення	Autoindent чи поведінка терміналу можуть створити каскадні зміни відступу	Використовуйте `:set paste`, вставте один раз, виконайте `:set nopaste`, збережіть і перевірте
Заміна широкого шаблону глобально	Мітки, селектори, імена чи незв’язані версії змінюються випадково	Спершу шукайте, використовуйте вузький шаблон заміни, потім огляньте змінені рядки
Видалення часткових блоків YAML	Осиротілі поля залишаються під неправильним батьківським елементом і створюють помилки схеми	Видаляйте повні елементи списку чи блоки полів за допомогою візуального виділення чи порахованих delete
Додавання полів на неправильному рівні об’єкта	Маніфест проходить перевірку, але не змінює задуману поведінку Pod’ів чи робочого навантаження	Визначте батьківський шлях, особливо `metadata` проти `spec.template.metadata`
Пропуск перевірки після невеликої правки	Крихітна помилка відступу чи типу виявляється лише після того, як накопичилося більше змін	Зберігайте й виконуйте `kubectl apply -f file.yaml --dry-run=client` після кожної значущої правки
Залишення ввімкненим режиму вставлення	Звичайне набирання й поведінка відступу здаються неправильними після вставлення	Виконайте `:set nopaste` одразу після того, як вставлений блок на місці

Тест

Сценарій: ваш маніфест Deployment зазнає збою після того, як ви додали змінну середовища. Помилка вказує поблизу блоку `env:`, і ви помічаєте, що нова змінна має `value: true` без лапок. Завдання вимагає, щоб застосунок отримав літеральний рядок `true`. Що вам слід змінити і як би ви перевірили виправлення?

Змініть значення на value: "true", бо значення змінних середовища в Kubernetes є рядками, а взяте без лапок булеве значення YAML може бути інтерпретоване як булеве значення до перевірки схеми. Збережіть файл і виконайте kubectl apply -f deployment.yaml --dry-run=client. Якщо перевірка проходить, огляньте відповідний блок, щоб підтвердити, що ви змінили значення змінної середовища, а не інше поле зі схожим текстом. Ця відповідь працює, бо вона відділяє розбір YAML від правил схеми Kubernetes, а потім підтверджує, що змінилося задумане поле.

Сценарій: ви вставляєте маніфест Pod у vim під час іспиту, і кожен вкладений рядок зсувається далі праворуч, ніж попередній. Ви ще не зберігали. Яка послідовність відновлення мінімізує ризик і чому вона краща за ручне переміщення рядків ліворуч?

Натисніть Esc, потім u, щоб скасувати погане вставлення. Виконайте :set paste, вставте маніфест знову, потім виконайте :set nopaste, збережіть і перевірте за допомогою kubectl apply -f file.yaml --dry-run=client. Це безпечніше за ручне виправлення, бо скасування відновлює останній відомий чистий стан, тоді як ручне зсування багатьох рядків може внести нові батьківсько-дочірні помилки. Міркування операційне: коли файл усе ще незбережений, збереження відомого справного стану буфера швидше за виправлення непевного відступу вручну.

Сценарій: Service не вибирає Pod'и після того, як ви відредагували Deployment. YAML Deployment'а успішно проходить перевірку. Ви змінили `metadata.labels.app` угорі Deployment'а, але не оглянули `spec.template.metadata.labels` чи селектор Service. Що вам слід порівняти і який робочий процес редактора допомагає уникнути пропуску правильного блоку?

Порівняйте селектор Service з мітками шаблону Pod під spec.template.metadata.labels, а не лише з верхньорівневими мітками об’єкта Deployment. У vim шукайте labels: і рухайтеся по кожному збігу за допомогою n, перевіряючи батьківський шлях навколо кожного блоку мітки. Це уникає дійсної-але-неправильної правки, де метадані об’єкта змінюються, але Pod’и все одно несуть стару мітку. Важлива відмінність у тому, що перевірка доводить, що об’єкт прийнятний для API, а не те, що відредагована мітка контролює задуману вами поведінку робочого навантаження.

Сценарій: вам потрібно видалити одну змінну середовища з контейнера. Змінна представлена двома рядками, `- name: DEBUG` та `value: "true"`. Яка команда vim може видалити її ефективно і що вам слід перевірити згодом?

Перейдіть до рядка - name: DEBUG у режимі Normal і наберіть 2dd. Потім перевірте за допомогою kubectl apply -f file.yaml --dry-run=client і огляньте навколишній список env:, щоб підтвердити, що не залишилося осиротілого рядка value. Команда ефективна, бо видаляє повний дворядковий елемент списку, а не символи всередині нього. Якщо зникнуть неправильні рядки, негайно скасуйте за допомогою u, перш ніж намагатися відновити вручну.

Сценарій: ви виконуєте `cat -A pod.yaml` і бачите `^I` перед кількома полями YAML. Файл виглядав вирівняним у vim, але `kubectl` повідомляє про проблему розбору. Яка ймовірна корінна причина і як vim може це виправити?

^I вказує на символи табуляції. Відступ YAML має використовувати пробіли, і візуальне вирівнювання може ввести в оману, коли табуляції відображаються зі зручною шириною. У vim виконайте :%s/\t/ /g, щоб замінити табуляції двома пробілами, потім огляньте структуру й перевірте знову. Для запобігання використовуйте set expandtab, set softtabstop=2 та set shiftwidth=2 у ~/.vimrc, бо ці налаштування змінюють те, що редактор записує, замість того щоб лише змінювати те, як відображається відступ.

Сценарій: завдання просить вас оновити лише образ nginx з `nginx:1.25` на `nginx:1.26`. Той самий файл також містить `busybox:1.25` у sidecar'і. Чому `:%s/1.25/1.26/g` ризиковано і яка команда безпечніша?

Широка команда змінює кожне входження 1.25, зокрема sidecar busybox, якщо він використовує той самий тег. Безпечніша команда — :%s/nginx:1.25/nginx:1.26/g, бо вона прив’язує заміну до точного образу, який згадує завдання. Після збереження шукайте image: чи використовуйте grep, щоб переконатися, що змінився лише задуманий образ. Перевірка Kubernetes не може довести цей намір сама собою, бо обидва теги образів можуть бути синтаксично й структурно дійсними.

Сценарій: ви згенерували маніфест Pod за допомогою `kubectl run --dry-run=client -o yaml`, відкрили його у vim і додали блок `ports`. Перевірка тепер каже, що `containerPort` має неправильний тип. Рядок читається як `containerPort: "80"`. Як ви міркуєте про виправлення?

Файл є читабельним YAML, але схема Kubernetes очікує, що containerPort буде цілим числом, а не рядком. Видаліть лапки, щоб рядок читався як containerPort: 80, збережіть і виконайте kubectl apply -f file.yaml --dry-run=client. Міркування відділяє синтаксис YAML від схеми API Kubernetes: взяті в лапки рядки можуть бути дійсним YAML, водночас залишаючись неправильними для конкретного поля Kubernetes. Та сама логіка пояснює, чому значення змінних середовища часто потребують лапок, навіть якщо номери портів — ні.

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

Завдання: налаштуйте vim, виправте зламаний YAML Kubernetes і практикуйте цикл «редагуй–перевір», доки не зможете вносити структурні зміни без повторного набирання цілих файлів.

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

Крок 1: установіть базову конфігурацію редагування

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

cat << 'EOF' > ~/.vimrc
set number
set tabstop=2
set softtabstop=2
set shiftwidth=2
set expandtab
set autoindent
set smartindent
set cursorline
set hlsearch
syntax on
set listchars=tab:>-,trail:.,extends:>,precedes:<
autocmd FileType yaml setlocal tabstop=2 softtabstop=2 shiftwidth=2 expandtab
autocmd FileType yml setlocal tabstop=2 softtabstop=2 shiftwidth=2 expandtab
EOF

Критерії успіху для цього кроку:

~/.vimrc існує.
Файл містить set expandtab.
Файл містить set shiftwidth=2.
Файл містить set number.

Крок 2: створіть дійсний базовий маніфест

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

cat << 'EOF' > exercise-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: exercise-pod
spec:
  containers:
  - name: app
    image: nginx:1.25
EOF

kubectl apply -f exercise-pod.yaml --dry-run=client

Критерії успіху для цього кроку:

exercise-pod.yaml існує.
kubectl apply -f exercise-pod.yaml --dry-run=client виконується успішно.
Ви можете пояснити, чому перевірка перед редагуванням дає вам чисту базову версію.

Крок 3: додайте мітки метаданих у vim

Відкрийте файл і перейдіть до блоку metadata:, перш ніж набирати будь-який YAML. Ваша мета — додати мітки як дочірні елементи metadata, а не як верхньорівневі поля поруч із ним.

vim exercise-pod.yaml

Додайте цей блок під metadata: з двома пробілами перед labels: та чотирма пробілами перед кожним ключем мітки. Відступ — це урок тут: імена міток мають бути дочірніми елементами labels, а labels має бути дочірнім елементом metadata.

  labels:
    app: exercise
    tier: web

Збережіть і перевірте після правки мітки, щоб вправа перевірила і синтаксис, і форму об’єкта Kubernetes. Якщо dry-run зазнає збою, знову відкрийте саме ділянку міток і порівняйте її відступ із очікуваною батьківсько-дочірньою структурою.

kubectl apply -f exercise-pod.yaml --dry-run=client

Критерії успіху для цього кроку:

labels: має відступ під metadata:.
app та tier мають відступ під labels:.
Dry-run на боці клієнта виконується успішно після правки.
Ви використали Esc та :w чи :wq, а не закрили термінал.

Крок 4: продублюйте й змініть блок YAML

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

vim exercise-pod.yaml

Продублюйте наявний блок контейнера й змініть копію так, щоб Pod мав другий контейнер. Спершу копіювати структуру, а потім редагувати значення швидше за повторне набирання елемента списку, але лише якщо вставлений блок залишається вирівняним із оригінальним рядком - name.

  - name: sidecar
    image: busybox:1.36
    command: ["sh", "-c", "sleep 3600"]

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

kubectl apply -f exercise-pod.yaml --dry-run=client

Критерії успіху для цього кроку зосереджені на належності до списку та володінні полями. Sidecar має бути рівнем із контейнером app, а його поле command має залишатися дочірнім елементом елемента sidecar.

Другий контейнер під тим самим списком containers:, що й перший контейнер.
Sidecar має власний рядок - name.
Команда залишається в одному рядку YAML і проходить перевірку.
Ви скопіювали й змінили структуру, замість того щоб повторно набирати весь маніфест.

Крок 5: виправте маніфест із табуляціями та неправильними типами

Створіть зламаний файл, що поєднує приховані табуляції з проблемою типу схеми. Це дає вам компактну діагностичну вправу, де один інструмент виявляє невидимі символи, а перевірка через kubectl пояснює, чого очікує API Kubernetes.

printf 'apiVersion: v1\nkind: Pod\nmetadata:\n\tname: broken-exercise\nspec:\n\tcontainers:\n\t- name: app\n\t  image: nginx:1.25\n\t  ports:\n\t  - containerPort: "80"\n' > broken-exercise.yaml

cat -A broken-exercise.yaml
kubectl apply -f broken-exercise.yaml --dry-run=client

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

vim broken-exercise.yaml

Виправте файл так, щоб він використовував пробіли для відступу та ціле число для containerPort. Ви можете використати :%s/\t/ /g як частину виправлення, але огляньте отриману структуру перед збереженням. Виправлений файл має виглядати так:

apiVersion: v1
kind: Pod
metadata:
  name: broken-exercise
spec:
  containers:
  - name: app
    image: nginx:1.25
    ports:
    - containerPort: 80

Перевірте виправлення.

kubectl apply -f broken-exercise.yaml --dry-run=client

Критерії успіху для цього кроку вимагають і очищення на рівні байтів, і коректності на рівні схеми. Якщо cat -A усе ще показує ^I, редактор насправді не видалив табуляції, навіть якщо файл виглядає вирівняним на екрані.

cat -A broken-exercise.yaml більше не показує ^I у відступі.
containerPort є цілим числом, а не взятим у лапки рядком.
Dry-run на боці клієнта виконується успішно після виправлення.
Ви можете пояснити, чи був початковий збій на рівні парсера, на рівні схеми чи на обох.

Крок 6: попрактикуйте вузький пошук і заміну

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

cat << 'EOF' > replace-exercise.yaml
apiVersion: v1
kind: Pod
metadata:
  name: replace-exercise
spec:
  containers:
  - name: web
    image: nginx:1.25
  - name: helper
    image: busybox:1.36
    command: ["sh", "-c", "sleep 3600"]
EOF

Відкрийте файл і замініть лише тег nginx на nginx:1.26. Пройдіться пошуком по рядках образів перед заміною, щоб знати, що шаблон описує цільовий образ, а не спільний номер версії.

vim replace-exercise.yaml

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

:%s/nginx:1.25/nginx:1.26/g

Перевірте й огляньте після збереження, бо ці перевірки відповідають на різні питання. Dry-run каже вам, що маніфест прийнятний для Kubernetes, тоді як grep підтверджує, що конкретні рядки образів тепер відповідають завданню.

kubectl apply -f replace-exercise.yaml --dry-run=client
grep "image:" replace-exercise.yaml

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

Образ nginx змінився на nginx:1.26.
Образ busybox не змінився.
Маніфест проходить перевірку після заміни.
Ви шукали чи оглядали рядки образів, перш ніж вважати завдання завершеним.

Крок 7: приберіть практичні файли

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

rm -f exercise-pod.yaml broken-exercise.yaml replace-exercise.yaml

Критерії успіху для цього кроку:

Ви можете створити файл YAML Kubernetes у vim без табуляцій.
Ви можете додати вкладені поля під правильним батьківським елементом.
Ви можете безпечно продублювати й змінити елемент списку.
Ви можете виправити приховані символи табуляції.
Ви можете відрізнити помилки парсера YAML від помилок схеми Kubernetes.
Ви можете використовувати перевірку dry-run після кожної значущої правки.
Ви обрали vim чи nano своїм основним екзаменаційним редактором і попрактикували послідовність збереження/виходу для цього редактора.

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

Вправа 1: дворядкове редагування Pod за дві хвилини

Згенеруйте каркас Pod, додайте мітки й перевірте його як коротку вправу на час. Мета — зробити цикл «генеруй–редагуй–перевіряй» автоматичним, водночас зберігаючи дисципліну перевірки відступу міток, перш ніж ви довіритеся файлу.

kubectl run drill-web --image=nginx:1.25 --dry-run=client -o yaml > drill-web.yaml
vim drill-web.yaml
kubectl apply -f drill-web.yaml --dry-run=client
rm -f drill-web.yaml

Ваша цільова правка — додати app: drill-web та tier: frontend під metadata.labels. Навчальна мета — спочатку не сира швидкість. Навчальна мета — уникнути розміщення міток на неправильному рівні відступу чи плутанини верхньорівневих міток об’єкта з мітками шаблону Pod у пізнішій роботі з Deployment.

Вправа 2: видаліть зламаний блок

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

cat << 'EOF' > drill-delete.yaml
apiVersion: v1
kind: Pod
metadata:
  name: drill-delete
spec:
  containers:
  - name: app
    image: nginx:1.25
    env:
    - name: KEEP
      value: stable
    - name: REMOVE
      value: temporary
EOF

vim drill-delete.yaml
kubectl apply -f drill-delete.yaml --dry-run=client
rm -f drill-delete.yaml

Видаліть лише змінну REMOVE. Використовуйте структурне видалення на кшталт 2dd із рядка - name: REMOVE. Якщо ви видалите забагато, скористайтеся u, перш ніж пробувати будь-що інше.

Вправа 3: виправте батьківсько-дочірній відступ

Створіть маніфест зі зміщеними мітками й свідомо виправте батьківсько-дочірній відступ. Вправа невелика, але та сама помилка з’являється в більших маніфестах Pod та Deployment щоразу, коли мітки додаються на неправильному рівні об’єкта.

cat << 'EOF' > drill-indent.yaml
apiVersion: v1
kind: Pod
metadata:
  name: drill-indent
labels:
    app: misplaced
spec:
  containers:
  - name: app
    image: nginx:1.25
EOF

vim drill-indent.yaml
kubectl apply -f drill-indent.yaml --dry-run=client
rm -f drill-indent.yaml

Перемістіть labels: під metadata: і перемістіть app: misplaced під labels:. Використовуйте візуальне виділення та > чи <, якщо це швидше за ручні пробіли. Перевірте після збереження.

Вправа 4: безпечно замініть один образ

Створіть файл із кількома контейнерами й змініть лише nginx, потім доведіть, що образ helper залишився незмінним. Ця вправа тримає пошук-і-заміну чесним, поєднуючи команду редактора з командою огляду.

cat << 'EOF' > drill-replace.yaml
apiVersion: v1
kind: Pod
metadata:
  name: drill-replace
spec:
  containers:
  - name: web
    image: nginx:1.25
  - name: helper
    image: busybox:1.36
    command: ["sh", "-c", "sleep 3600"]
EOF

vim drill-replace.yaml
grep "image:" drill-replace.yaml
kubectl apply -f drill-replace.yaml --dry-run=client
rm -f drill-replace.yaml

Використовуйте вузький пошук і заміну, щоб лише nginx:1.25 став nginx:1.26. grep після правки є частиною вправи, бо перевірка схеми не може довести, що ви змінили лише задуманий образ.

Вправа 5: запасний варіант nano

Якщо nano — ваш резервний редактор, повторіть Вправу 1 з nano й порівняйте результат зі своєю спробою у vim. Корисний вимір — не те, який редактор здається звичнішим, а те, який допомагає вам створити дійсний YAML із меншою кількістю кроків відновлення.

kubectl run nano-drill --image=nginx:1.25 --dry-run=client -o yaml > nano-drill.yaml
nano nano-drill.yaml
kubectl apply -f nano-drill.yaml --dry-run=client
rm -f nano-drill.yaml

Використовуйте Ctrl+O, Enter та Ctrl+X, щоб зберегти й вийти. Порівнюйте свій рівень помилок, а не лише час. Редактор, який послідовно створює дійсний YAML, є кращим екзаменаційним редактором для вас.

Джерела

https://kubernetes.io/docs/reference/kubectl/generated/kubectl_apply/
https://kubernetes.io/docs/reference/kubectl/generated/kubectl_run/
https://kubernetes.io/docs/reference/kubectl/conventions/
https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
https://kubernetes.io/docs/concepts/workloads/pods/
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/
https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/deployment-v1/
https://yaml.org/spec/1.2.2/
https://vimhelp.org/options.txt.html
https://vimhelp.org/change.txt.html
https://www.nano-editor.org/dist/latest/nanorc.5.html
kubernetes.io: labels — Документація Kubernetes про мітки явно показує мітки, прикріплені в метаданих об’єкта через metadata.labels.
kubernetes.io: kubectl run — Довідка kubectl run явно документує dry-run клієнта та вивід YAML для друку згенерованого об’єкта без його створення.
kubernetes.io: pod v1 — Офіційна довідка API Pod явно типізує ports.containerPort як int32, а env.value як string.
kubernetes.io: deployment — Документація Deployment явно відрізняє .metadata.labels від .spec.template.metadata.labels і стверджує, що .spec.selector має збігатися з мітками шаблону Pod.
github.com: vim — README офіційного репозиторію Vim каже, що vim.tiny використовується багатьма дистрибутивами Linux як стандартний редактор vi і що малий Vim попередньо встановлений на Mac та Linux.
kubernetes.io: kubectl apply — Довідка kubectl apply документує dry-run клієнта як друк об’єкта без його надсилання, а її прапорці перевірки пояснюють поведінку перевірки, що стосується цього робочого процесу.

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

Модуль 0.4: Навігація kubernetes.io — швидкий пошук документації під час іспиту.