Модуль 1.2: Операції та CLI Kyverno

Складність: [СЕРЕДНЯ] — кілька інструментів та операційних концепцій

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

Передумови: KCA README (огляд домену), Kyverno 4.7 (основи архітектури)

Охоплені домени KCA: Домен 2 (Встановлення та конфігурація, 18%) + Домен 3 (CLI, 12%) + Домен 6 (Керування політиками, 10%) = 40% іспиту

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

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

Спроєктувати готове до продакшну встановлення Kyverno з кількома репліками, анти-афінністю Pod’ів, запитами ресурсів, політиками реагування на збої та засобами контролю винятків для кластерів Kubernetes 1.35+.
Перевіряти політики Kyverno перед розгортанням за допомогою kyverno apply, kyverno test та kyverno jp у повторюваному локальному або CI-процесі.
Діагностувати поведінку політик за PolicyReports, ClusterPolicyReports, метриками Prometheus та логами контролера допуску, не вгадуючи, який компонент ухвалив рішення.
Оцінювати, коли застосовувати режим аудиту, режим примусового виконання, фільтри ресурсів, PolicyExceptions або зміни політик під час повсякденних операцій.
Експлуатувати оновлення Kyverno безпечно, перевіряючи сумісність, створюючи резервні копії ресурсів політик, застосовуючи CRD виважено та перевіряючи стан вебхуків після зміни релізу.

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

Гіпотетичний сценарій: ваша платформова команда має надійний набір політик Kyverno, але перше розгортання в продакшні відбувається з однією реплікою Kyverno, без анти-афінності, без набору тестів політик та зі строгою політикою реагування на збій допуску. Робочий вузол виводиться з експлуатації для планового обслуговування, єдиний Под Kyverno на короткий час зникає, і API-сервер Kubernetes починає викликати кінцеву точку вебхука, яка не має готового бекенда. Самі політики можуть бути коректними, проте операційний дизайн перетворив примусове виконання політик на ризик для доступності кластера.

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

Цей модуль навчає операційного рівня, який з’являється в доменах 2, 3 та 6 KCA. Ви працюватимете з командами CLI, що зсувають перевірку політик ліворуч, з об’єктами звітності, які пояснюють те, що сталося всередині кластера, з моделлю винятків, яка тримає обходи вузькими, та з налаштуваннями Helm, які роблять Kyverno стійким за масштабування. Зрештою, провалений тест політики, шумний PolicyReport, тайм-аут вебхука або оновлення CRD виглядатимуть як система, що піддається діагностиці, а не як купа непов’язаних симптомів.

Операційна модель: де ухвалюються рішення Kyverno

Kyverno найлегше експлуатувати, коли ви розділяєте життєвий цикл політики на три місця: до кластера, всередині допуску та після допуску. До кластера CLI Kyverno може оцінювати політики щодо YAML-файлів без звернення до API-сервера. Усередині допуску Kyverno отримує запити admission review від вебхуків Kubernetes і вирішує, чи запит має пройти, провалитися, отримати попередження, бути змінений, згенерувати ресурс чи бути пропущеним. Після допуску фонові контролери та контролери звітності продовжують оцінювати наявні ресурси, щоб дані аудиту не залежали лише від майбутнього API-трафіку.

Це розділення має значення, тому що кожне місце відповідає на інше операційне питання. CLI відповідає: «чи поводитиметься ця політика так, як я очікую, щодо цих маніфестів?» Допуск відповідає: «чи слід дозволити цей живий запит API прямо зараз?» PolicyReports та метрики відповідають: «який тривалий ефект мають ці політики в усьому кластері?» Якщо змішати ці питання докупи, ви потягнетеся не за тим інструментом, коли щось зламається, наприклад, налагоджуватимете офлайн-тест за логами допуску або звинувачуватимете вебхук у результаті фонового сканування.

Іспит KCA часто перевіряє цю відмінність опосередковано. Питання може описувати маніфест, що провалюється в CI, ресурс, який з’являється в PolicyReport, або запит API, заблокований під час розгортання. Правильна відповідь залежить від розпізнавання того, яка частина операційної моделі задіяна. Провал локального тесту вказує на вхідні файли kyverno apply чи kyverno test, запис у звіті вказує на результати оцінки політики, збережені в API PolicyReport, а збій допуску вказує на вебхуки, кінцеві точки сервісу, готовність, репліки та політику реагування на збій.

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

+------------------+      +------------------+      +--------------------+
| Git or CI system | ---> | Kyverno CLI       | ---> | Policy test result |
| manifests        |      | apply/test/jp     |      | before deployment  |
+------------------+      +------------------+      +--------------------+
         |
         v
+------------------+      +------------------+      +--------------------+
| Kubernetes API   | ---> | Kyverno webhooks  | ---> | allow, deny, warn, |
| admission request|      | admission path    |      | mutate, generate   |
+------------------+      +------------------+      +--------------------+
         |
         v
+------------------+      +------------------+      +--------------------+
| Existing cluster | ---> | Background scans  | ---> | PolicyReports and |
| resources        |      | reporting control |      | Prometheus metrics |
+------------------+      +------------------+      +--------------------+

Зробіть паузу й спрогнозуйте: якщо політика проходить kyverno apply щодо локального маніфеста, але те саме робоче навантаження відхиляється під час допуску, які вхідні дані змінилися між двома оцінками? Зазвичай відповідь — контекст допуску, дані простору імен, згенеровані змінні, живий стан кластера або конфігурація вебхука, а не сам текст політики. Звичка прогнозувати наперед тримає налагодження сфокусованим і ощадливим, тому що тести CLI Kyverno є потужними, але вони бачать лише ті файли та змінні, які ви явно їм надаєте, і нічого поза цими межами.

CLI Kyverno: зсуньте тестування політик ліворуч

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

Установіть CLI у спосіб, що пасує вашій робочій станції чи CI-раннеру. Homebrew зручний у macOS та багатьох Linux-середовищах, завантаження бінарників передбачувані в обмежених CI-образах, Docker корисний, коли раннер не може встановлювати пакети, а Krew надає шлях плагіна kubectl kyverno для команд, що вже стандартизувалися на плагінах kubectl. Важливе операційне правило — не метод встановлення; це закріплення відомої версії в автоматизації, щоб результати політик не змінювалися через те, що раннер мовчки підхопив інший реліз CLI.

brew install kyverno

# Download a pinned release. Check https://github.com/kyverno/kyverno/releases for the current version you standardize on.
curl -LO https://github.com/kyverno/kyverno/releases/download/v1.12.0/kyverno-cli_v1.12.0_linux_amd64.tar.gz
tar -xzf kyverno-cli_v1.12.0_linux_amd64.tar.gz
sudo mv kyverno /usr/local/bin/

# Verify the installed binary before using it in automation.
kyverno version

docker run --rm -v "$(pwd):/workspace" ghcr.io/kyverno/kyverno-cli:latest \
  apply /workspace/policy.yaml --resource /workspace/deploy.yaml

kubectl krew install kyverno
kubectl kyverno version

kyverno apply — найпряміша команда офлайн-тестування. Вона читає одну чи кілька політик, читає один чи кілька ресурсів, оцінює правила, що збігаються, і виводить результати pass, fail, warn, error чи skip. Коли команда каже, що хоче «зсунути ліворуч» Kyverno, зазвичай це перша команда, потрібна їй у pull request’ах, тому що вона ловить очевидні порушення політик до того, як вони стануть збоями допуску в спільному кластері.

# Test a single policy against a single resource.
kyverno apply policy.yaml --resource deployment.yaml

# Test a directory of policies against a directory of resources.
kyverno apply policies/ --resource manifests/

# Show detailed results with per-rule context.
kyverno apply policy.yaml --resource deployment.yaml --detailed-results

# Test against resources in a running cluster when kubeconfig is available.
kyverno apply policy.yaml --cluster

# Provide admission-style variables when the policy references request context.
kyverno apply policy.yaml --resource pod.yaml \
  --set request.object.metadata.namespace=production

Коди виходу — частина контракту, тож ставтеся до них так само уважно, як до виведеного результату. Нульовий код виходу означає, що всі оцінені ресурси пройшли згідно з вхідними даними команди. Ненульовий код виходу означає, що принаймні один ресурс провалив оцінку політики або команда не змогла завершити налаштування (некоректний YAML, відсутні файли, нечитабельні шляхи). Kyverno документує семантику кодів виходу для кожного релізу; запустіть kyverno apply --help та довідник CLI для вашої закріпленої версії, перш ніж кодувати CI-бар’єри на конкретних числових кодах.

Перед запуском цього в CI: який результат ви очікуєте, якщо один маніфест навмисно невідповідний, а ваша політика спроєктована, щоб відхиляти його? Відповідь має бути ненульовою задачею, коли ви використовуєте kyverno apply як бар’єр, але успішною задачею, коли ви використовуєте kyverno test і оголошуєте, що невідповідний ресурс має провалитися за очікуванням. Саме ця різниця — причина, чому зрілі команди застосовують обидві команди: apply фільтрує запропоновані робочі навантаження, а test перевіряє передбачену поведінку політики.

name: Kyverno Policy Check
on: [pull_request]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Install Kyverno CLI
      run: |
        curl -LO https://github.com/kyverno/kyverno/releases/download/v1.12.0/kyverno-cli_v1.12.0_linux_amd64.tar.gz
        tar -xzf kyverno-cli_v1.12.0_linux_amd64.tar.gz
        sudo mv kyverno /usr/local/bin/
    - name: Test policies
      run: kyverno apply policies/ --resource k8s-manifests/ --detailed-results

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

tests/
|-- require-labels/
|   |-- policy.yaml
|   |-- resource-pass.yaml
|   |-- resource-fail.yaml
|   `-- kyverno-test.yaml

apiVersion: cli.kyverno.io/v1alpha1
kind: Test
metadata:
  name: require-labels-test
policies:
  - policy.yaml
resources:
  - resource-pass.yaml
  - resource-fail.yaml
results:
  - policy: require-app-label
    rule: check-for-app-label
    resource: good-deployment
    kind: Deployment
    result: pass
  - policy: require-app-label
    rule: check-for-app-label
    resource: bad-deployment
    kind: Deployment
    result: fail

# Run all tests in a directory.
kyverno test tests/

# Run a specific test.
kyverno test tests/require-labels/

# Show detailed output.
kyverno test tests/ --detailed-results

Поле result приймає pass, fail, skip, warn та error, що означає, що набір тестів може документувати передбачену поведінку, а не лише успішний допуск. Це особливо корисно для політик у режимі аудиту, винятків, передумов та правил відмови, де цікава поведінка часто звучить як «цей об’єкт не повинен пройти». Під час рев’ю файл kyverno-test.yaml стає виконуваною документацією політики, тому що кожен очікуваний результат пояснює, що, на думку автора політики, мало статися.

kyverno jp існує, тому що багато політик Kyverno залежать від виразів JMESPath, а помилки JMESPath важко помітити у файлі політики. Передумова може мовчки оцінитися як хибна, змінна може повернути масив там, де ви очікували рядок, або відсутнє поле може перетекти у вираз за замовчуванням. Тестування запиту окремо зменшує цю неоднозначність, перш ніж ви звинуватите блок match, конфігурацію вебхука чи фільтри ресурсів. Пропускайте репрезентативний JSON допуску через kyverno jp query, коли правило використовує проєкції на кшталт containers[].image чи відфільтровані списки, тому що CLI друкує оцінену форму, яку ви порівнюватимете з умовами deny та передумовами.

# Query a JSON file.
kyverno jp query "metadata.labels.app" -i resource.json

# Parse an admission-style expression.
kyverno jp parse "request.object.metadata.namespace"

# Test a query against JSON supplied on standard input.
echo '{"spec":{"containers":[{"name":"nginx","image":"nginx:1.25"},{"name":"sidecar","image":"envoy:1.28"}]}}' | \
  kyverno jp query "spec.containers[].image"

Вираз	Що повертає
`request.object.metadata.labels.app`	Значення мітки `app`
`request.object.spec.containers[].image`	Усі образи контейнерів як масив
`request.object.metadata.namespace
`length(request.object.spec.containers)`	Кількість контейнерів

Застосовуйте CLI як перший крок діагностики тоді, коли докази є локальними та відтворюваними на вашій машині. Застосовуйте логи допуску, PolicyReports та метрики тоді, коли докази залежать від живого контексту кластера, якого CLI просто не бачить. Ця межа проста, але вона запобігає чималій втраті часу, тому що локальний тест CLI не може повністю відобразити RBAC, селектори простору імен, готовність сервісу, тайм-аути вебхуків чи кожне динамічне значення, наявне в реальному запиті admission review.

Звіти політик: читайте слід аудиту

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

Область звіту повідомляє, який тип ресурсу було оцінено. Ресурси з простором імен, як-от Pod’и, Деплойменти та Сервіси, з’являються в об’єктах PolicyReport, прив’язаних до простору імен. Ресурси кластерної області, як-от Простори імен, Ноди, ClusterRoles та інші об’єкти без простору імен, з’являються в об’єктах ClusterPolicyReport. Ця відмінність дзеркалить області Kubernetes, тож вашим першим кроком налагодження має бути вибір правильного типу звіту, а не сліпий пошук у кожному просторі імен.

CRD	Область	Створюється для
`PolicyReport`	Простір імен	Ресурси з простором імен (Pod’и, Деплойменти, Сервіси)
`ClusterPolicyReport`	Кластерна область	Кластерні ресурси (Ноди, Простори імен, ClusterRoles)

# List cluster-wide reports.
kubectl get clusterpolicyreport

# List namespace reports with summary counts.
kubectl get policyreport -n production -o wide

# Get detailed results for a specific report.
kubectl get policyreport -n production polr-ns-production -o yaml

Кожен запис звіту має поле result, що описує результат оцінки політики. Не ставтеся до кожного результату, відмінного від pass, як до одного й того самого інциденту. Результат warn часто означає, що політика навмисно проводить аудит перед примусовим виконанням, результат error може вказувати на проблему з оцінкою політики, а результат skip може бути коректним, коли передумови не збігаються або застосовується виняток. Результат — це підказка, а не остаточний діагноз.

Результат	Значення
`pass`	Ресурс відповідає політиці
`fail`	Ресурс порушує політику
`warn`	Політика в режимі аудиту, і ресурс порушує її
`error`	Під час оцінки політики сталася помилка
`skip`	Політику пропущено, бо передумови не виконано або застосовано виняток

apiVersion: wgpolicyk8s.io/v1alpha2
kind: PolicyReport
metadata:
  name: polr-ns-production
  namespace: production
summary:
  pass: 42
  fail: 3
  warn: 1
  error: 0
  skip: 0
results:
  - policy: require-resource-limits
    rule: check-limits
    result: fail
    message: "CPU and memory limits are required."
    resources:
      - apiVersion: v1
        kind: Pod
        name: legacy-app-7f8b9c
        namespace: production

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

Спрощену версію процесу легко запам’ятати, але операційні нюанси криються в проміжних кроках. Ви розгортаєте політику з поведінкою аудиту, запитуєте kubectl get policyreport -A -o wide, інспектуєте конкретні записи звітів, відрізняєте легітимні порушення від ресурсів, яким потрібні винятки, виправляєте маніфести застосунків і спостерігаєте, як спадають лічильники fail чи warn. Лише коли решта знахідок зрозуміла, команда має перемикати політику на примусове виконання.

# Step 1: inspect namespace-scoped audit results across the cluster.
kubectl get policyreport -A -o wide

# Step 2: inspect one report deeply enough to see policy, rule, message, and resource.
kubectl get policyreport -n production polr-ns-production -o yaml

# Step 3: inspect cluster-scoped results separately.
kubectl get clusterpolicyreport -o yaml

Дані звітів також допомагають чітко відділити проблему самої політики від проблеми винятку до неї. Якщо результат skip, спершу погляньте на передумови, селектори match та exclude і PolicyExceptions, перш ніж переписувати саму політику. Якщо результат error, інспектуйте вираз політики, змінні, посилання на контекст та логи контролера, тому що помилка — це не те саме, що відповідне чи невідповідне робоче навантаження. Якщо звіт відсутній цілком, перевірте, чи увімкнено звітність, чи виконувалися фонові сканування і чи входить тип ресурсу в область політики.

PolicyExceptions та операційні обходи

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

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

Механізм	Застосовуйте, коли	Область
Блок `exclude` у політиці	Цілі категорії слід виключити, як-от системний простір імен чи відомий клас ресурсів	Частина визначення політики
CRD `PolicyException`	Потрібен конкретний операційний обхід, як-от один Под CNI, що вимагає привілейованих налаштувань	Окремий ресурс, яким може керувати інша команда

apiVersion: kyverno.io/v2
kind: PolicyException
metadata:
  name: allow-privileged-cni
  namespace: kube-system
spec:
  exceptions:
  - policyName: disallow-privileged-containers
    ruleNames:
    - require-non-privileged
  match:
    any:
    - resources:
        kinds:
        - Pod
        namespaces:
        - kube-system
        names:
        - "calico-node-*"

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

# Helm values
features:
  policyExceptions:
    enabled: true
    namespace: "kyverno-exceptions"

Централізація винятків у виділеному просторі імен — це управлінський вибір, а не технічна вимога. Дозвіл винятків у будь-якому просторі імен може зменшити тертя для команд застосунків, але це також розпорошує повноваження обходу по кластеру. Обмеження винятків простором імен на кшталт kyverno-exceptions спрощує рев’ю та RBAC, тому що лише невеликій групі потрібен дозвіл створювати ресурси, які послаблюють поведінку політики.

Який підхід ви б обрали тут і чому: одне глобальне виключення політики для kube-system чи названий PolicyException для одного привілейованого CNI DaemonSet? Виняток зазвичай є кращою операційною відповіддю, коли обхід дійсно вузький, тому що він зберігає примусове виконання для кожного іншого системного робочого навантаження й залишає об’єкт, придатний для аудиту, що пояснює виняток. Широке виключення легше написати, але воно ховає забагато майбутнього ризику під одним зручним селектором.

Спостережуваність: метрики, логи та затримка

Kyverno надає метрики Prometheus на порту 8000 за кінцевою точкою /metrics за замовчуванням, і ці метрики повідомляють, чи оцінка політик здорова як сервіс. Звіти відповідають на питання «що сталося з ресурсами», тоді як метрики відповідають «як часто, як швидко й з яким результатом Kyverno оцінює запити?» Вам потрібні обидва погляди, тому що кластер може не мати нових порушень і все одно мати повільний чи нездоровий шлях допуску.

Три метрики, важливі для KCA, які варто запам’ятати, — це результати політик, запити допуску та тривалість виконання політики. kyverno_policy_results_total рахує оцінки з мітками на кшталт policy_name, rule_name, rule_result (pass/fail) та типу ресурсу. kyverno_admission_requests_total рахує трафік допуску за resource_kind, resource_namespace та operation — вона не надає мітки allowed; відмови з’являються в результатах політик. kyverno_policy_execution_duration_seconds — це гістограма, що допомагає виявити повільну оцінку політики до того, як вона стане видимою користувачеві проблемою затримки API.

Метрика	Тип	Що повідомляє
`kyverno_policy_results_total`	Лічильник	Оцінки політик за політикою, правилом, `rule_result` та типом ресурсу
`kyverno_admission_requests_total`	Лічильник	Запити допуску за типом, простором імен та операцією (не allow/deny)
`kyverno_policy_execution_duration_seconds`	Гістограма	Скільки триває оцінка політики, що важить для SLO затримки допуску
`kyverno_controller_reconcile_total`	Лічильник	Активність узгодження фонового контролера

# Policy violation rate over the last five minutes.
rate(kyverno_policy_results_total{rule_result="fail"}[5m])

# Admission request latency at p99.
histogram_quantile(0.99, rate(kyverno_policy_execution_duration_seconds_bucket[5m]))

# Total policy failures (denials surface here, not on admission_requests_total).
sum(kyverno_policy_results_total{rule_result="fail"})

# Violations grouped by policy name.
sum by (policy_name) (kyverno_policy_results_total{rule_result="fail"})

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

# Enable via Helm values.
serviceMonitor:
  enabled: true
  additionalLabels:
    release: prometheus

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: kyverno
  namespace: kyverno
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: kyverno
  endpoints:
  - port: metrics
    interval: 30s

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

# Quick import via Grafana API. Use 127.0.0.1 when testing against a local Grafana instance.
curl -X POST http://127.0.0.1:3000/api/dashboards/import \
  -H "Content-Type: application/json" \
  -d '{"dashboard":{"id":15804},"overwrite":true,"inputs":[{"name":"DS_PROMETHEUS","type":"datasource","value":"Prometheus"}]}'

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

Висока доступність, конфігурація Helm та оновлення

Одна репліка Kyverno — це продакшн-ризик, тому що вебхуки допуску перебувають на шляху запиту API Kubernetes. Висока доступність — це не лише про підтримання зеленим Деплоймента Kyverno; це про підтримання доступності рішень допуску, коли вузли виводяться з експлуатації, Pod’и перезапускаються чи контролери перемикаються. Продакшн-встановлення мають використовувати кілька реплік, анти-афінність чи topology spread, запити та ліміти ресурсів і політику реагування на збій, що відповідає толерантності організації до ризику.

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

+-------------------------------------------------------------+
|                    Kyverno HA Setup                         |
|                                                             |
|   Node A              Node B              Node C            |
|   +----------+        +----------+        +----------+       |
|   | kyverno  |        | kyverno  |        | kyverno  |       |
|   | replica-0|        | replica-1|        | replica-2|       |
|   | leader   |        | standby  |        | standby  |       |
|   +----------+        +----------+        +----------+       |
|        |                   |                   |             |
|        +-------------------+-------------------+             |
|                            |                                 |
|                  Leader Election via Lease                   |
|                                                             |
|   Webhooks: all ready replicas serve admission requests      |
|   Background: one leader runs coordinated controller work     |
+-------------------------------------------------------------+

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

# Install: helm install kyverno kyverno/kyverno -n kyverno --create-namespace -f values.yaml

# Replicas for HA.
replicaCount: 3

# Pod anti-affinity to spread replicas across nodes.
podAntiAffinity:
  preferredDuringSchedulingIgnoredDuringExecution:
  - weight: 100
    podAffinityTerm:
      labelSelector:
        matchExpressions:
        - key: app.kubernetes.io/name
          operator: In
          values:
          - kyverno
      topologyKey: kubernetes.io/hostname

# Resource limits prevent Kyverno from consuming unbounded memory.
resources:
  limits:
    memory: 512Mi
    cpu: "1"
  requests:
    memory: 256Mi
    cpu: 100m

# Webhook configuration.
webhookAnnotations:
  cert-manager.io/inject-ca-from: kyverno/kyverno-svc.kyverno.svc.tls

# Failure policy and resource filters share one config: mapping (duplicate keys override silently).
config:
  webhooks:
    - failurePolicy: Fail
    # failurePolicy: Ignore
  resourceFilters:
    - "[*,kyverno,*]"
    - "[Event,*,*]"
    - "[*,kube-system,*]"
    - "[*,kube-public,*]"
    - "[*,kube-node-lease,*]"

# PolicyExceptions feature.
features:
  policyExceptions:
    enabled: true
    namespace: ""

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

Оновлення Kyverno вимагають обережності, тому що CRD, поведінка контролерів та поля політик можуть змінюватися між версіями. Helm не оновлює CRD автоматично під час звичайного helm upgrade, тож саме оновлення чарту може залишити API-сервер перевіряти політики за старими схемами. Безпечний патерн — прочитати посібник з міграції, зробити резервну копію політик та винятків, виважено застосувати цільові CRD, оновити реліз Helm і перевірити Pod’и, вебхуки, політики та звіти, перш ніж оголошувати оновлення завершеним.

kubectl get clusterpolicies -o yaml > clusterpolicies-backup.yaml
kubectl get policies -A -o yaml > policies-backup.yaml
kubectl get policyexceptions -A -o yaml > exceptions-backup.yaml

kubectl apply -f https://raw.githubusercontent.com/kyverno/kyverno/main/config/crds/kyverno/kyverno.io_clusterpolicies.yaml
kubectl apply -f https://raw.githubusercontent.com/kyverno/kyverno/main/config/crds/kyverno/kyverno.io_policies.yaml

helm repo update
helm upgrade kyverno kyverno/kyverno -n kyverno -f values.yaml

kubectl get pods -n kyverno
kubectl get clusterpolicies
kyverno version

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

Сценарії операційного runbook

Runbooks мають починатися з локалізації межі симптому: перед розгортанням, під час допуску, під час фонової звітності чи під час експлуатації самого сервісу Kyverno.

Симптом	Перша перевірка	Імовірна причина	Дія
CI провалюється на оцінці політики	Відтворіть точну команду `kyverno apply` чи `kyverno test` з тією самою версією CLI, шляхом політики та шляхом ресурсу	Логіка політики змінилася, фікстура більше не відповідає реальності, або `kyverno-test.yaml` очікує неправильний результат	Виправте політику, фікстуру чи очікуваний результат, потім додайте і pass-, і fail-випадки для правила
Живий запит несподівано відхилено	Прочитайте відповідь допуску щодо операції, простору імен, типу, назви політики та назви правила	Режим примусового виконання, передумови, контекст допуску чи збіг винятку відрізняється від локального тестового випадку	Порівняйте живий об’єкт і контекст допуску з ресурсом CLI, потім інспектуйте режим політики та винятки
Запит, який має бути відхилено, допускається	Перевірте логіку match політики, звіти та логи допуску, перш ніж змінювати налаштування вебхука	Тип, селектор простору імен, передумова, фільтр ресурсів чи `PolicyException` пропустили оцінку	Звузьте проблему області, оновіть блок match чи виняток і повторно протестуйте репрезентативним ресурсом
PolicyReports застарілі чи заплутані	Перевірте контролери Kyverno, налаштування генерації звітів, область ресурсу та час фонового сканування	Контролер ще не сканував, генерацію звітів вимкнено, або ресурс поза областю політики	Запишіть час розгортання та сканування, усуньте відомі знахідки й перевірте наступне оновлення звіту
Затримка допуску зростає	Почніть з `kyverno_policy_execution_duration_seconds`, ресурсів Pod’а, лічильників запитів та логів контролера	Дорогі правила, пошуки контексту, навантаження на CPU, навантаження на API-сервер чи нещодавнє зростання трафіку	Співвіднесіть сплеск з релізами політик, налаштуйте ресурси чи репліки й оптимізуйте повільні правила
Виняток виглядає підозріло	Визначте власника, назви політики й правила, блок match, причину та дату рев’ю	Широкий чи застарілий виняток обходить більше, ніж передбачене робоче навантаження	Звузьте match, оновіть власника й дату рев’ю або видаліть виняток після зміни робочого навантаження
Оновлення провалюється після змін Helm	Порівняйте нотатки міграції, встановлені CRD, стан Pod’ів, вебхуки, політики та репрезентативні тести CLI	Helm оновив контролери, але CRD чи ресурси політик усе ще відображають попередню версію	Зробіть резервну копію ресурсів, виважено застосуйте цільові CRD, повторіть оновлення Helm і перевірте звіти й тести
Розгортання сповільнюються після зростання політик	Перевірте частоту запитів, тривалість виконання p99, перезапуски, готовність та готові кінцеві точки Сервісу	У Kyverno замало реплік, недостатньо ресурсів чи правила, що більше не масштабуються з розміром кластера	Додайте репліки чи запити ресурсів, рознесіть Pod’и по вузлах та оптимізуйте дорогі правила політик
Фільтр ресурсів ховає очікувані знахідки	Інспектуйте запис фільтра та причину його додавання	Простір імен чи тип було виключено через шум, цикли, системну метушню чи історичний обхідний шлях	Задокументуйте намір, звузьте фільтр чи видаліть його, переконавшись, що Kyverno може безпечно оцінити ресурс
Поведінка Kyverno під час збою дивує команди	Перевірте `failurePolicy` вебхука, кількість реплік, готовність та кінцеві точки Сервісу	`Fail` чи `Ignore` обрано без чіткого рішення «безпека проти доступності»	Спершу забезпечте HA, тоді задайте політику реагування на збій залежно від критичності засобу контролю
Формулювання іспиту вказує на сценарій усунення несправностей	Зіставте ключові слова з доказами: pull request, відмова, затримка дашборда чи попередження звіту	Спершу досліджується неправильна операційна поверхня	Застосовуйте вхідні дані CLI для провалів PR, докази допуску для відмов, метрики для затримки й звіти для знахідок аудиту

Нотатки зі збору доказів

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

Для провалів CI збережіть точний командний рядок, робочий каталог, шляхи політик, шляхи ресурсів, код виходу й образ раннера чи тег контейнера. Ненульовий код виходу kyverno apply чи kyverno test означає, що запуск провалився, але самого числового коду не завжди досить, щоб відділити порушення політик від помилок налаштування між версіями CLI. Порівняйте stderr, --detailed-results та документацію закріпленого CLI, перш ніж вирішувати, чи виправляти маніфести, чи лагодити конвеєр.

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

Для відсутніх відмов доведіть, що Kyverno оцінив запит, перш ніж змінювати налаштування примусового виконання. Логи допуску, записи звітів та статус політики повідомляють, чи правило виконалося, пропустилося чи ніколи не збіглося. Якщо ресурс ніколи не з’являється в цих місцях, інспектуйте match, exclude, селектори простору імен, фільтри ресурсів та PolicyExceptions. Посилення failurePolicy не допомагає, коли Kyverno ніколи не просили оцінити ресурс.

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

Для проблем затримки збирайте і докази стану сервісу, і докази політики. Зростання p99 у kyverno_policy_execution_duration_seconds слід поєднувати з CPU Pod’а Kyverno, пам’яттю, перезапусками, готовими кінцевими точками, частотою запитів допуску та найсвіжішим релізом політики. Без такого співвіднесення видалення одного повільного правила може приховати проблему масштабування, що повернеться, коли додадуть наступну складну політику.

Тренувальні сценарії

У разі провалу бар’єра pull request відтворіть команду CI локально, перш ніж редагувати політику. Якщо та сама команда kyverno apply провалюється з тією самою версією CLI та файлами, імовірна проблема — ресурс чи політика. Якщо вона провалюється лише в CI, інспектуйте шляхи checkout, образи контейнерів, закріплені версії та чи змонтував раннер каталоги політики й маніфестів туди, де команда їх очікує.

Коли kyverno test провалюється після навмисної зміни політики, відділіть намір політики від дрейфу очікуваного результату. Провалений тест не є автоматично неправильним лише тому, що автор змінив політику. Порівняйте старий очікуваний результат, нову поведінку політики й призначення фікстури. Оновлюйте kyverno-test.yaml лише тоді, коли змінений результат є передбаченою поведінкою, і додайте негативну фікстуру, якщо набір більше не доводить відхилення.

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

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

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

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

Коли планується оновлення, протестуйте ресурси політик щодо цільового релізу Kyverno, перш ніж торкатися продакшну. CLI може рано вловити зміни синтаксису й поведінки, тоді як стейджинговий кластер може вловити поведінку CRD, вебхуків та контролерів. Запишіть нотатку міграції, що застосовується, джерело CRD, яке ви застосували, версію чарту Helm та команди після оновлення, що доводять здоров’я Pod’ів, вебхуків, політик та звітів.

Коли оновлення провалюється, бо поле політики відхилено, інспектуйте схему API, перш ніж перезапускати контролери. Запущений Под Kyverno не доводить, що API-сервер має встановлені новіші CRD. Зробіть резервну копію ресурсів політик, виважено застосуйте цільові CRD, повторіть відхилений ресурс і лише тоді продовжуйте з перевіркою релізу Helm. Якщо потрібен відкат, включіть стан CRD та ресурсів політик у нотатки відкату.

Коли Pod’и Kyverno здорові, але допуск усе одно тайм-аутить, перевірте Сервіс і шлях вебхука. API-сервер викликає URL вебхука, що розв’язується через Сервіс Kubernetes, тож готові кінцеві точки, селектори, порти, сертифікати та конфігурація вебхука важать так само, як статус Pod’а. Под може бути Running, тоді як Сервіс не має готового бекенда, що з точки зору API-сервера виглядає як збій Kyverno.

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

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

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

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

Розпізнавання патернів іспиту

Питання KCA зазвичай ховають операційну поверхню у формулюванні. Pull request чи задача CI вказують на kyverno apply чи kyverno test. Відхилене створення чи оновлення вказує на деталі відповіді допуску, стан вебхука та режим політики. Звіт із попередженнями вказує на усунення від аудиту до примусового виконання. Повільний дашборд вказує на метрики Prometheus, логи контролера, навантаження на ресурси та складність політики.

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

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

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

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

Патерн	Коли застосовувати	Чому працює	Міркування щодо масштабування
Набори тестів політик у CI	Політики керуються в Git і переглядаються через pull request’и	`kyverno test` документує очікувану поведінку pass та fail до того, як політики потраплять у кластер	Закріпіть версію CLI й тримайте репрезентативні ресурси близько до політики
Впровадження від аудиту до примусового виконання	Політика може вплинути на наявні навантаження чи багато команд	PolicyReports виявляють порушення до того, як примусове виконання заблокує розгортання	Визначте часові рамки усунення, щоб режим аудиту не став постійним
HA за замовчуванням	Вебхуки Kyverno є частиною шляху допуску	Кілька реплік та анти-афінність зменшують переривання під час обслуговування вузлів чи Pod’ів	Стежте за готовими кінцевими точками, затримкою вебхуків та поведінкою виборів лідера
Вузькі винятки	Легітимному навантаженню потрібен обхід політики	`PolicyException` обмежує обхід, не послаблюючи політику глобально	Централізуйте простір імен винятків і вимагайте власників, причин та дат рев’ю

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

Антипатерн	Що йде не так	Краща альтернатива
Запуск однієї репліки Kyverno у продакшні	Витіснення Pod’а чи проблема з вузлом може прибрати єдиний бекенд допуску	Використовуйте кілька реплік, анти-афінність, перевірки готовності та оповіщення
Ставлення до режиму аудиту як до кінцевого стану	Порушення лишаються видимими, але ніколи не усуваються, тож засіб контролю фактично не захищає кластер	Відстежуйте лічильники звітів, призначайте власників і плануйте примусове виконання після усунення
Створення широких виключень політик	Цілі простори імен чи класи ресурсів припиняють отримувати корисне покриття політик	Віддавайте перевагу вузьким умовам match чи переглянутим PolicyExceptions
Оновлення Helm без CRD	Нові поля політик можуть бути відхилені чи проігноровані старими схемами API	Виважено застосовуйте цільові CRD перед оновленням релізу

Структура ухвалення рішень

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

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

Ситуація	Перший інструмент або налаштування	Чому цей вибір пасує	На що зважати
Нова політика в розробці	`kyverno test` з фікстурами pass та fail	Підтверджує передбачену поведінку до впровадження в кластер	Відсутні змінні контексту допуску
Pull request з маніфестами навантажень	`kyverno apply policies/ --resource manifests/`	Фільтрує запропоновані ресурси до того, як вони потраплять у допуск	Дрейф версій CLI між раннерами
Наявні навантаження можуть порушувати політику	Режим аудиту плюс PolicyReports	Робить вплив видимим перед примусовим виконанням	Знахідки аудиту без власника усунення
Одному легітимному навантаженню потрібен обхід	`PolicyException` з вузьким match	Уникає послаблення політики для непов’язаних ресурсів	Винятки, що ніколи не закінчуються чи не переглядаються
Зростає затримка допуску	Гістограма Prometheus та логи допуску	Відділяє повільну оцінку політики від порушень ресурсів	Дашборди без оповіщень
Оновлення версії Kyverno	Резервна копія CRD, застосування CRD, оновлення Helm, перевірка	Виважено обробляє зміни схеми й контролерів	Припущення, що Helm оновив CRD за вас

Start with the symptom
|
+-- Local manifest or PR fails? ----------> Use kyverno apply or kyverno test
|
+-- Live request denied? -----------------> Check admission logs, policy mode, and webhook health
|
+-- Existing resources show findings? ----> Read PolicyReports or ClusterPolicyReports
|
+-- One workload needs bypass? -----------> Prefer a narrow PolicyException
|
+-- Kyverno itself looks unhealthy? ------> Check replicas, endpoints, metrics, and failure policy
|
+-- Upgrade planned? ---------------------> Back up policy resources, apply CRDs, then upgrade Helm

Структура ухвалення рішень також допомагає з формулюванням іспиту. Якщо запит згадує PolicyReport, починайте з інтерпретації звіту, а не із синтаксису CLI. Якщо він згадує конвеєр CI, думайте про kyverno apply чи kyverno test. Якщо він згадує витіснення Pod’а чи недоступний вебхук, думайте про репліки, анти-афінність, готовність, кінцеві точки Сервісу та політику реагування на збій. Іспит винагороджує зіставлення симптому з правильною операційною поверхнею.

Чи знали ви?

CLI Kyverno працює повністю офлайн: ви можете тестувати політики щодо маніфестів на ноутбуці без кластера, без мережі й без встановленого Kyverno в цільовому кластері, що робить його практичним для CI-систем та робочих процесів рев’ю в ізольованих (air-gapped) середовищах.
PolicyReports дотримуються спільної моделі звітності політик: об’єкти PolicyReport, які записує Kyverno, базуються на роботі над API звітності політик Kubernetes, тож вони спроєктовані як ресурси Kubernetes, а не як формат логу лише для Kyverno.
Kyverno надає понад тридцять метрик Prometheus: операційні питання у стилі KCA зазвичай зосереджуються на результатах політик, запитах допуску та тривалості виконання, тому що ці метрики прямо пов’язані з відповідністю, відмовами та затримкою.
Команда kyverno jp допомагає налагоджувати вирази JMESPath: тестування запиту щодо JSON перед вбудовуванням у політику може заощадити час, коли передумови чи змінні повертають несподіване значення.

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

Помилка	Чому стається	Як виправити
Запуск `kyverno apply` щодо ресурсів кластера без `--cluster`	CLI читає локальні файли за замовчуванням, тож команда не дивиться на живі ресурси, доки їй про це не сказати	Додайте `--cluster`, коли передбачено оцінку кластера через kubeconfig, або передайте явні файли `--resource`
Забування `ruleNames` у PolicyException	Виняток має націлюватися на конкретні правила політики, а розмитого винятку недостатньо для передбаченого обходу	Вкажіть точний `policyName` та кожне передбачене ім’я правила, потім підтвердіть, що результат звіту змінюється як очікувалося
Налаштування `failurePolicy: Fail` з однією реплікою	Команда хоче строгого контролю допуску, але не зробила бекенд вебхука високодоступним	Використайте три чи більше реплік з анти-афінністю, потім оберіть `Fail` чи `Ignore` залежно від критичності політики
Оновлення релізу Helm без застосування CRD	Helm не оновлює CRD під час звичайних оновлень чарту, тож схеми API можуть відставати від поведінки контролерів	Зробіть резервну копію політик, виважено застосуйте цільові CRD, потім запустіть `helm upgrade` і перевірте ресурси політик
Ігнорування `kyverno_policy_execution_duration_seconds`	Команди стежать за лічильниками порушень, але забувають, що повільна оцінка політики додає затримку до запитів API	Налаштуйте оповіщення на високий перцентиль тривалості виконання й дослідіть дорогі правила, пошуки контексту чи перевантаження
Створення широких виключень простору імен для шумних знахідок	Це швидше, ніж виправляти маніфести чи переглядати винятки, але ховає непов’язані майбутні порушення	Застосуйте режим аудиту, щоб інвентаризувати вплив, виправте поширені причини й створюйте вузькі PolicyExceptions лише за обґрунтування
Тестування лише ресурсів, що мають пройти	Набір тестів лише з pass-випадками не може довести, що політика відхиляє поведінку, яку її написано запобігти	Додайте принаймні одну fail-фікстуру на кожне важливе правило й змусьте `kyverno test` стверджувати очікуваний провал

Тест

Питання 1: Ваш pull request додає три маніфести Kubernetes, і CI має блокувати злиття, якщо будь-який маніфест порушує каталог політик. Який підхід CLI Kyverno слід застосувати і чому?

Застосуйте kyverno apply policies/ --resource manifests/ --detailed-results як бар’єр pull request. Ця команда оцінює запропоновані ресурси щодо набору політик до того, як вони потраплять у кластер, а її код виходу може провалити задачу CI, коли знайдено порушення. kyverno test усе ще цінний для розробки політик, але він кращий, коли ви стверджуєте очікувані фікстури pass та fail, а не просто фільтруєте маніфести застосунків. Живий лог допуску був би неправильним першим інструментом, тому що ресурси ще не розгорнуто.

Питання 2: Простір імен має PolicyReport із кількома результатами `warn` для нової політики лімітів ресурсів. Що команда має зробити, перш ніж змінювати політику на примусове виконання?

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

Питання 3: DaemonSet CNI потребує привілейованих налаштувань, але кластер має політику, що відхиляє привілейовані контейнери. Як слід змоделювати виняток?

Створіть вузький PolicyException, що називає конкретну політику й правило, збігається з Pod’ами DaemonSet за типом, простором імен та шаблоном імені, і тримайте виняток під контрольованим RBAC. Такий підхід зберігає політику для непов’язаних навантажень, водночас документуючи операційну причину обходу. Широке виключення для всього kube-system могло б бути легшим, але воно сховало б майбутні порушення від інших системних компонентів. Функцію також треба увімкнути в конфігурації Kyverno, інакше ресурс винятку не матиме передбаченого ефекту.

Питання 4: Після оновлення Kyverno політика, що використовує нове поле, відхиляється API-сервером, хоча Pod'и контролера запущені. Яка найімовірніша операційна помилка?

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

Питання 5: Під час виведення вузла з експлуатації запити допуску починають тайм-аутити, бо єдиний Под Kyverno було витіснено. Які зміни встановлення зменшують цей ризик?

Запустіть кілька реплік Kyverno, рознесіть їх анти-афінністю Pod’ів чи правилами топології, надайте відповідні запити ресурсів та стежте за готовими кінцевими точками Сервісу. Кілька готових реплік дозволяють Сервісу Kubernetes маршрутизувати трафік вебхука до іншого Pod’а, коли один вузол виводиться з експлуатації. Анти-афінність зменшує шанс, що всі репліки опиняться на одному вузлі й зникнуть разом. Команді також варто переглянути політику реагування на збій, тому що Fail та Ignore виражають різні компроміси, коли вебхук не може відповісти.

Питання 6: Правило політики використовує передумову JMESPath і продовжує пропускати ресурси, що мали б збігтися. Який практичний шлях налагодження?

Почніть з вилучення репрезентативного JSON та тестування виразу за допомогою kyverno jp, потім порівняйте повернене значення з логікою передумови в політиці. Якщо запит повертає масив, null чи інше поле, ніж очікувалося, політика може коректно пропускати згідно зі своїм поточним виразом, навіть якщо автор мав на увазі щось інше. Після виправлення виразу локально додайте випадок kyverno test, що фіксує ресурси, які збігаються й не збігаються. Перехід прямо до конфігурації вебхука був би передчасним, бо симптом вказує на логіку правила.

Питання 7: Prometheus показує зростання p99 для `kyverno_policy_execution_duration_seconds`, але PolicyReports не показують більше провалів. Що це підказує?

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

Практична вправа: конвеєр CLI Kyverno

Сценарій вправи: ви додаєте політику лімітів ресурсів до репозиторію Git і хочете локальний набір тестів, що поводиться як бар’єр CI. Вправа використовує лише локальні файли, тож ви можете зосередитися на робочому процесі CLI без залежності від запущеного кластера Kubernetes. Ви створите одну політику, один Под, що проходить, один Под, що провалюється, структурований kyverno-test.yaml та контрольний список, що доводить роботу і політики, і очікувань тесту.

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

Установіть CLI Kyverno методом, який підтримує ваше середовище, потім створіть чистий робочий каталог для лабораторної роботи. Приклади нижче використовують Homebrew для зручності й тримають усі файли в ~/kyverno-lab, але та сама структура файлів працює в будь-якому тимчасовому каталозі. Якщо ви використовуєте закріплений бінарник у CI-системі вашої команди, використовуйте ту саму версію локально, щоб поведінка тестів відповідала автоматизації.

# Install Kyverno CLI with one supported method.
brew install kyverno
# Or download a binary from https://github.com/kyverno/kyverno/releases

# Create a working directory.
mkdir -p ~/kyverno-lab/tests
cd ~/kyverno-lab

Завдання 1: створіть політику

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

cat <<'EOF' > policy.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-limits
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "CPU and memory limits are required for all containers."
      pattern:
        spec:
          containers:
          - resources:
              limits:
                memory: "?*"
                cpu: "?*"
EOF

Завдання 2: створіть ресурси, що проходять і провалюються

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

# Resource that should pass.
cat <<'EOF' > tests/good-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: good-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m"
EOF

# Resource that should fail.
cat <<'EOF' > tests/bad-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: bad-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    # No resource limits.
EOF

Завдання 3: тестування за допомогою `kyverno apply`

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

# Should pass with exit code 0.
kyverno apply policy.yaml --resource tests/good-pod.yaml --detailed-results

# Should fail with exit code 1.
kyverno apply policy.yaml --resource tests/bad-pod.yaml --detailed-results

Завдання 4: створіть структурований набір тестів

Тепер закодуйте очікування у kyverno-test.yaml. Це файл, який ви тримали б у контролі версій поряд із політикою, тому що він документує і поведінку pass, і поведінку fail. Зверніть увагу, що поганий Под очікувано провалюється, тож провалений результат політики все одно може дати тестовий випадок, що проходить, коли результат відповідає очікуванню.

cat <<'EOF' > tests/kyverno-test.yaml
apiVersion: cli.kyverno.io/v1alpha1
kind: Test
metadata:
  name: resource-limits-test
policies:
  - ../policy.yaml
resources:
  - good-pod.yaml
  - bad-pod.yaml
results:
  - policy: require-resource-limits
    rule: check-limits
    resource: good-pod
    kind: Pod
    result: pass
  - policy: require-resource-limits
    rule: check-limits
    resource: bad-pod
    kind: Pod
    result: fail
EOF

Завдання 5: запустіть набір тестів

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

kyverno test tests/

ID | POLICY                    | RULE         | RESOURCE  | RESULT
---|---------------------------|--------------|-----------|-------
1  | require-resource-limits   | check-limits | good-pod  | Pass
2  | require-resource-limits   | check-limits | bad-pod   | Pass

Test Summary: 2 tests passed, 0 tests failed

Розв’язання

Очікувана інтерпретація `kyverno apply`

Добрий Под має пройти, тому що його єдиний контейнер має і ліміти CPU, і ліміти пам’яті. Поганий Под має провалитися, тому що патерн вимагає значення resources.limits.memory та значення resources.limits.cpu для кожного контейнера. Якщо обидва ресурси проходять, патерн політики надто слабкий або оцінено не ті файли. Якщо обидва ресурси провалюються, перевірте відступи, назву політики та чи дійсний YAML ресурсу.

Очікувана інтерпретація `kyverno test`

Набір тестів має пройти обидва випадки, тому що good-pod очікувано проходить, а bad-pod очікувано провалюється. Ця відмінність — головна причина, чому kyverno test корисний для авторів політик. Порушення політики не є автоматично проваленим тестом; це провалений тест лише тоді, коли фактичний результат відрізняється від очікуваного результату, оголошеного у kyverno-test.yaml.

Підказка до бонусного завдання

Додайте третій Под із двома контейнерами, де один контейнер має ліміти, а другий — ні. Спрогнозуйте, що політика має провалитися, тому що патерн застосовується до всього списку контейнерів і кожен контейнер має задовольняти необхідну форму. Додайте ресурс до resources, додайте запис results з result: fail і запустіть kyverno test tests/ знову. Якщо результат вас здивує, інспектуйте, як зіставлення патернів Kyverno застосовується до масивів.

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

kyverno version успішно запускається в лабораторному середовищі.
kyverno apply policy.yaml --resource tests/good-pod.yaml --detailed-results завершується успіхом.
kyverno apply policy.yaml --resource tests/bad-pod.yaml --detailed-results повідомляє про порушення політики.
tests/kyverno-test.yaml містить очікування і для ресурсу, що проходить, і для ресурсу, що провалюється.
kyverno test tests/ повідомляє про обидва випадки як про пройдені, тому що фактичні результати збігаються з очікуваними.
Ви можете пояснити, коли застосовувати kyverno apply як бар’єр, а коли — kyverno test як набір тестів поведінки політики.

Джерела

Перевірка засвоєння

Helm values.yaml: Один верхньорівневий блок config: містить і webhooks (failurePolicy: Fail), і resourceFilters як рівнозначні елементи — дублювання ключів config: мовчки відкинуло б налаштування вебхуків.

Prometheus: Використовуйте rule_result="fail" на kyverno_policy_results_total; kyverno_admission_requests_total не має мітки allowed — рахуйте відмови через результати політик.

Коди виходу CLI: Ставтеся до ненульового kyverno apply / kyverno test як до провалу; підтвердьте значення коду виходу через --help для вашої версії CLI, а не припускайте 1 чи 2.

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

Продовжте з Домен 5: написання політик, щоб попрактикувати патерни політик validate, mutate, generate, verifyImages та CEL після того, як ви матимете операційний робочий процес на місці.