Ресурсы, масштабирование и доступность¶
Требования применяются к ёмкости, отказоустойчивости и ресурсным границам
production-целей и общей Kubernetes-платформы. Уровни обязательности определены
в корневом README.md.
INF-RES-001. Проверяемая ёмкость¶
Уровень: MUST
Применяется к: production-цели
Requests, limits, число экземпляров и ёмкость зависимостей должны опираться на
измеренную нагрузку либо явно ограниченную модель использования. Владелец
должен определить признаки насыщения и запас по
architecture:OPS-CAP-001–OPS-CAP-003; инфраструктура должна доказать, что
workload размещается с этими границами и не вытесняет системные компоненты.
Обоснование¶
Произвольные лимиты вызывают вытеснение, throttling или неэффективный резерв.
Проверка¶
- нагрузочный тест или анализ production-метрик;
- проверка alert на насыщение.
Исключения¶
Новая система MAY использовать временную оценку со сроком пересмотра.
INF-RES-002. High-availability workload¶
Уровень: MUST
Применяется к: stateless workload профиля high-availability
Workload должен иметь не менее двух реплик, распределение между доступными узлами через topology spread или anti-affinity и PodDisruptionBudget, сохраняющий минимально доступную ёмкость. Все синхронные зависимости на критичном пути должны переживать ту же заявленную модель отказа либо деградировать способом, сохраняющим заявленный пользовательский результат.
Обоснование¶
Несколько реплик на одном узле не защищают от отказа узла.
Проверка¶
- drain каждого подходящего узла;
- запрос размещения Pod и PDB.
Исключения¶
Кластер с единственным узлом не может заявлять HA для этого workload.
INF-RES-003. Автоматическое масштабирование¶
Уровень: SHOULD
Применяется к: переменной нагрузке профиля high-availability
Проекту следует использовать Horizontal Pod Autoscaler или эквивалент по метрике, отражающей насыщение. Минимум, максимум, target и поведение scale-down следует задать явно.
Обоснование¶
Ограниченное масштабирование адаптирует ёмкость без неконтролируемого роста.
Проверка¶
- нагрузочный тест scale-up и последующего scale-down;
- тест достижения максимума и alert насыщения.
Исключения¶
Фиксированная ёмкость допустима при доказанном запасе и известном потолке.
INF-RES-004. Плановый disruption¶
Уровень: MUST
Применяется к: production Kubernetes-платформе
Обновление и обслуживание узлов должны учитывать PDB, постоянные тома и достаточную ёмкость для переноса workload. Процедура не должна принудительно обходить PDB без зарегистрированного решения.
Обоснование¶
Плановое обслуживание не должно становиться общим отказом.
Проверка¶
- rehearsal drain;
- проверка событий scheduling и volume attach.
Исключения¶
Аварийное удаление отказавшего узла MAY обойти обычный порядок.
INF-RES-005. Проверяемая модель отказа¶
Уровень: MUST
Применяется к: production-цели high-availability
Manifest failure_tolerance и операционный README должны назвать отказы,
которые цель обязана пережить без нарушения SLO: как минимум потерю одного
worker-узла. Проверка должна включать workload, ingress, secrets, storage и
критичные data services. Формулировка high-availability без модели отказа и
результата запрещена.
Обоснование¶
HA не является проверяемым свойством без заданного отказа и наблюдаемого результата.
Проверка¶
- fault test заявленной модели под репрезентативной нагрузкой;
- измерение SLI и recovery time.
Исключения¶
Не допускаются.
INF-RES-006. Single-instance как ограничение¶
Уровень: MUST
Применяется к: production-цели single-instance
Dashboard, SLO и runbook должны учитывать недоступность при отказе экземпляра, узла и плановом deployment. Документация и интерфейс не должны заявлять автоматическое failover или HA, которого цель не обеспечивает.
Обоснование¶
Явное ограничение предотвращает ложные ожидания потребителя.
Проверка¶
- review SLO, runbook и пользовательской документации;
- измерение восстановления после удаления экземпляра.
Исключения¶
Не допускаются.
INF-RES-007. Защита от eviction и pressure¶
Уровень: MUST
Применяется к: production Kubernetes workload
Workload должен иметь наблюдаемую QoS class, предел ephemeral storage и приоритет, соответствующий критичности. Платформа должна alert на memory, disk, PID и inode pressure до массового eviction. PriorityClass не должна позволять обычному приложению вытеснять критичные системные компоненты.
Обоснование¶
Дисковое и process pressure вызывают отказ даже при достаточных CPU и memory.
Проверка¶
- запрос QoS/PriorityClass и limits;
- контролируемое pressure в non-production;
- проверка порядка eviction и alert.
Исключения¶
PriorityClass MAY отсутствовать в выделенном одноцелевом кластере.
INF-RES-008. Ёмкость горизонтального масштабирования¶
Уровень: MUST
Применяется к: production Kubernetes workload с автоматическим горизонтальным масштабированием
Платформа должна обеспечивать размещение заданного максимума реплик либо
посредством измеренного allocatable-резерва, либо посредством автоматического
увеличения ёмкости узлов. Расчёт должен учитывать requests workload,
системный резерв, topology constraints, volumes и одновременное
масштабирование других workload в заявленной нагрузочной модели по
architecture:OPS-CAP-001.
Для автоматического увеличения узлов должны быть численно заданы максимальное
время до schedulable-ёмкости, предел узлов или ресурсов, применимые quotas и
поведение при достижении каждого предела. Создание реплики в состоянии
Pending не должно считаться успешным scale-up. Платформа должна наблюдать
причину и возраст unschedulable replicas, достижение предела node pool или
quota и ошибку механизма увеличения ёмкости.
Обоснование¶
Horizontal Pod Autoscaler не добавляет ёмкость узлов; запрос дополнительных реплик без возможности размещения не восстанавливает насыщенный workload.
Проверка¶
- нагрузочный тест scale-up до заявленного максимума реплик;
- измерение времени от решения о scale-up до готовой schedulable-реплики;
- тест недостаточной ёмкости, предела node pool и quota;
- проверка alerts для возраста unschedulable replicas и ошибки autoscaler.
Исключения¶
Автоматическое увеличение узлов MAY отсутствовать, если измеренный allocatable-резерв размещает максимальные реплики всех одновременно масштабирующихся workload и это проверяется после изменения requests или topology.
INF-RES-009. Масштабирование фоновой обработки¶
Уровень: MUST
Применяется к: автоматически масштабируемому consumer или worker, обрабатывающему сохраняемую очередь либо поток
Сигнал scale-up должен отражать объём или возраст необработанной работы и учитывать скорость поступления относительно подтверждённой скорости обработки. Максимум реплик и concurrency должен учитывать число независимо обрабатываемых partitions или leases, пределы downstream-зависимостей, хранилища и broker quotas.
Scale-down не должен терять или оставлять без восстановления принятую работу: экземпляр должен прекратить получение новой работы, завершить либо безопасно вернуть незавершённую работу и подтвердить только фактически завершённый результат. Scale-to-zero MAY использоваться, только если механизм активации и измеренный cold start укладываются в максимальный допустимый возраст работы.
Обоснование¶
CPU не всегда отражает рост backlog, а увеличение consumers сверх параллелизма очереди или ёмкости downstream только переносит насыщение и усиливает отказ.
Проверка¶
- нагрузочный тест burst, устойчивого backlog и восстановления после пика;
- тест достижения предела partitions, downstream или quota;
- scale-down во время долгой обработки с проверкой подтверждения и повтора;
- измерение активации из нуля относительно допустимого возраста работы.
Исключения¶
Фиксированное число consumers MAY использоваться при доказанном запасе для пиковой скорости и alert до достижения максимального допустимого возраста работы.