Kyverno & Kyverno Policies

Запланируйте небольшое окно обслуживания: эти шаги на короткое время отключают контроль
допуска (admission control) Kyverno в кластере. Команды выполняются через kubectl в целевом
кластере.

0. (Рекомендуется) Сделайте резервную копию собственных политик

Шаг 3 удаляет CRD Kyverno, а вместе с ними — все объекты ClusterPolicy/Policy, включая
созданные вами. (Встроенные политики Pod Security Standards новая версия создаёт заново
автоматически; сохранять нужно только ваши собственные политики.) Историю PolicyReports тоже
удаляется, она будет перегенерирована после переустановки.

kubectl get clusterpolicies.kyverno.io,policies.kyverno.io -A -o yaml > my-kyverno-policies-backup.yaml

1. Удалите старую версию через Marketplace

Удаляйте старое приложение через Marketplace, а не командой helm uninstall:

• Консоль: Managed Service for Kubernetes → ваш кластер → Marketplace / установленные
  приложения → удалите приложение Kyverno; или
• Terraform: удалите ресурс yandex_kubernetes_marketplace_helm_release и выполните
  terraform apply (destroy).

При этом запускается pre-delete-хук старого чарта (который удаляет вебхуки Kyverno) и
очищается запись Marketplace об установке. Прямой helm uninstall минует Marketplace и
оставляет «осиротевшую» запись о приложении, что позже приводит к ошибке AlreadyExists
при установке новой версии.

2. Удалите оставшиеся admission-вебхуки Kyverno — критично

Kyverno регистрирует свои вебхуки во время работы. Если какие-то из них уцелели после шага 1
(например, старый под был нездоров и pre-delete-хук не отработал), они указывают на уже
несуществующий Service и блокируют создание любых подов во всём кластере. Убедитесь, что их
не осталось, и удалите оставшиеся:

kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations | grep kyverno
kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations -o name \
  | grep kyverno | xargs -r kubectl delete

3. Удалите старые CRD Kyverno — обязательно

Helm устанавливает CRD чарта (каталог crds/) только если таких CRD ещё нет — он никогда не
обновляет и не заменяет существующие. Если старые CRD (Kyverno 1.9) остаются, новая установка
продолжит использовать устаревшие определения, и новые контроллеры v1.18 попадут в
crash-loop на проверках наличия CRD (отсутствуют ephemeralreports.reports.kyverno.io, группа
policies.kyverno.io и т. д.). Удалите все CRD Kyverno, чтобы установился новый корректный
набор:

kubectl get crd -o name | grep -E 'kyverno\.io|wgpolicyk8s\.io' | xargs -r kubectl delete

Заодно удалятся типы CRD, убранные в v1.18 (например, generaterequests, updaterequests).

4. Удалите старое пространство имён

Удалите пространство имён, которое использовала старая версия продукта (или убедитесь, что оно пустое,
прежде чем переиспользовать):

kubectl delete namespace <старое-пространство-имён>

5. Проверьте, что кластер очищен

kubectl get crd | grep -E 'kyverno\.io|wgpolicyk8s\.io'                     # пусто
kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations | grep kyverno   # пусто
kubectl get ns <старое-пространство-имён>                                   # NotFound

6. Установите новую версию

Установите новую версию Kyverno.

Затем проверьте установку и заново примените собственные политики из шага 0:

kubectl -n <пространство-имён> get pods     # 4 контроллера в состоянии Running: admission/background/cleanup/reports
kubectl get clusterpolicies.kyverno.io      # политики PSS, READY=true

При проверке сохранённых собственных политик учтите, что в Kyverno v1.18 поле
spec.validationFailureAction перенесено на уровень правила —
spec.rules[].validate.failureAction (Audit/Enforce).