Операції та Управління → Політики виконання та 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.