Kyverno в Kubernetes: чому політики не спрацьовують
Найчастіше політики формально є: маніфести застосовано, правила описано, звіти збираються. Але частина розгортань проходить повз перевірки, частина падає з незрозумілою помилкою admission-вебхука, а конфігурація кластера між середовищами розходиться дедалі сильніше. Причина майже ніколи не в самих правилах — вона в тому, як налаштовано їх застосування.
Перше джерело — сам admission-вебхук. Якщо для нього вибрано режим, за якого недоступність контролера політик не блокує запит, розгортання в цей момент проходять без перевірки. Туди ж селектори за просторами імен і мітками: під правило потрапляє лише частина робочих навантажень.
А поди, які контролери створюють уже після перевірки, без фонового сканування залишаються поза політиками.
Друге — порядок спрацьовування правил мутації та політик валідації. Мутація змінює об'єкт до валідації, тому перевірка, розрахована на поля, які підставляє інше правило, поводиться інакше, ніж очікувалося.
Відхилені розгортання приходять повідомленням вебхука без імені правила й конкретного поля — за таким текстом причину не відновити.
Третє — керування політиками. Коли правила живуть у репозиторії, а застосовуються вручну, послаблення накопичуються в одному кластері й не доїжджають до іншого: у тестовому середовищі мутація спрацювала, у продуктивному її немає, і валідація відхиляє те, що в тесті проходило.
Контроль конфігурації кластера розвалюється тихо, без явних помилок — далі розбираємо, як це закривається.
Що змінюється після впровадження: вимірювані ефекти
Kyverno вбудовується в момент допуску об'єкта в кластер, тому ефект вимірюється метриками супроводу, а не відчуттями. Нижче — чотири величини, які змінюються в перші тижні після переходу.
Частка змін, що пройшли без ручної правки
Вимога описується один раз: обов'язкові мітки, ліміти ресурсів, заборонені джерела образів. Інженер не звіряє конфігурації очима, а отримує відмову з причиною прямо у виводі команди — частка правок, які повертаються авторові на доопрацювання, падає з десятків до одиниць.
Час перевірки зміни
Розбір конфігурації скорочується з годин до хвилин: рецензент дивиться на сенс зміни, а не на відповідність регламенту. Типові відхилення відсікаються автоматично, ще до потрапляння в основну гілку, тому перевірки перестають бути вузьким місцем релізу.
Клас відмов, який зникає
Окреме джерело збоїв — розходження середовищ: на тестовому контурі правило дотримувалися, на продуктивному забули. Мутація приводить об'єкт до єдиного вигляду під час створення, і вимоги до середовищ стають однаковими за побудовою, а не за домовленістю в документі.
Час відновлення після невірної конфігурації
Якщо некоректна зміна все ж пройшла, генерація залежних об'єктів і явна причина відмови скорочують розбір. Час простою вкладається в хвилини: відкат описується тією самою політикою, що й заборона, а не окремим сценарієм.
Режими застосування правил: аудит, блокування, мутація
Одне й те саме правило в Kyverno описується один раз, а режим визначає, що станеться в разі невідповідності: запис у звіт, відмова у створенні об'єкта або виправлення маніфесту на льоту.
Порядок впровадження — аудит на живому кластері, потім сухий прогін на реальних маніфестах, і лише потім блокування: інакше перше ж суворе правило зупиняє викат.
Мутація й генерація — окрема категорія: вони не відхиляють об'єкт, а приводять його до потрібного вигляду або створюють пов'язані об'єкти. Їх вмикають після того, як аудит показав, чого саме не вистачає ресурсам.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Аудит-режим | Перший прогін на живому кластері: зібрати порушення без зупинки викату | Нічого не забороняє — відхилення продовжують створюватися |
| Сухий прогін | Перевірити нове правило на реальних маніфестах до увімкнення | Не бачить рішень, що залежать від поточного стану кластера |
| Блокувальний режим | Коли порушення розібрано й хибних спрацювань немає | Невалідний маніфест падає цілком — викат зупиняється |
| Мутація ресурсів | Автопідстановка міток, лімітів і безпечних значень за замовчуванням | Змінює вихідний маніфест: розходження з репозиторієм |
| Генерація об'єктів | Потрібні супутні об'єкти: квоти, мережеві політики, доступи | Потребує правил видалення — об'єкти залишаються після зняття мітки |
Усередині одного проходу правила застосовуються послідовно: мутація, потім перевірка, потім генерація. Блокувальне правило тому перевіряє вже виправлений об'єкт.
Етапи впровадження: від розбору кластера до передачі
Порядок робіт будується так, щоб жоден етап не гальмував розробку раніше, ніж ми побачимо реальну картину кластера. Спочатку інвентаризація й проєкт правил, потім м'який прогін, розбір хибних спрацювань і лише потім блокування.
Це знімає головний ризик: політика, увімкнена відразу в жорсткому режимі, зупиняє викатку релізу через один нештатний маніфест.
- Аудит кластера. Інвентаризуємо об'єкти та винятки: привілейовані контейнери, томи хоста, образи без фіксованого тега, контейнери без лімітів. Окремо фіксуємо простори імен і службові навантаження, які чіпати не можна.
- Проєкт набору правил. Розкладаємо знайдене за класами порушень — одне правило на клас, зі зрозумілим текстом відмови. Узгоджуємо, що йде в блокування, а що залишається попередженням.
- Пілот на стенді. Прогоняємо правила Kyverno на копії кластера, розбираємо звіти й правимо формулювання, поки хибні спрацювання не підуть.
- М'який запуск. Вмикаємо набір у режимі аудиту на робочому контурі: дивимося, скільки об'єктів порушує, хто їх створює і чи заважає це викатці.
- Переведення в блокування. Переводимо по одному правилу, починаючи з тих, де звіти чисті. Для успадкованих навантажень — точкові винятки з терміном перегляду.
- Приймання правил. Прогоняємо сценарії обходу: підміна образу, запуск від суперкористувача, відсутність лімітів. Перевіряємо, що правило спрацьовує і не ламає штатні релізи.
- Передача експлуатації. Віддаємо репозиторій із політиками, схему пріоритетів, регламент винятків і порядок оновлення набору.
Політики доступу та комплект документації, що передається
Політики, які ніхто не описував словами, через пів року перетворюються на набір правил, які бояться чіпати: незрозуміло, що перевіряє кожна директива і що станеться при її вимкненні.
Тому разом із налаштованим кластером замовник отримує комплект, де в кожного правила є опис, а в команди — узгоджений порядок роботи з ним.
- Реєстр правил. За кожною політикою зазначено, що вона перевіряє, які ресурси зачіпає, працює в блокувальному режимі чи лише в режимі звіту і чому.
- Ролі й доступи. Правка політик і погодження їх увімкнення розділені між різними людьми; права видаються ролями, а не одним загальним обліковим записом.
- Схема застосування. Шлях правила від репозиторію до кластера: де лежить джерело, як проходить перевірку, у який момент починає діяти і як відкочується.
- Регламент змін. Нове правило спочатку збирає спрацювання в режимі звіту і лише після розбору переводиться в блокувальний — масових зупинок викатів не трапляється.
- Порядок винятків. Як оформити виняток за простором імен або міткою, хто його погоджує і коли він знімається, не вимагаючи правки самого правила.
- Інструкція для чергової зміни. Що робити, якщо правило зупинило викат: як відрізнити хибне спрацювання від реального порушення, де дивитися журнал і в якому порядку знімати блокування.
- Звіти про спрацювання. Налаштоване вивантаження подій за правилами — видно, які перевірки частіше заважають роботі, а які вже час посилювати.
Як в одному кластері прибрали ручні правки конфігурацій
Кластер на кілька десятків сервісів і три середовища — розробка, передпродакшн, продуктив. Будь-яка правка маніфесту йшла через ручне ревю: черговий інженер відкривав diff, звіряв ліміти, мітки, політики безпеки і сховище образів. Розходження між середовищами спливали вже після випуску.
Що було
На ревю надходило 60-80 правок на тиждень, кожна займала від десяти хвилин. До продуктива доходило близько 10% — решта поверталася на доопрацювання після збірки й тестів. Автор не розумів, що саме порушив: формальних правил не було, були домовленості.
Що змінили
Правила перевели в Kyverno. Валідація відхиляє маніфест до застосування: немає лімітів ресурсів, немає мітки власника, плаваючий тег образу, запис у чужий простір імен.
Мутація сама проставляє відсутні поля і приводить середовища до спільного шаблону, генерація створює квоти й мережеві правила разом із застосунком.
Що стало
Відмова приходить протягом хвилини і із зазначенням правила, що спрацювало — раннє відхилення замість розбору постфактум. Ручних перевірок стало менше на порядок, час реакції на помилку скоротився з годин до хвилини.
Повернення за конфігурацією після випуску майже зникли, а розходження між середовищами перестали бути окремою задачею.
Що робити, якщо в кластері вже є свої правила та винятки?
Правила не скасовують уже зроблене — вони стають поряд і поступово заміщають напрацювання.
Починаємо з режиму аудиту: новий набір фіксує порушення, але не блокує розгортання, і відразу видно, де він розходиться з виданими раніше послабленнями і які робочі навантаження зачіпає першими. У блокувальний режим правила переводять по одному і лише після розбору цих розходжень.
Конфлікт правил найчастіше народжується на стику мутації та валідації. Якщо правило спочатку дописує мітку або побічний контейнер, перевірка бачить уже змінений об'єкт і спрацьовує інакше, ніж очікувалося.
Тому цільовий стан описуємо мутацією, а вимоги — валідацією поверх нього, і тримаємо їх разом, щоб порядок застосування був передбачуваним.
Успадкування будуємо згори вниз: базові вимоги живуть на рівні кластера, надбудови — в окремих просторах імен. Виняток, оголошений вище, діє всюди; виняток знизу не повинен тихо знімати вимогу для сусідів, інакше один простір імен послаблює політику всьому кластеру.
Кожен старий виняток переносимо окремим записом із причиною і терміном перегляду, а не загальним обходом перевірок. Те, що не вдається пояснити словами, закривається вимогою — зазвичай це правила, додані колись «на час».
Саморобні перевірки виводимо останніми: поки новий набір в аудиті не покаже збіг із ними на всіх навантаженнях, скрипти залишаються страховкою. Далі їх вимикають по одному, і в кластері залишається одне джерело вимог із зрозумілим порядком застосування.
Технічні сумніви: обмеження та сумісність
Синтаксис правил Kyverno рідко спричиняє складнощі; питання починаються на експлуатації.
Що буде з випуском при недоступності контролера, як не зачепити системні компоненти і що змінювати при оновленні версій — нижче відповідаємо на сумніви, які найчастіше піднімає команда супроводу кластера.
Що буде, якщо контролер політик недоступний?
Кластер працює за вибраним режимом відмови: м'який пропускає запити без перевірки, строгий — відхиляє. Строгий ставимо точково, на критичні правила, з коротким таймаутом і вузькою областю перевірки.
Політики можуть зупинити випуск застосунку?
Перед примусовим увімкненням правило прогоняємо в режимі аудиту: звіти показують, скільки об'єктів його порушать, а випуск при цьому не блокується. Переведення в строгий режим — лише після усунення розходжень.
Як виключити системні компоненти кластера?
Мережу, автомасштабування й сховище виводимо з-під правил через винятки за мітками просторів імен. Інакше одна перевірка здатна зупинити службові контури раніше, ніж прикладні.
Які обмеження в самих правил?
Не все виражається декларативно: міжресурсні залежності та порядок мутацій описуються явно. Генерація створює об'єкти в нових просторах імен — на вже наявні вона не поширюється.
Як проходить оновлення версій?
Правила прив'язані до версії API кластера. Оновлення перевіряємо на тестовому контурі на тому самому наборі маніфестів і переносимо поетапно, зберігаючи сумісність із поточними політиками.
Обговоримо задачу: з чого починається налаштування
Щоб розбір задачі зайняв одну коротку розмову, а не серію уточнень, корисно заздалегідь зібрати кілька вхідних даних.
Нічого екзотичного не потрібно — те, що й так є у вашої команди: доступ до кластера на читання, поточні маніфести політик і опис того, які перевірки вже закриті штатними засобами, а де вони не спрацьовують.
Далі ми проходимо по кластеру й дивимося, які правила валідації, мутації та генерації дадуть реальний ефект, а які конфліктують із наявними робочими навантаженнями.
Повертаємося з оцінкою строків і планом робіт: що робимо першим, які політики вмикаємо в режимі аудиту, які — у блокувальному, і як кожна зміна відкочується.
Що потрібно від замовника для старту:
- Перелік кластерів і середовищ із порядком, у якому їх чіпаємо.
- Доступ на читання до API-сервера й до репозиторію з маніфестами — можна через вашого інженера.
- Поточні політики: що налаштовано вручну, що через admission-контролери, які винятки вже накопичено.
- Болючі точки: які розгортання ламалися через неправильні теги, ліміти або відсутні мітки.
- Вимоги безпеки й аудиту: які перевірки зобов'язані блокувати розгортання, а які достатньо логувати.
- Контакт інженера, який підтвердить рішення щодо політик і прав доступу.
- Обмеження за вікнами змін — коли допустимо увімкнути блокувальний режим у робочому середовищі.
Зі свого боку даємо схему розміщення політик, конфігурації з розділенням за просторами імен, порядок перевірки на тестовому контурі та опис процедури відкату.
Якщо частина вхідних даних поки невідома — це не привід відкладати: почнемо з аудиту поточного стану, а те, чого бракує, закриємо по ходу.
