LLM генерирует рабочие Kubernetes-манифесты с дырами: как поймать их до деплоя

Манифест, который выдала нейросеть, выглядит безупречно: правильные отступы, знакомые поля, `kubectl apply` не ругается, под переходит в Running. Именно на этом, судя по анонсу разбора на Habr, и строится ловушка. Проблемы вылезают позже, уже в production. Причина в том, что LLM воспроизводят устаревшие и небезопасные конфигурации, которых в обучающих данных предостаточно. Для масштаба: Ingress из `extensions/v1beta1` удалён в Kubernetes 1.22, а PodSecurityPolicy исчезла в 1.25. Старые туториалы с этими объектами по-прежнему лежат в сети, и модель охотно их цитирует.

Оговорка: в доступном анонсе нет подробностей, только тезисы. Ниже опираемся на них и на общеизвестные особенности Kubernetes.

Почему правдоподобный YAML опасен

Модель оптимизирует вероятность следующего токена, а не безопасность кластера. Годы публичных примеров, ответов на форумах и репозиториев с демо-конфигами учат её «типичному» манифесту. Типичный манифест из документации намеренно минимален: без лимитов ресурсов, без ограничений безопасности, часто с тегом `latest`. Для учебного стенда это нормально. Для боевого кластера нет.

Валидация схемы эту проблему не видит. Она проверяет форму: поля существуют, типы совпадают. Контейнер, запущенный от root с `privileged: true`, формально корректен. Манифест без readiness-проб тоже корректен, просто трафик придёт на под раньше, чем приложение к нему готово.

Классический набор дефектов, который находят при ревью такого YAML:

• `apiVersion` удалённых или объявленных устаревшими API, из-за чего манифест ломается при обновлении кластера;
• образы с тегом `latest` вместо зафиксированной версии или digest;
• отсутствие `resources.requests` и `limits`, то есть риск «шумного соседа» и OOM-убийств;
• запуск от root, нет `runAsNonRoot`, `allowPrivilegeEscalation: false`, `readOnlyRootFilesystem`;
• нет liveness и readiness проб;
• секреты прямо в `env` вместо Secret или внешнего хранилища;
• `hostNetwork`, `hostPath` и `privileged`, перенесённые из отладочных примеров;
• сервисы, открытые наружу, и отсутствие NetworkPolicy.

Где ставить заслоны

Первый уровень — проверка схемы под конкретную версию кластера. Для этого подходят kubeconform и `kubectl apply --dry-run=server`: серверный dry-run прогоняет манифест через API-сервер и admission-контроллеры, не создавая объектов. Для поиска устаревших API есть Pluto.

Второй уровень — статический анализ на безопасность и практики: kube-linter, Checkov, Trivy (режим config), Kubescape. Они ловят root-контейнеры, отсутствие лимитов, привилегированные режимы. Всё это запускается в CI на каждый pull request, независимо от того, писал файл человек или модель.

Третий уровень — политики в самом кластере. Pod Security Admission с профилем `restricted` отсекает небезопасные поды на входе. Kyverno или OPA Gatekeeper добавляют свои правила: запрет `latest`, обязательные лимиты, разрешённые реестры. Если автор манифеста что-то пропустил, кластер не пустит такой объект.

Как работать с ИИ-генерацией на практике

Относитесь к ответу модели как к pull request от стажёра: быстро, уверенно и без понимания вашего окружения. В запросе явно указывайте версию Kubernetes, требования к безопасности и политики организации. Просите объяснять каждый нетривиальный параметр, а потом проверяйте объяснение по документации.

Не давайте сгенерированным манифестам идти напрямую в кластер. Путь должен быть один: репозиторий, CI с линтерами, ревью человеком, GitOps-выкатка, постепенный rollout с наблюдением за метриками. Тогда скорость генерации остаётся преимуществом, а не отложенным инцидентом.

И последнее. Если в команде нет политик, которые автоматически отклоняют плохие конфиги, ИИ просто ускорит появление этих конфигов. Сначала нужны заслоны, потом автоматизация.