Kubernetes workload¶
Требования применяются к deployment и runtime-конфигурации приложений в
Kubernetes. Уровни обязательности определены в корневом README.md.
INF-K8S-001. Декларативный workload¶
Уровень: MUST
Применяется к: каждому Kubernetes-развёртыванию
Все namespaced-ресурсы приложения должны получаться из версионируемой конфигурации Helm, Kustomize или Helm, обработанного Kustomize. Ручное создание или изменение production-ресурса вне управляемого аварийного процесса запрещено.
Обоснование¶
Декларативная конфигурация обеспечивает повторяемость и аудит.
Проверка¶
- чистое развёртывание из Git;
- сравнение live-ресурсов с отрендеренной конфигурацией.
Исключения¶
Контроллер MAY создавать дочерние runtime-ресурсы из декларативного custom resource.
INF-K8S-002. Health probes¶
Уровень: MUST
Применяется к: контейнеру приложения, имеющему архитектурные health checks
Startup, readiness и liveness probes должны реализовывать
architecture:BE-HLTH-001–BE-HLTH-009. Параметры probes должны учитывать
измеренное время старта и восстановления приложения. Инфраструктура не должна
менять семантику endpoint: в частности, liveness не зависит от внешней системы,
а readiness исключает экземпляр из трафика до готовности и при graceful
shutdown.
Обоснование¶
Неверная probe вызывает каскадные рестарты или направляет трафик в неготовый процесс.
Проверка¶
- тест медленного старта, потери зависимости и завершения;
- сопоставление путей и тайм-аутов с контрактом приложения.
Исключения¶
Job без входящего трафика MAY не иметь readiness probe.
INF-K8S-003. Ресурсы и безопасный runtime¶
Уровень: MUST
Применяется к: каждому контейнеру приложения
Контейнер должен иметь requests для CPU, memory и применимого ephemeral storage,
а также limits для memory и ephemeral storage. Необходимость CPU limit должна
быть выбрана по измеренному поведению нагрузки. Значения должны согласовываться
с architecture:BE-RSRC-001–BE-RSRC-003.
Контейнер должен запускаться без privileged, без повышения привилегий, с
runAsNonRoot, read-only root filesystem и удалёнными Linux capabilities.
Обоснование¶
Границы ресурсов обеспечивают планирование, а минимальные привилегии уменьшают последствия дефекта.
Проверка¶
- policy или статическая проверка PodSpec;
- запуск workload с заявленными ограничениями.
Исключения¶
Необходимые writable paths, запуск от фиксированного UID, capabilities либо отключение read-only root filesystem должны быть перечислены и обоснованы. Privileged, hostPID, hostIPC, hostNetwork или hostPath в production требует ADR владельца платформы и отдельной проверки области доступа.
INF-K8S-004. Service account¶
Уровень: MUST
Применяется к: каждому workload
Workload должен использовать отдельный service account. Автоматическое монтирование Kubernetes API token должно быть отключено, если приложение не обращается к API. Разрешения должны ограничиваться требуемыми ресурсами, verbs и namespace.
Обоснование¶
Default service account создаёт неявные и избыточные полномочия.
Проверка¶
- review serviceAccountName, automount и RBAC;
- негативный тест запрещённой операции.
Исключения¶
Несколько workload одного компонента MAY разделять account при одинаковых полномочиях и владельце.
INF-K8S-005. Завершение процесса¶
Уровень: MUST
Применяется к: workload с долгими запросами или фоновой обработкой
terminationGracePeriodSeconds должен покрывать проверенную задержку удаления
из маршрутизации, timeout завершения по
architecture:BE-SHUT-001–BE-SHUT-007 и запас платформы. Если внешняя
маршрутизация продолжает трафик после SIGTERM, должен использоваться
ограниченный preStop либо эквивалентный drain. Deployment должен проверять
завершение активной работы без штатного SIGKILL.
Обоснование¶
Короткий grace period приводит к оборванным запросам и повторной обработке.
Проверка¶
- deployment-тест с долгой операцией;
- наблюдение сигналов, readiness и завершения.
Исключения¶
Не применяются для процесса, который доказуемо не имеет сохраняемого состояния операции.
INF-K8S-006. Изменение ConfigMap и Secret¶
Уровень: MUST
Применяется к: workload, использующему ConfigMap или Secret
Deployment-конфигурация должна явно определять, применяется ли изменение через
перезапуск экземпляров либо поддерживаемую runtime-ротацию по
architecture:BE-CONF-001–BE-CONF-013 и
architecture:SEC-SCRT-006–SEC-SCRT-009. Для restart-модели изменение
содержимого должно менять Pod template или другую наблюдаемую revision; простое
обновление объекта без доставки значения процессу не должно считаться
успешным rollout.
Обоснование¶
Изменённый ConfigMap или Secret не гарантирует, что работающий процесс получил новое значение.
Проверка¶
- изменение конфигурации и секрета с проверкой revision и значения в новом Pod;
- тест ротации без разрыва для runtime-модели.
Исключения¶
Неиспользуемое изменение metadata не требует перезапуска.
INF-K8S-007. Миграция как отдельная операция¶
Уровень: MUST
Применяется к: release с миграцией данных
Миграция должна выполняться отдельным ограниченным Job или эквивалентной
операцией до, во время либо после rollout согласно
architecture:BE-MIG-001–BE-MIG-004. Одновременное выполнение одной миграции
несколькими Pod должно предотвращаться. Job должен иметь timeout, ограниченную
retry policy, сохраняемый результат и не должен запускаться как неуправляемый
side effect старта каждой реплики.
Обоснование¶
Конкурентная или бесконечно повторяемая миграция повреждает данные и блокирует release.
Проверка¶
- параллельный запуск двух release;
- тест timeout, retry и неуспешной миграции;
- проверка остановки rollout.
Исключения¶
Миграция при старте допустима только при доказанной межпроцессной блокировке и выполнении тех же архитектурных контрактов.
INF-K8S-008. Ограниченный Job и CronJob¶
Уровень: MUST
Применяется к: Kubernetes Job и CronJob
Job должен иметь activeDeadlineSeconds, ограниченный backoffLimit и политику
очистки завершённых объектов. CronJob должен дополнительно задавать
concurrencyPolicy, deadline пропущенного запуска, time zone и пределы истории.
Если версия Kubernetes не поддерживает поле time zone, расписание должно быть
задано и документировано в UTC. Политика повторов должна соответствовать
идемпотентности операции; невозможность выполнить критичный Job должна
создавать alert.
Обоснование¶
Зависшая или конкурентная фоновая операция не должна бесконечно потреблять ресурсы либо незаметно пропускаться.
Проверка¶
- тест зависания, ошибки и перекрывающихся запусков;
- проверка очистки истории и alert.
Исключения¶
Одноразовый диагностический Job MAY не иметь автоматического alert.
INF-K8S-009. Управляемое постоянное состояние¶
Уровень: MUST
Применяется к: workload, записывающему сохраняемые данные
Сохраняемые данные должны находиться в PersistentVolumeClaim или внешнем
сервисе, объявленном capability manifest. emptyDir, writable layer container
и локальный путь узла не должны быть единственной копией сохраняемых данных.
StorageClass, access mode, размер, expansion policy и backup должны быть заданы
явно.
Обоснование¶
Эфемерное и привязанное к узлу состояние теряется при пересоздании или переносе Pod.
Проверка¶
- пересоздание Pod и drain узла;
- review PVC, StorageClass и backup coverage.
Исключения¶
emptyDir допустим для cache и временных данных, потеря которых проверена.