Операции и Управление → Политики исполнения и runtime-ограничения
Политики исполнения и runtime-ограничения
1) Назначение
Runtime-политики делают поведение сервисов предсказуемым, безопасным и экономным: ограничивают «шумных соседей», предотвращают утечки и перегрев, обеспечивают комплаенс и удержание SLO при росте нагрузки.
Ключевые цели: изоляция, справедливое распределение ресурсов, контролируемая деградация, воспроизводимость, аудит.
2) Область охвата
Вычисления и память: CPU, RAM, GC-паузы, лимиты потоков.
Диск/хранилища: IOPS/throughput, квоты, fs-политики (read-only).
Сеть: egress/ingress, bandwidth shaping, network policies.
Процессы/системные вызовы: seccomp, capabilities, ulimit.
Оркестрация: Kubernetes QoS, requests/limits, приоритеты, taints/affinity.
API/шлюзы: rate-limits, квоты, таймауты/ретраи, circuit-breakers.
Данные/ETL/стримы: batch/stream concurrency, consumer lag budgets.
Безопасность: AppArmor/SELinux, rootless, секреты/кофиги.
Policy-as-Code: OPA/Gatekeeper, Kyverno, Conftest.
3) Базовые принципы
Fail-safe по умолчанию: лучше отбрасывать лишние запросы, чем падать.
Budget-driven: таймауты/ретраи вписываются в бюджет времени запроса и бюджет ошибок SLO.
Small blast radius: изоляция по namespace/пулу/узлу/шарду.
Declarative & auditable: все ограничения — в коде/репозитории + журнал изменений.
Multi-tenant fairness: никакой арендатори/команда не может «высосать» весь кластер.
4) Вычисления и память
4.1 Kubernetes и cgroup v2
requests/limits: requests гарантируют долю CPU/памяти; limits включают throttling/OOM-killer.
QoS классы: Guaranteed / Burstable / BestEffort — критичные ворклоады держим в Guaranteed/Burstable.
CPU: `cpu.shares`, `cpu.max` (throttle), CPuset для пиннинга.
Память: `memory.max`, `memory.swap.max` (обычно swap off), oom_score_adj для приоритета.
4.2 Паттерны
Headroom 20–30% на узле, anti-affinity для дублирования.
GC-лимиты: JVM `-Xmx` < k8s memory limit; Go: `GOMEMLIMIT`; Node: `--max-old-space-size`.
ulimit: `nofile`, `nproc`, `fsize` — по профилю сервиса.
5) Диск и хранилища
IOPS/Throughput квоты на PVC/кластер-storage; разделение журналов/данных.
Read-only root FS, tmpfs для временных файлов, ограничение размера `/tmp`.
FS-watchdog: алерты на заполнение томов и рост inode.
6) Сеть и трафик
NetworkPolicy (ingress/egress) — zero-trust east-west.
Bandwidth limits: tc/egress-policies, QoS/DSCP для критичных потоков.
Egress-контроллер: список разрешенных доменов/подсетей, audit DNS.
mTLS + TLS policies: шифрование и принудительная версия протокола.
7) Безопасность процесса
Seccomp (allowlist syscalls), AppArmor/SELinux профили.
Drop Linux capabilities (оставить минимум), `runAsNonRoot`, `readOnlyRootFilesystem`.
Rootless контейнеры, подписанные образы и attestations.
Secrets-only via Vault/KMS, tmp-tokens с коротким TTL.
8) Политики времени: таймауты, ретраи, бюджеты
Timeout budget: сумма всех hop’ов ≤ SLA энд-ту-энд.
Ретраи с backoff+джиттером, максимум попыток по классу ошибок.
Circuit-breaker: open при error%/timeout p95 выше порога → быстрые отказы.
Bulkheads: отдельные connection-pool’ы/очереди для критичных путей.
Backpressure: ограничение продюсеров по lag потребителей.
9) Rate-limits, квоты и приоритет
Алгоритмы: token/leaky bucket, GCRA; локальные + распределенные (Redis/Envoy/global).
Гранулярность: ключ API/пользователь/организация/регион/эндпойнт.
Градиенты приоритета: «платежные/авторизационные» потоки — gold, аналитика — bronze.
Квоты в сутки/месяц, «burst» и «sustained» лимиты; 429 + Retry-After.
10) Оркестрация и планировщик
PriorityClass: защита P1-подов от вытеснения.
PodDisruptionBudget: границы даунтайма при обновлениях.
Taints/Tolerations, (anti)Affinity — изоляция workloads.
RuntimeClass: gVisor/Firecracker/Wasm для песочниц.
Horizontal/Vertical autoscaling с гвард-порогами и max-replicas.
11) Политики данных/ETL/стримов
Concurrency per job/topic, max batch size, checkpoint интервал.
Consumer lag budgets: warning/critical; DLQ и лимит ретраев.
Freshness SLA для витрин, пауза тяжелых джобов при пиках прод-трафика.
12) Policy-as-Code и admission-контроль
OPA Gatekeeper/Kyverno: запрет подов без requests/limits, без `readOnlyRootFilesystem`, с `hostNetwork`, `:latest`.
Conftest для pre-commit проверок Helm/K8s/Terraform.
Mutation policies: автодобавление sidecar (mTLS), аннотаций, seccompProfile.
yaml apiVersion: kyverno. io/v1 kind: ClusterPolicy metadata:
name: require-resources spec:
validationFailureAction: Enforce rules:
- name: check-limits match:
resources:
kinds: ["Pod"]
validate:
message: "We need resources. requests/limits for CPU and memory"
pattern:
spec:
containers:
- resources:
requests:
cpu: "?"
memory: "?"
limits:
cpu: "?"
memory: "?"rego package policy. timeout
deny[msg] {
input. kind == "ServiceConfig"
input. timeout_ms> 800 msg: = sprintf ("timeout% dms exceeds budget 800ms," [input. timeout_ms])
}13) Наблюдаемость и метрики соблюдения
Compliance %: доля подов с корректными requests/limits/labels.
Security Posture: доля подов с seccomp/AppArmor/rootless.
Rate-limit hit%, shed%, throttle%, 429 share.
p95 таймаутов/ретраев, circuit-open duration.
OOM kills/evictions, CPU throttle seconds.
Network egress denied events, egress allowlist misses.
14) Чек-листы
Перед выкладкой сервиса
- Прописаны requests/limits; QoS ≥ Burstable
- Таймауты и ретраи вписываются в end-to-end SLA
- Circuit-breaker/bulkhead включены для внешних зависимостей
- NetworkPolicy (ingress/egress) и mTLS
- Seccomp/AppArmor, drop capabilities, non-root, read-only FS
- Rate-limits и квоты на API-шлюзе/сервисе
- PDB/priority/affinity заданы; autoscaling настроен
Ежемесячно
- Аудит policy-исключений (TTL)
- Пересмотр бюджетов времени/ошибок
- Тест деградации (fire-drill): shed/backpressure/circuit-breaker
- Ротация секретов/сертификатов
15) Анти-паттерны
Без requests/limits: «бурст» съедает соседей → каскадные сбои.
Глобальные ретраи без джиттера: шторм у зависимостей.
Бесконечные таймауты: «висящие» коннекты и исчерпание пулов.
`:latest` и mutable теги: непредсказуемые runtime-сборки.
Открытый egress: утечки и неуправляемые зависимости.
Отсутствие PDB: обновления «выбивают» весь пул.
16) Мини-плейбуки
А. Всплеск CPU throttle% у payments-service
1. Проверить limits/requests и профилировать горячие пути.
2. Временно поднять requests, включить автоскейл по p95 latency.
3. Включить кэш-фоллбэк лимитов/курсов, снизить сложность запросов.
4. Пост-фикс: денормализация/индексы, пересмотр limits.
Б. Рост 429 и жалобы на API
1. Отчет по ключам/организациям → кто уперся в квоту.
2. Ввести hierarchical quotas (per-org→per-key), поднять burst для gold.
3. Коммуникация и guidance по backoff; включить adaptive limiting.
В. Массовые OOM kills
1. Снижение concurrency, включить heap-лимит и профилирование.
2. Пересчитать Xmx/GOMEMLIMIT под реальные peak-usage.
3. Переобучить GC/пулы, добавить swap-off и soft-limit алерты.
17) Примеры конфигураций
K8s контейнер с безопасными настройками (фрагмент):yaml securityContext:
runAsNonRoot: true allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities:
drop: ["ALL"]yaml rate_limit_policy:
actions:
- request_headers:
header_name: "x-api-key"
descriptor_key: "api_key"yaml nginx. ingress. kubernetes. io/proxy-connect-timeout: "2s"
nginx. ingress. kubernetes. io/proxy-read-timeout: "1s"
nginx. ingress. kubernetes. io/limit-rps: "50"18) Интеграция с управлением изменениями и инцидентами
Любое ослабление политики — через RFC/CAB и временное исключение с TTL.
Инциденты по нарушениям политик → пост-мортем и обновление правил.
Дашборды соответствия (compliance) подключены к релизному календарю.
19) Итог
Политики исполнения — это «перила» для платформы: они не мешают ехать быстро, они не дают упасть. Декларативные ограничения, автоматическое принуждение, хорошие метрики и дисциплина исключений превращают хаотичную эксплуатацию в управляемую и предсказуемую систему — с контролируемой стоимостью и устойчивыми SLO.