Стратегія іспиту CNPE та середовище

Напрямок CNPE | Складність: [СЕРЕДНЯ] | Час на проходження: 45–60 хв

Передумови: хаб CNPE, основи Platform Engineering, базові знання GitOps, базові знання спостережуваності

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

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

класифікувати завдання CNPE як задачі GitOps, платформного API, спостережуваності, безпеки чи експлуатації ще до того, як змінювати систему
спроєктувати повторюваний робочий процес сортування, виконання та перевірки для іспиту з платформної інженерії, що базується на практичних завданнях
оцінювати ризик завдання й розподіляти темп роботи між доменами доставки, самообслуговування, спостережуваності, безпеки та експлуатації
впровадити контрольний список середовища іспиту, який зменшує помилки контексту, дрейф команд і прогалини у перевірці
порівнювати джерела доказів, щоб довести, чи відображає бажаний стан саме Git, платформне API чи кластер

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

Гіпотетичний сценарій: ви сідаєте за практичну сесію у стилі CNPE, і перше завдання просить відновити платформний сервіс, який завис після зміни в доставці. Репозиторій показує нещодавнє редагування, контролер GitOps повідомляє про нездоровий застосунок, claim Crossplane не готовий, а в просторі імен з’являється подія політики допуску. Той, хто вчиться, ставиться до завдання як до питання на ерудицію й починає шукати запам’ятовану команду, але платформний інженер читає ситуацію як проблему стану системи: знайти бажаний стан, обрати найменший безпечний важіль і довести, що платформа узгодилася.

Саме тому підготовка до CNPE має відчуватися інакше, ніж пасивне зубріння до сертифікації. CNCF описує CNPE як практичний іспит, що базується на завданнях, для роботи з платформною інженерією, а опубліковані домени охоплюють платформну архітектуру, GitOps і безперервну доставку, платформні API та самообслуговування, спостережуваність і експлуатацію, а також безпеку й застосування політик. На практиці ви готуєтеся не переказувати визначення; ви готуєтеся переходити між рівнями, не втрачаючи нитки. Іспит винагороджує кандидатів, які вміють вирішити, чи є джерелом істини Git, кастомне API, рушій політик, поле статусу контролера чи спостереження за кластером.

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

Аналогія з диспетчерською

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

Читайте завдання як платформний контракт

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

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

Домени CNPE заохочують переходи між рівнями. Завдання з доставки може починатися з редагування репозиторію, продовжуватися синхронізацією Argo CD й завершуватися перевіркою розгортання у Kubernetes. Завдання платформного API може починатися з claim у просторі імен, продовжуватися через композитний ресурс чи статус контролера й завершуватися станом керованого ресурсу. Завдання з експлуатації може починатися з патерну в метриці чи логах, продовжуватися зміною деплойменту чи конфігурації й завершуватися сигналом політики, події чи телеметрії, який доводить, що система повелася інакше.

+----------------------+----------------------+----------------------+
| Prompt clue          | Likely work surface  | Evidence to collect  |
+----------------------+----------------------+----------------------+
| "sync", "promote"    | GitOps repository    | app sync and health  |
| "claim", "self-serve"| platform API or CRD  | ready conditions     |
| "alert", "latency"   | observability stack  | metric, log, trace   |
| "deny", "audit"      | policy controller    | event or report      |
| "access", "role"     | Kubernetes RBAC      | can-i or binding     |
+----------------------+----------------------+----------------------+

Зробіть паузу й передбачте: якщо завдання згадує бажану версію в Git, але в кластері запущено інший образ, якому стану ви довіряєте першим і що доведе, що узгодження відбулося? Відповідь не завжди «негайно редагувати Git». Спершу визначте, чи має застосунок керуватися через GitOps, чи не призупинено й не пошкоджено контролер і чи належить запущене робоче навантаження до того самого бажаного об’єкта. Ця додаткова хвилина вбереже вас від редагування не того шляху в репозиторії чи від боротьби з контролером, який уже пояснює вам, чому він не може застосувати зміну.

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

Існує корисна різниця між «завдання згадує інструмент» і «інструмент є правильним важелем». Завдання може згадувати Deployment лише тому, що Deployment є видимим симптомом, тоді як стійке виправлення живе в Git. Воно може згадувати оповіщення лише тому, що оповіщення — це спосіб, у який помітили збій, тоді як безпечною зміною є селектор сервісу чи виняток у політиці. Привчіть себе питати, який об’єкт має повноваження зберігати бажаний стан істинним після того, як ваші руки покинуть клавіатуру.

Ще одна практична звичка читання завдань — відокремлювати іменники від дієслів. Іменники називають вам об’єкти й домени: застосунок, claim, політика, оповіщення, простір імен, сервіс, роль чи конвеєр. Дієслова називають очікуваний рух: просунути, узгодити, заборонити, аудитувати, відновити, відкотити, забезпечити чи діагностувати. Коли іменники й дієслова вказують на різні рівні, завдання каже вам поєднати рівні, а не сидіти всередині одного інструмента. Саме там виборюється багато балів CNPE.

Підказка домену	Перше питання	Швидкий доказ	Типова пастка
Доставка GitOps	Який шлях у репозиторії володіє бажаним станом?	diff застосунку, статус синхронізації, статус розгортання	редагування живих об’єктів кластера, які Git перезапише
Платформне API	Який кастомний об’єкт є контрактом для користувача?	claim, XR, посилання на ресурси, стани	налагодження лише керованого ресурсу й ігнорування claim
Платформна архітектура / інфраструктура	Який вибір топології, оренди чи розмірів відповідає завданню?	розкладка просторів імен, пули нод, клас сховища, сигнали вартості	патчинг одного навантаження, коли хибним є сам дизайн платформи
Спостережуваність	Який сигнал доводить, що видима користувачу поведінка змінилася?	запит метрики, span трасування, кореляція логів, стан оповіщення	сприймання одного рядка логу як цілого інциденту
Безпека і політика	Правило має аудитувати чи примусово застосовувати?	подія допуску, звіт політики, відхилений запит	зміна політики до підтвердження області збігу
Експлуатація	Який компонент володіє узгодженням?	логи контролера, події, стани статусу	перезапуск компонентів без читання статусу

Побудуйте триетапний робочий процес іспиту

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

Етап один — для очевидних, низькоризикових і легких для перевірки завдань. Приклади: оновлення значення GitOps, коли шлях у репозиторії зрозумілий, огляд CRD чи claim на наявність стану, виправлення простої прив’язки RBAC, корекція області політики або відповідь на діагностичне питання за метрикою чи подією. Ці завдання мають мати короткі цикли зворотного зв’язку. Ви читаєте, дієте, перевіряєте й позначаєте результат, не намагаючись розв’язати кожну суміжну проблему, яку помітили.

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

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

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

git status --short
kubectl config current-context
kubectl get events -A --sort-by=.lastTimestamp | tail -n 10

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

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

Етап	Обирайте завдання, які	Типові приклади	Умова зупинки
Етап 1	очевидні, низькоризикові, швидкі для перевірки	редагування значення, проста область політики, перевірка RBAC, огляд claim	немає зрозумілої наступної дії після початкового огляду
Етап 2	обмежені, але узгоджені	просування, запит на самообслуговування, виправлення правила оповіщення, перевірка розгортання	більше ніж одна непевна залежність
Етап 3	крихкі, широкі чи схильні до збоїв	відкат, проблема кількох контролерів, виняток у політиці, глибокий інцидент	час, що лишився, уже не дозволяє безпечну зміну

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

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

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

Готуйте середовище як практичну лабораторію

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

Почніть із контролю контексту. Знайте, як ви підтверджуватимете активний кластер, простір імен, гілку репозиторію та локальне робоче дерево. Якщо завдання згадує кілька середовищ, використовуйте явні прапорці чи команди, які друкують ціль, замість покладання на пам’ять. Уникайте shell-аліасів, що виконуються, у практичних матеріалах і скриптах, бо аліаси не розкриваються в неінтерактивних оболонках і ховають намір від будь-кого, хто пізніше переглядатиме ваші команди. Багато інженерів використовують особисті скорочення інтерактивно, але підготовка до CNPE має тренувати безпечні для копіювання-вставки команди з повним бінарником kubectl.

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

+------+------------+------------------+-----------------------+--------+
| Task | Domain     | Lever            | Verification          | State  |
+------+------------+------------------+-----------------------+--------+
| 1    | GitOps     | values file      | app health + rollout  | done   |
| 2    | Platform   | claim field      | claim Ready=True      | return |
| 3    | Security   | policy scope     | denied test workload  | open   |
+------+------------+------------------+-----------------------+--------+

Ваші локальні довідники теж мають бути передбачуваними. Швидкий довідник Kubernetes, довідкові сторінки kubectl, посібник користувача Argo CD, документація з композицій Crossplane, концепції сигналів OpenTelemetry та документація контролера політик — усе це цінне, але лише якщо ви можете швидко знайти потрібну сторінку. Під час практики виробіть звичку шукати потрібну концепцію, застосовувати її й закривати цикл. Не перетворюйте кожен пошук на сесію читання.

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

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

kubectl api-resources | grep -E 'claims|composite|applications|policies' || true
kubectl get namespaces
kubectl auth can-i get pods --all-namespaces

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

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

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

Виконуйте зміни через правильне джерело істини

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

Для завдань GitOps ставтеся до Git як до контракту бажаного стану, якщо завдання чітко не каже інакше. Огляньте застосунок, шлях у репозиторії, цільову ревізію, статус синхронізації та здоров’я, перш ніж змінювати маніфести. Argo CD розрізняє бажаний стан і живий стан, і саме ця різниця є причиною, чому GitOps допомагає платформним командам працювати в масштабі. Якщо бажаний стан хибний, виправте Git; якщо бажаний стан правильний, але синхронізація заблокована, огляньте контролер, diff, хуки, хвилі й дозволи.

Для завдань платформного API спершу визначте об’єкт, звернений до користувача. У термінах Crossplane claim може бути в межах простору імен, тоді як композитний ресурс є на рівні кластера, а композиція володіє керованими ресурсами за абстракцією. Це розділення і є суттю платформного API: команди застосунків запитують результат, не керуючи кожною деталлю інфраструктури. У Crossplane v1 (та режимі v2 LegacyCluster) Claim у межах простору імен зіставляється з композитним ресурсом (XR) на рівні кластера; у Crossplane v2 XR за замовчуванням перебуває в межах простору імен, і окремого API Claim немає. Завдання іспиту можуть використовувати будь-яку модель — діагностика все одно тече claim → XR → композиція → посилання на керовані ресурси у v1, або стани XR у межах простору імен у v2. У завданні іспиту налагодження лише хмарного ресурсу чи лише об’єкта Kubernetes може марнувати час, якщо ви пропускаєте зв’язок між claim, композитним ресурсом, композицією та станами керованих ресурсів.

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

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

kubectl get applications.argoproj.io -A
kubectl get claims -A 2>/dev/null || true  # claim plural is per-XRD — substitute your claim CRD plural
kubectl get events -A --sort-by=.lastTimestamp | tail -n 20
kubectl auth can-i create deployments --namespace default

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

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

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

Це особливо важливо для завдань відкату. Відкат у GitOps може означати повернення значення чи ревізії репозиторію, а не видалення Pod’ів, доки випадково не з’явиться стара версія. Відкат у платформному API може означати відновлення параметра claim чи посилання композиції, а не редагування кожного керованого ресурсу по одному. Відкат у політиці може означати відновлення режиму примусового застосування після вікна міграції, а не видалення об’єкта політики цілком. Слово «відкат» описує бажаний результат; важіль визначає власник платформи.

Перевіряйте так, ніби завдання ще не виконане

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

Хороша перевірка є багаторівневою. По-перше, підтвердьте, що зміна існує в джерелі істини. По-друге, підтвердьте, що контролер чи API її прийняли. По-третє, підтвердьте, що результат, звернений до користувача чи оператора, змінився. Ця послідовність запобігає двом протилежним помилкам: оголошенню перемоги після локального редагування файлу й витріщанню на живий кластер без усвідомлення, що бажаний стан так і не змінився. Завдання CNPE часто стають легшими, коли ви пишете шлях перевірки перед редагуванням.

+-------------------+-----------------------+------------------------+
| Source evidence   | Reconcile evidence    | Outcome evidence       |
+-------------------+-----------------------+------------------------+
| Git diff clean    | app Synced/Healthy    | rollout available      |
| claim spec fixed  | XR Ready=True         | managed ref ready      |
| alert rule edited | rule loaded by stack  | alert state expected   |
| policy adjusted   | admission event clear | test object allowed    |
+-------------------+-----------------------+------------------------+

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

Перевірка теж має ціну, тож обирайте докази, достатньо конкретні, щоб не стати дослідницьким проєктом. kubectl get events -A корисне для широкого орієнтування, але завершене завдання зазвичай потребує вужчої перевірки: здоров’я названого застосунку, стану названого claim, розгортання названого деплойменту, названого звіту політики чи названого оповіщення. Широкі перевірки знаходять напрямок; вузькі перевірки доводять завершення.

kubectl get deployment -A
kubectl get pods -A --field-selector=status.phase!=Running
kubectl get events -A --sort-by=.lastTimestamp | tail -n 20
kubectl auth can-i list pods --all-namespaces

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

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

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

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

Відновлюйтеся, коли завдання починає йти не туди

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

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

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

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

Task 4 return note:
Desired: claim Ready=True for team-a cache service.
Seen: claim exists, XR not Ready, composition ref cache-small.
Next check: describe XR and inspect resource refs before editing managed objects.

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

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

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

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

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

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

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

Патерн	Коли використовувати	Чому працює	Міркування щодо масштабування
Цикл читати-діяти-перевіряти	Кожне завдання, особливо завдання змішаних доменів	Він прив’язує кожне редагування до бажаного стану й доказу	Тримайте кожен цикл малим, щоб збої вказували на одне припущення
Спершу джерело істини	Завдання GitOps, платформного API та політики	Він не дає живим виправленням боротися з контролерами	Підтвердьте власність перед редагуванням спільних чи згенерованих об’єктів
Драбина доказів	Завдання асинхронного узгодження та експлуатації	Він розділяє доказ джерела, контролера й результату	Зафіксуйте доказ у чернетці, щоб швидко продовжити
Триетапний темп	Практика з обмеженим часом і повна симуляція іспиту	Він накопичує легкі бали, перш ніж крихка робота поглине увагу	Повертайтеся до пропущених завдань із короткою нотаткою, а не повним перезапуском

Антипатерн	Що йде не так	Чому команди потрапляють у це	Кращий варіант
Живе редагування ресурсів, керованих GitOps	Контролер відкочує зміну чи створює diff, якого ви не очікуєте	Живий об’єкт видимий і відчувається ближчим, ніж репозиторій	Визначте шлях джерела застосунку, відредагуйте Git, потім перевірте синхронізацію та здоров’я
Налагодження керованих ресурсів до платформного API	Ви виправляєте симптом, поки claim чи композиція лишається хибною	Хмарні ресурси чи ресурси навантаження показують конкретні помилки першими	Почніть зі зверненого до користувача claim, простежте посилання, потім огляньте керовані ресурси
Сприймання першого сигналу як кореневої причини	Один лог чи подія заводить вас у неправильну підсистему	Термінові сигнали відчуваються надійнішими за тихі поля статусу	Поєднайте один сигнал джерела з однією перевіркою узгодження чи власності
Послаблення політики, щоб навантаження пройшло	Ви створюєте широкий ризик і можете зламати пізніші завдання з безпеки	Відхилений запит виглядає як перешкода замість зворотного зв’язку	Підтвердьте область збігу, режим і намічений виняток перед зміною примусового застосування

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

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

Каркас прийняття рішень

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

+-----------------------------+
| What changed or failed?      |
+-------------+---------------+
              |
              v
+-----------------------------+
| Is Git the desired state?    |
+------+----------------------+
       | yes
       v
  GitOps path -> sync/health -> rollout proof
       |
       no
       v
+-----------------------------+
| Is there a platform API?     |
+------+----------------------+
       | yes
       v
  claim/XR -> composition refs -> ready proof
       |
       no
       v
+-----------------------------+
| Is the issue operational?    |
+------+----------------------+
       | yes
       v
  signal -> owner -> bounded fix -> signal proof
       |
       no
       v
  policy/RBAC/object scope -> admission or access proof

Каркас навмисно питає про Git до живого редагування кластера, бо GitOps є важливим доменом CNPE і поширеним платформним джерелом істини. Він питає про платформні API до керованих ресурсів, бо абстракції самообслуговування мають ховати деталі реалізації, доки вони не потрібні вам для діагностики. Він питає про експлуатацію й політику останніми, бо ці завдання часто виглядають як загальне налагодження Kubernetes, доки ви не визначите контроль-власник.

Якщо завдання каже	Віддайте перевагу цьому першому важелю	Перевірте за допомогою	Уникайте
”promote”, “sync”, “rollback”	стан репозиторію та застосунок GitOps	diff, синхронізація, здоров’я, розгортання	прямий живий патч без перевірки власності
”self-service”, “claim”, “template”	claim, XR, XRD, композиція	стани й посилання на ресурси	редагування згенерованих ресурсів першими
”alert”, “latency”, “error budget”	запит телеметрії та навантаження-власник	зміни сигналу та стан навантаження	покладання на один рядок логу як доказ
”deny”, “audit”, “policy”	область, режим політики та тестовий об’єкт	результат допуску чи звіт політики	глобальне вимкнення примусового застосування
”permission”, “access”	суб’єкт RBAC, дієслово, ресурс, простір імен	`kubectl auth can-i`	додавання широкого доступу у стилі cluster-admin

Використовуйте каркас прийняття рішень зі смиренням. Якщо докази суперечать вашій першій класифікації, перекласифікуйте завдання замість того, щоб силою тримати початковий план. Завдання, що починається зі збою розгортання, може стати завданням політики, коли події допуску показують відхилені Pod’и. Завдання, що починається з claim, може стати завданням GitOps, коли маніфест claim згенеровано зі шляху в репозиторії. Хороша стратегія не вперта; вона достатньо структурована, щоб швидко змінити напрямок.

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

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

Чи знали ви?

CNPE — це 120-хвилинний онлайн-іспит із наглядом (proctored), що базується на практичних завданнях; вартість становить $445 з однією безкоштовною перездачею, тож керування часом є частиною навички, яку перевіряють, а не дрібницею.
Офіційний план іспиту CNPE зважує п’ять доменів так:

Домен	Вага
Платформна архітектура та інфраструктура	15%
GitOps та безперервна доставка	25%
Платформні API та можливості самообслуговування	25%
Спостережуваність та експлуатація	20%
Безпека та застосування політик	15%

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

Кастомні ресурси Kubernetes розширюють API Kubernetes, тож платформне API, побудоване на CRD, можна оглядати звичайними API-звичками навіть тоді, коли базові ресурси складні.
OpenTelemetry групує телеметрію в сигнали, як-от трасування, метрики та логи (з baggage для контексту між сервісами), що є корисною ментальною моделлю під час вибору доказів для завдань експлуатації.

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

Помилка	Чому це стається	Як виправити
Початок із найважчого завдання	Перше заплутане завдання відчувається терміновим, і кандидати хочуть полегшення, перш ніж рухатися далі	Спершу опрацюйте очевидні низькоризикові завдання, позначте важкі завдання нотаткою про повернення та захистіть час для пізніших етапів
Сліпе редагування	Живий об’єкт видимий, але контролер, шлях у репозиторії чи власник платформного API не визначено	Назвіть бажаний кінцевий стан, джерело істини й команду перевірки перед будь-якою зміною
Сприймання документації як достатньої	Читання створює впізнавання, але CNPE винагороджує згадування, послідовність і доказ під тиском часу	Відрепетируйте повні термінальні робочі процеси й вимагайте, щоб кожне практичне завдання завершувалося доказом
Невстановлення проміжку часу для застряглого завдання	Частково розв’язана проблема створює тиск утрачених витрат і продовжує розростатися	Зупиніться після обмеженого огляду, запишіть наступну корисну перевірку й перейдіть до завдання із зрозумілішим доказом
Пропуск перевірок після зміни	YAML може виглядати правильним, поки узгодження, допуск чи розгортання все ще падає	Перевірте джерело, прийняття контролером і кінцевий результат, перш ніж позначати завдання виконаним
Використання зручного, але нереалістичного налаштування для практики	Знайомі аліаси, простори імен і безкінечний час ховають тертя середовища	Практикуйтеся з явними контекстами, повними командами, чернеткою та перемиканнями доменів за таймером
Надто широке послаблення політики чи доступу	Вузька відмова виглядає як блокувальник, тож кандидати прибирають огорожу замість виправлення області	Підтвердьте режим аудиту чи примусового застосування, умови збігу та намічений виняток перед зміною контролів

Тест

Ваше перше завдання CNPE каже, що сервіс має бути просунутий до staging, і ви бачите і репозиторій Git, і запущений Deployment зі старим образом. Що слід оглянути першим?

A. Запатчити образ Deployment напряму, бо живий об’єкт є найшвидшим важелем. B. Оглянути застосунок GitOps і шлях у репозиторії, що володіє бажаним станом. C. Перезапустити Pod’и, щоб контролер автоматично підтягнув найновіший образ. D. Змінити рушій політик, бо просування образу зазвичай блокується допуском.

Відповідь і пояснення

B — найкращий перший хід, бо мова завдання вказує на просування, що зазвичай належить джерелу істини GitOps. Якщо застосунок володіє Deployment, прямий патч у A може бути відкочений чи створити дрейф, що не задовольняє завдання. C гадає про симптом часу виконання, не довівши, що бажаний образ змінився. D можливе лише тоді, коли докази показують, що допуск блокує просування, тож воно не має бути першим важелем.

Claim платформного API присутній у просторі імен застосунку, але керований ресурс за ним не готовий. Який шлях дослідження найкраще зберігає платформний контракт?

A. Видалити й перестворити керований ресурс, щоб він отримав чистий старт. B. Патчити ресурс, яким володіє провайдер, доки він не повідомить про готовність. C. Оглянути claim, композитний ресурс, посилання на композицію та посилання на ресурси по порядку. D. Проігнорувати claim і шукати в усіх логах контролерів загальні помилки.

Відповідь і пояснення

C — правильно, бо платформні API навмисно розділяють звернений до користувача запит і керовану реалізацію. Стани claim і композитного ресурсу зазвичай пояснюють, чи прийняла платформа запит і де узгодження зазнало невдачі. A і B можуть боротися з контролером і лишити хибний контракт незмінним. D може бути корисним пізніше, але широкий пошук у логах до простеження посилань марнує час і послаблює діагностику.

Під час етапу один завдання виглядає простим, але ви не можете визначити простір імен чи джерело істини після початкового огляду. Що слід зробити?

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

Відповідь і пояснення

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

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

A. Локальний файл змінено, застосунок GitOps синхронізовано й здорово, статус розгортання показує бажані репліки. B. Локальний файл змінено, термінальне запрошення повернулося успішно, ніхто не поскаржився. C. Deployment запатчено наживо, Pod’и перезапущено, репозиторій Git усе ще відрізняється від кластера. D. Події тихі, тож зміна автоматично завершена.

Відповідь і пояснення

A — найсильніший, бо охоплює доказ джерела, доказ узгодження й доказ результату. B доводить лише, що відбулося локальне редагування, і нічого не каже про прийняття платформою. C може створити тимчасовий живий стан, порушуючи власність GitOps. D сприймає відсутність шуму як доказ, але тихі події не доводять бажаного стану чи здоров’я розгортання.

Завдання політики каже, що нові навантаження у просторі імен мають аудитуватися, але не блокуватися. Тестовий Pod відхилено. Яка найкраща перша діагностика?

A. Підтвердити режим політики, область збігу, мітки простору імен і подію чи звіт політики. B. Видалити політику, щоб Pod зміг стартувати й завдання розблокувалося. C. Надати собі ширші дозволи, бо збої допуску зазвичай є проблемами RBAC. D. Патчити Pod повторно, доки одна версія не прослизне крізь допуск.

Відповідь і пояснення

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

Завдання спостережуваності показує оповіщення, що спрацьовує після зміни деплойменту. Який підхід до перевірки найбільш готовий до іспиту?

A. Прочитати один рядок логу застосунку й припустити, що він пояснює оповіщення. B. Поєднати запит чи стан оповіщення зі статусом навантаження-власника й одним релевантним сигналом. C. Вимкнути оповіщення, щоб дашборд став зеленим. D. Перезапустити стек моніторингу, перш ніж перевіряти мітки чи запити.

Відповідь і пояснення

B — найкраще, бо робота зі спостережуваністю потребує доказів, що поєднують сигнал із системою-власником. A може бути корисним, але надто вузьке, щоб довести, що умова оповіщення змінилася. C змінює симптом, а не поведінку платформи. D додає ризик і затримує діагностику до перевірки простіших причин, як-от міток, селекторів чи здоров’я розгортання.

Вам потрібно спроєктувати повторюваний робочий процес сортування, виконання та перевірки для практики CNPE. Який контрольний список дає найкращий сигнал підготовки?

A. Підтвердити контекст кластера, статус репозиторію, формат чернетки, доступ до документації та одну звичку перевірки на домен. B. Встановити багато інструментів і припустити, що середовище іспиту точно відповідатиме вашій робочій станції. C. Практикуватися лише читанням документації, доки кожна команда не стане знайомою. D. Використовувати особисті скорочення команд у кожному скрипті, щоб практика відчувалася швидшою.

Відповідь і пояснення

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

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

Сценарій вправи: побудуйте особистий робочий процес іспиту CNPE, використовуючи три невеликі завдання з цього напрямку чи з вашої власної платформної лабораторії. Оберіть одне завдання GitOps чи доставки, одне завдання платформного API чи самообслуговування й одне завдання спостережуваності, безпеки чи експлуатації. Мета не в тому, щоб створити ідеальне середовище лабораторії; мета в тому, щоб напрактикувати класифікацію, темп і збір доказів, доки ритм не відчуватиметься повторюваним.

Налаштування

Використовуйте кластер чи пісочницю, де ви можете безпечно оглядати ресурси, і використовуйте репозиторій, що містить принаймні один маніфест Kubernetes чи платформи. Якщо у вас не встановлено Argo CD, Crossplane, Kyverno чи Gatekeeper, ви все одно можете виконати вправу, написавши план класифікації та перевірки для цих доменів. Цінність практики йде від вибору джерела істини й доказу, а не від удавання, що кожен інструмент присутній.

git status --short
kubectl config current-context
kubectl get namespaces
kubectl get events -A --sort-by=.lastTimestamp | tail -n 10

Завдання

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

Підказки до розв'язання

Сильне розв’язання має три короткі записи в чернетці, а не довгу розповідь. Для завдання GitOps запис має назвати шлях у репозиторії, застосунок чи контролер і доказ розгортання чи здоров’я. Для завдання платформного API він має назвати claim чи кастомний ресурс, зв’язок, яким володіє контролер і який ви оглянули, та доказ готовності. Для завдання спостережуваності, безпеки чи експлуатації він має назвати сигнал, компонент-власник і доказ, що змінився після вашої дії.

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

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

Приклад чернетки

Task A: GitOps delivery
Desired: staging service uses image tag from prompt.
Lever: edit values file in repo path shown by application source.
Proof: app synced and healthy, deployment rollout complete.

Task B: Platform API
Desired: cache claim Ready=True.
Lever: fix claim parameter after checking XR condition.
Proof: claim and XR ready, resource refs present.

Task C: Security
Desired: namespace audited, not blocked.
Lever: adjust policy mode or namespace selector after confirming event.
Proof: test pod admitted and policy report records audit result.

Джерела

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

Продовжте з Лабораторією GitOps і доставки CNPE, де абстрактний робочий процес стає хронометрованим практичним сценарієм доставки.