Базовый контракт платформы¶
Требования применяются к Kubernetes-платформе как к готовой цели размещения и
не задают процедуру установки k3s, MicroK8s или другого дистрибутива.
Уровни обязательности определены в корневом README.md.
INF-PLT-001. Идентификация и границы платформы¶
Уровень: MUST
Применяется к: каждой Kubernetes-платформе
Платформа должна иметь стабильный идентификатор, владельца, перечень обслуживаемых сред, поддерживаемую версию Kubernetes и документированные границы ответственности между владельцем платформы и владельцем приложения.
Обоснование¶
Неопределённая ответственность оставляет обновления и отказы без владельца.
Проверка¶
- review platform manifest и маршрута поддержки;
- запрос версии Kubernetes и сопоставление с заявленной.
Исключения¶
Не допускаются.
INF-PLT-002. Изоляция целей¶
Уровень: MUST
Применяется к: Kubernetes-развёртываниям
Каждая цель должна использовать выделенный namespace. Production и non-production не должны разделять namespace, service accounts, secrets или постоянные тома. Доступы CI и операторов должны ограничиваться целевыми namespace.
Обоснование¶
Общие полномочия и имена увеличивают область ошибочного изменения.
Проверка¶
- запрос namespace, RBAC, secrets и PersistentVolumeClaim;
- негативный тест доступа service account к соседней цели.
Исключения¶
Общеплатформенные контроллеры MAY работать в выделенных системных namespace.
INF-PLT-003. Синхронизация времени и DNS¶
Уровень: MUST
Применяется к: узлам production-платформы
Узлы должны использовать контролируемую синхронизацию времени и разрешать корпоративные и кластерные DNS-имена. Платформа должна обнаруживать потерю синхронизации времени и недоступность кластерного DNS.
Обоснование¶
Ошибочное время и DNS нарушают TLS, координацию и диагностику.
Проверка¶
- измерение смещения времени на узлах;
- синтетический DNS-запрос из workload;
- тест alert при отказе.
Исключения¶
Не допускаются.
INF-PLT-004. Управляемые обновления платформы¶
Уровень: MUST
Применяется к: production-платформе
Владелец должен определить поддерживаемые версии, порядок обновления, предварительную проверку совместимости workload, способ восстановления и максимальный срок устранения неподдерживаемой версии.
Обоснование¶
Неуправляемое обновление или устаревание создаёт общий отказ приложений.
Проверка¶
- review последнего обновления и rehearsal восстановления;
- проверка версии относительно принятого диапазона.
Исключения¶
Не допускаются.
INF-PLT-005. Инвентаризация и декларативность¶
Уровень: MUST
Применяется к: конфигурации платформы
Воспроизводимая конфигурация платформы должна храниться в Git. Terraform, OpenTofu и Ansible MAY использоваться по INF-IAC, но не являются обязательными. Невоспроизводимое ручное изменение должно регистрироваться и переноситься в декларативный источник не позднее закрытия связанного change или incident.
Обоснование¶
История в Git уменьшает расхождение платформ и облегчает восстановление.
Проверка¶
- сопоставление работающей конфигурации с Git;
- review журнала административных изменений.
Исключения¶
Аварийное изменение допустимо по INF-OPS-002 и должно быть синхронизировано с
Git.
INF-PLT-006. Основание профиля high-availability¶
Уровень: MUST
Применяется к: платформе, размещающей production-цель
high-availability
Платформа должна сохранять Kubernetes API/control plane при отказе одного control-plane участника и сохранять ingress, DNS, доставку secrets и запуск stateless workload при отказе одного worker-узла. Если роли совмещены, должна проверяться потеря одного такого узла. Компоненты, основанные на quorum, должны сохранять quorum при заявленном отказе. Workload и его данные должны иметь независимые отказные домены, соответствующие этой модели.
Обоснование¶
Несколько реплик приложения не создают HA на одноузловой или однодоменной платформе.
Проверка¶
- контролируемый отказ каждого типа узла;
- проверка control plane, APISIX, DNS, secret delivery и scheduling;
- сопоставление topology с заявленной моделью отказа.
Исключения¶
Внешний компонент MAY обеспечивать функцию платформы, если его доступность и граница ответственности документированы.
INF-PLT-007. Восстановление платформы¶
Уровень: MUST
Применяется к: production Kubernetes-платформе
Должен существовать проверенный способ развернуть совместимую платформу заново и восстановить невоспроизводимое cluster state. Процедура должна определять порядок восстановления control plane, operators/CRD, secrets, storage, namespaced-ресурсов и workload. Backup etcd или иного datastore не заменяет отдельные backup данных приложений.
Обоснование¶
Git с manifests не содержит автоматически ключи, cluster state и данные.
Проверка¶
- восстановление в чистой тестовой платформе;
- измерение результата относительно platform RPO/RTO.
Исключения¶
Полностью воспроизводимое cluster state MAY не копироваться, если clean rebuild доказан в пределах RTO.
INF-PLT-008. Квоты и резерв платформы¶
Уровень: MUST
Применяется к: общей production-платформе
Namespace должен иметь ResourceQuota или эквивалентные границы CPU, memory, ephemeral storage, persistent storage и числа критичных объектов. Платформа должна сохранять измеряемый резерв для системных компонентов и восстановления workload после отказа узла.
Обоснование¶
Один потребитель не должен исчерпать общую ёмкость или заблокировать восстановление.
Проверка¶
- запрос quotas и allocatable/requested ресурсов;
- тест достижения квоты;
- расчёт размещения после отказа узла.
Исключения¶
Выделенный одноцелевой кластер MAY не иметь namespace quota, если имеет эквивалентные пределы на уровне узлов и storage.
INF-PLT-009. Admission policy production¶
Уровень: MUST
Применяется к: production Kubernetes-платформе
Admission control должен блокировать как минимум privileged containers, необоснованные host namespaces/hostPath, privilege escalation и workload без обязательных ресурсных границ. Policy должна версионироваться и проверяться до включения enforcement. Исключение должно ограничиваться точным namespace/workload, иметь владельца и срок.
Обоснование¶
CI-проверку можно обойти другим клиентом, а ошибочная общая admission policy может одновременно остановить все deployments.
Проверка¶
- негативный apply каждого запрещённого PodSpec;
- audit существующих исключений;
- dry-run policy на текущих workload перед обновлением.
Исключения¶
Bootstrap системного компонента MAY использовать отдельную policy с теми же ограничениями области и срока.
INF-PLT-010. Жизненный цикл self-managed узла¶
Уровень: MUST
Применяется к: Kubernetes-узлу, ОС и container runtime которого эксплуатирует владелец платформы
Владелец должен определить поддерживаемые версии ОС, kernel и container
runtime, численный максимальный срок установки security-обновления, а также
порядок drain, reboot, замены и восстановления узла. Обновление не должно
выполнять несогласованный reboot в обход INF-RES-004. Превышение срока
устранения неподдерживаемой или уязвимой версии должно создавать alert с
владельцем.
Обоснование¶
Поддерживаемая версия Kubernetes не устраняет уязвимость или несовместимость нижнего runtime и узловой ОС.
Проверка¶
- сопоставление inventory узлов с принятым диапазоном версий;
- rehearsal drain, reboot и замены узла;
- тест alert для версии за пределами срока обновления.
Исключения¶
Managed node service MAY выполнять жизненный цикл узла, если граница
ответственности по INF-PLT-001 и evidence провайдера подтверждают тот же
результат.
INF-PLT-011. Граница административного доступа к узлу¶
Уровень: MUST
Применяется к: self-managed Kubernetes-узлу
Административный доступ к ОС должен быть персональным и аудируемым. Общий
постоянный credential запрещён. Kubernetes API, kubelet API, container runtime
socket и административные порты узла должны быть доступны только объявленным
control-plane и административным сетевым источникам. Обычный workload не
должен получать доступ к runtime socket или credential узла; аварийный доступ
должен выполняться по INF-OPS-002.
Обоснование¶
Доступ к runtime или узлу позволяет обойти namespace, RBAC и secret-границы всех размещённых workload.
Проверка¶
- сетевой тест административных endpoint из разрешённой и запрещённой сети;
- проверка identity и audit события интерактивного доступа;
- негативный доступ обычного Pod к runtime socket и node credentials.
Исключения¶
Консоль восстановления провайдера MAY использоваться как персональный ограниченный по времени break-glass канал с тем же аудитом.