Kyverno в Kubernetes: почему политики не срабатывают
Чаще всего политики формально есть: манифесты применены, правила описаны, отчёты собираются. Но часть развёртываний проходит мимо проверок, часть падает с невнятной ошибкой admission-вебхука, а конфигурация кластера между средами расходится всё сильнее. Причина почти никогда не в самих правилах — она в том, как настроено их применение.
Первый источник — сам admission-вебхук. Если для него выбран режим, при котором недоступность контроллера политик не блокирует запрос, развёртывания в этот момент проходят без проверки. Туда же селекторы по пространствам имён и меткам: под правило попадает лишь часть рабочих нагрузок. А поды, которые контроллеры создают уже после проверки, без фонового сканирования остаются вне политик.
Второй — порядок срабатывания правил мутации и политик валидации. Мутация меняет объект до валидации, поэтому проверка, рассчитанная на поля, которые подставляет другое правило, ведёт себя иначе, чем ожидалось. Отклонённые развёртывания приходят сообщением вебхука без имени правила и конкретного поля — по такому тексту причину не восстановить.
Третий — управление политиками. Когда правила живут в репозитории, а применяются руками, послабления накапливаются в одном кластере и не доезжают до другого: в тестовой среде мутация сработала, в продуктивной её нет, и валидация отклоняет то, что в тесте проходило. Контроль конфигурации кластера разваливается тихо, без явных ошибок — дальше разбираем, как это закрывается.
Что меняется после внедрения: измеримые эффекты
Kyverno встраивается в момент допуска объекта в кластер, поэтому эффект измеряется метриками сопровождения, а не ощущениями. Ниже — четыре величины, которые меняются в первые недели после перехода.
Доля изменений, прошедших без ручной правки
Требование описывается один раз: обязательные метки, пределы ресурсов, запрещённые источники образов. Инженер не сверяет конфигурации глазами, а получает отказ с причиной прямо в выводе команды — доля правок, возвращаемых автору на доработку, падает с десятков до единиц.
Время проверки изменения
Разбор конфигурации сокращается с часов до минут: рецензент смотрит смысл изменения, а не соответствие регламенту. Типовые отклонения отсекаются автоматически, ещё до попадания в основную ветку, поэтому проверки перестают быть узким местом релиза.
Класс отказов, который исчезает
Отдельный источник сбоев — расхождение сред: на тестовом контуре правило соблюдали, на продуктивном забыли. Мутация приводит объект к единому виду при создании, и требования к средам становятся одинаковыми по построению, а не по договорённости в документе.
Время восстановления после неверной конфигурации
Если некорректное изменение всё же прошло, генерация зависимых объектов и явная причина отказа сокращают разбор. Время простоя укладывается в минуты: откат описывается той же политикой, что и запрет, а не отдельным сценарием.
Режимы применения правил: аудит, блокировка, мутация
Одно и то же правило в Kyverno описывается один раз, а режим определяет, что произойдёт при несоответствии: запись в отчёт, отказ в создании объекта или исправление манифеста на лету. Порядок внедрения — аудит на живом кластере, затем сухой прогон на реальных манифестах, и только потом блокировка: иначе первое же строгое правило останавливает выкат.
Мутация и генерация — отдельная категория: они не отклоняют объект, а приводят его к нужному виду или создают связанные объекты. Их включают после того, как аудит показал, чего именно не хватает ресурсам.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Аудирующий режим | Первый прогон на живом кластере: собрать нарушения без остановки выката | Ничего не запрещает — отклонения продолжают создаваться |
| Сухой прогон | Проверить новое правило на реальных манифестах до включения | Не видит решений, зависящих от текущего состояния кластера |
| Блокирующий режим | Когда нарушения разобраны и ложных срабатываний нет | Невалидный манифест падает целиком — выкат останавливается |
| Мутация ресурсов | Автоподстановка меток, лимитов и безопасных значений по умолчанию | Меняет исходный манифест: расхождение с репозиторием |
| Генерация объектов | Нужны сопутствующие объекты: квоты, сетевые политики, доступы | Требует правил удаления — объекты остаются после снятия метки |
Внутри одного прохода правила применяются последовательно: мутация, затем проверка, затем генерация. Блокирующее правило поэтому проверяет уже исправленный объект.
Этапы внедрения: от разбора кластера до передачи
Порядок работ строится так, чтобы ни один этап не тормозил разработку раньше, чем мы увидим реальную картину кластера. Сначала инвентаризация и проект правил, затем мягкий прогон, разбор ложных срабатываний и только потом блокировка. Это снимает главный риск: политика, включённая сразу в жёстком режиме, останавливает выкатку релиза из-за одного нештатного манифеста.
- Аудит кластера. Инвентаризируем объекты и исключения: привилегированные контейнеры, тома хоста, образы без фиксированного тега, контейнеры без лимитов. Отдельно фиксируем пространства имён и служебные нагрузки, которые трогать нельзя.
- Проект набора правил. Раскладываем найденное по классам нарушений — одно правило на класс, с понятным текстом отказа. Согласуем, что уходит в блокировку, а что остаётся предупреждением.
- Пилот на стенде. Прогоняем правила Kyverno на копии кластера, разбираем отчёты и правим формулировки, пока ложные срабатывания не уйдут.
- Мягкий запуск. Включаем набор в режиме аудита на рабочем контуре: смотрим, сколько объектов нарушает, кто их создаёт и мешает ли это выкатке.
- Перевод в блокировку. Переводим по одному правилу, начиная с тех, где отчёты чистые. Для унаследованных нагрузок — точечные исключения со сроком пересмотра.
- Приёмка правил. Прогоняем сценарии обхода: подмена образа, запуск от суперпользователя, отсутствие лимитов. Проверяем, что правило срабатывает и не ломает штатные релизы.
- Передача эксплуатации. Отдаём репозиторий с политиками, схему приоритетов, регламент исключений и порядок обновления набора.
Политики доступа и комплект передаваемой документации
Политики, которые никто не описывал словами, через полгода превращаются в набор правил, которые боятся трогать: непонятно, что проверяет каждая директива и что произойдёт при её отключении. Поэтому вместе с настроенным кластером заказчик получает комплект, где у каждого правила есть описание, а у команды — согласованный порядок работы с ним.
- Реестр правил. По каждой политике указано, что она проверяет, какие ресурсы затрагивает, работает в блокирующем режиме или только в режиме отчёта и почему.
- Роли и доступы. Правка политик и согласование их включения разделены между разными людьми; права выдаются ролями, а не одной общей учётной записью.
- Схема применения. Путь правила от репозитория до кластера: где лежит исходник, как проходит проверку, в какой момент начинает действовать и как откатывается.
- Регламент изменений. Новое правило сначала собирает срабатывания в режиме отчёта и только после разбора переводится в блокирующий — массовых остановок выкаток не случается.
- Порядок исключений. Как оформить исключение по пространству имён или метке, кто его согласует и когда оно снимается, не требуя правки самого правила.
- Инструкция для дежурной смены. Что делать, если правило остановило выкатку: как отличить ложное срабатывание от реального нарушения, где смотреть журнал и в каком порядке снимать блокировку.
- Отчёты о срабатываниях. Настроенная выгрузка событий по правилам — видно, какие проверки чаще мешают работе, а какие пора ужесточать.
Как в одном кластере убрали ручные правки конфигураций
Кластер на несколько десятков сервисов и три среды — разработка, предпродакшн, продуктив. Любая правка манифеста шла через ручное ревью: дежурный инженер открывал diff, сверял лимиты, метки, политики безопасности и хранилище образов. Расхождения между средами всплывали уже после выпуска.
Что было
На ревью приходило 60-80 правок в неделю, каждая занимала от десяти минут. До продуктива доходило около 10% — остальное возвращалось на доработку после сборки и тестов. Автор не понимал, что именно нарушил: формальных правил не было, были договорённости.
Что изменили
Правила перевели в Kyverno. Валидация отклоняет манифест до применения: нет лимитов ресурсов, нет метки владельца, плавающий тег образа, запись в чужое пространство имён. Мутация сама проставляет недостающие поля и приводит среды к общему шаблону, генерация создаёт квоты и сетевые правила вместе с приложением.
Что стало
Отказ приходит в течение минуты и с указанием сработавшего правила — раннее отклонение вместо разбора постфактум. Ручных проверок стало меньше на порядок, время реакции на ошибку сократилось с часов до минуты. Возвраты по конфигурации после выпуска почти исчезли, а расхождения между средами перестали быть отдельной задачей.
Что делать, если в кластере уже есть свои правила и исключения?
Правила не отменяют уже сделанное — они встают рядом и постепенно замещают наработки. Начинаем с режима аудита: новый набор фиксирует нарушения, но не блокирует развёртывание, и сразу видно, где он расходится с выданными ранее послаблениями и какие рабочие нагрузки задевает первыми. В блокирующий режим правила переводят по одному и только после разбора этих расхождений.
Конфликт правил чаще всего рождается на стыке мутации и валидации. Если правило сначала дописывает метку или побочный контейнер, проверка видит уже изменённый объект и срабатывает иначе, чем ожидалось. Поэтому целевое состояние описываем мутацией, а требования — валидацией поверх него, и держим их вместе, чтобы порядок применения был предсказуемым.
Наследование строим сверху вниз: базовые требования живут на уровне кластера, надстройки — в отдельных пространствах имён. Исключение, объявленное выше, действует везде; исключение снизу не должно тихо снимать требование для соседей, иначе одно пространство имён ослабляет политику всему кластеру.
Каждое старое исключение переносим отдельной записью с причиной и сроком пересмотра, а не общим обходом проверок. То, что не удаётся объяснить словами, закрывается требованием — обычно это правила, добавленные когда-то «на время».
Самописные проверки выводим последними: пока новый набор в аудите не покажет совпадение с ними на всех нагрузках, скрипты остаются страховкой. Дальше их отключают по одному, и в кластере остаётся один источник требований с понятным порядком применения.
Технические сомнения: ограничения и совместимость
Синтаксис правил Kyverno — редкость сложностей; вопросы начинаются на эксплуатации. Что будет с выпуском при недоступности контроллера, как не задеть системные компоненты и что менять при обновлении версий — ниже отвечаем на сомнения, которые чаще всего поднимает команда сопровождения кластера.
Что будет, если контроллер политик недоступен?
Кластер работает по выбранному режиму отказа: мягкий пропускает запросы без проверки, строгий — отклоняет. Строгий ставим точечно, на критичные правила, с коротким таймаутом и узкой областью проверки.
Политики могут остановить выпуск приложения?
Перед принуждением правило прогоняем в режиме аудита: отчёты показывают, сколько объектов его нарушат, а выпуск при этом не блокируется. Перевод в строгий режим — только после устранения расхождений.
Как исключить системные компоненты кластера?
Сеть, автомасштабирование и хранилище выводим из-под правил через исключения по меткам пространств имён. Иначе одна проверка способна остановить служебные контуры раньше, чем прикладные.
Какие ограничения у самих правил?
Не всё выражается декларативно: межресурсные зависимости и порядок мутаций описываются явно. Генерация создаёт объекты в новых пространствах имён — на уже существующие она не распространяется.
Как проходит обновление версий?
Правила привязаны к версии API кластера. Обновление проверяем на тестовом контуре на том же наборе манифестов и переносим поэтапно, сохраняя совместимость с текущими политиками.
Обсудим задачу: с чего начинается настройка
Чтобы разбор задачи занял один короткий разговор, а не серию уточнений, полезно заранее собрать несколько вводных. Ничего экзотического не нужно — то, что и так есть у вашей команды: доступ к кластеру на чтение, текущие манифесты политик и описание того, какие проверки уже закрыты штатными средствами, а где они не срабатывают.
Дальше мы проходим по кластеру и смотрим, какие правила валидации, мутации и генерации дадут реальный эффект, а какие конфликтуют с существующими рабочими нагрузками. Возвращаемся с оценкой сроков и планом работ: что делаем первым, какие политики включаем в режиме аудита, какие — в блокирующем, и как каждое изменение откатывается.
Что нужно от заказчика для старта:
- Перечень кластеров и окружений с порядком, в котором их трогаем.
- Доступ на чтение к API-серверу и к репозиторию с манифестами — можно через вашего инженера.
- Текущие политики: что настроено вручную, что через admission-контроллеры, какие исключения уже накоплены.
- Болевые точки: какие развёртывания ломались из-за неверных тегов, лимитов или отсутствующих меток.
- Требования безопасности и аудита: какие проверки обязаны блокировать развёртывание, а какие достаточно логировать.
- Контакт инженера, который подтвердит решения по политикам и правам доступа.
- Ограничения по окнам изменений — когда допустимо включить блокирующий режим в рабочем окружении.
Со своей стороны даём схему размещения политик, конфигурации с разделением по пространствам имён, порядок проверки на тестовом контуре и описание процедуры отката. Если часть вводных пока неизвестна — это не повод откладывать: начнём с аудита текущего состояния, а недостающее закроем по ходу.
