Базовый контракт платформы¶
Требования применяются к 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 с теми же ограничениями области и срока.