ოპერაციები და აღსრულებისა და რუნტიმის პოლიტიკის ოფისი

აღსრულებისა და რუნტიმის შეზღუდვების პოლიტიკა

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, კვოტები, taimauts/retrai, circuit-breakers.
მონაცემები/ETL/ნაკადები: batch/stream concurrence, consumer lag budgets.
უსაფრთხოება: AppARmor/SELinux, rootless, საიდუმლოებები/კოპიგები.
Policy-as-Code: OPA/Gatekeeper, Kyverno, Conftest.

3) ძირითადი პრინციპები

Fail-safe ნაგულისხმევი: უმჯობესია გადააგდოთ დამატებითი მოთხოვნები, ვიდრე დაეცემა.
Budget-driven: Timauts/retrais ჯდება მოთხოვნის დროისა და SLO შეცდომების ბიუჯეტის ბიუჯეტში.
მცირე 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 pinining.
მეხსიერება: "მეხსიერება. 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`.
ულიმიტი: 'nofile', 'nproc', 'fsize' - მომსახურების პროფილის მიხედვით.

5) დისკი და საცავი

IOPS/Throughput კვოტები PVC/კასეტა-სცენაზე; ჟურნალების/მონაცემების გამიჯვნა.
Read-only root FS, tmpfs დროებითი ფაილებისთვის, ზომა '/tmp 'შეზღუდვა.
FS-watchdog: ალერტები ტომების შევსებისა და ინტერესის ზრდისთვის.

6) ქსელი და ტრაფიკი

NetworkPolicy (ingress/egress) — zero-trust east-west.
Bandwidth limits: tc/egress-policies, QoS/DSCP კრიტიკული ნაკადებისთვის.
Egress კონტროლერი: ნებადართული დომენების/ქვესათაურების სია, audit DNS.
mTLS + TLS პოლიტიკა: პროტოკოლის დაშიფვრა და იძულებითი ვერსია.

7) პროცესის უსაფრთხოება

Seccomp (allowlist syscalls), Apparmor/SELinux პროფილები.
Drop Linux capabilities (დატოვეთ მინიმალური), 'runAsNonRoot', 'readOnlyRootFilesystem'.
Rootless კონტეინერები, ხელმოწერილი სურათები და ატესტატები.
Secrets-only via Vault/KMS, tmp-tokens მოკლე TTL.

8) დროის პოლიტიკა: ტაიმაუტები, რეტრაები, ბიუჯეტები

Timeout budget: ყველა ჰოპის ჯამი - SLA და tu.
Retrai ერთად backoff + jitter, შეცდომების კლასის მაქსიმალური მცდელობები.
Circuit-breaker: Open error %/timeout p95 უფრო მაღალია, ვიდრე ზღურბლზე - სწრაფი უარი.
Bulkheads: ცალკეული კავშირი-აუზი/ხაზები კრიტიკული ბილიკებისთვის.
Backpressure: მწარმოებლების შეზღუდვა მომხმარებლებზე lag.

9) კვოტები და პრიორიტეტები

ალგორითმები: token/leaky bucket, GCRA; ადგილობრივი + განაწილებულია (Redis/Envoy/global).
მარცვალი: API გასაღები/მომხმარებელი/ორგანიზაცია/რეგიონი/ენდოპოინტი.
პრიორიტეტის გრადიენტები: „გადახდის/ავტორიზაციის“ ნაკადები - ოქროს, ანალიტიკა - bronze.
კვოტები დღეში/თვეში, „burst“ და „sustained“ შეზღუდვები; 429 + Retry-After.

10) ორკესტრი და დამგეგმავი

PriorityClass: P1 პოდების დაცვა გადაადგილებისგან.
PodDisrupite Budget: განახლებების დროს downthim- ის საზღვრები.
Taints/Tolerations, (anti) Affinity - სამუშაო ადგილების იზოლაცია.
RuntimeClass: gVisor/Firecracker/Wasm ქვიშის ყუთებისთვის.
Horizontal/Vertical autoscaling gard-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', 'host Network', ': latest'.
Conftest pre commit შემოწმებისთვის Helm/K8s/Terraform.
Mutation policies: sidecar (mTLS) მანქანის წარმოება, მენიუ, secompProfile.

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 timaute/retrais, circuit ღია 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
• API კარიბჭის/მომსახურების კვოტები
• PDB/priority/affinity მოცემულია; autoscaling

ყოველთვიურად

• გამოკითხვის გამოკითხვა (TTL)
• დროის/შეცდომების ბიუჯეტების გადასინჯვა
• დეგრადაციის ტესტი: shed/backpressure/circuit-breaker

საიდუმლოების/სერთიფიკატების როტაცია

15) ანტი შაბლონები

Requests/limits- ის გარეშე: „ბურსტი“ ჭამს მეზობლებს კასკადის გაუმართაობებს.
გლობალური რეაგირება ჯიტერის გარეშე: ქარიშხალი დამოკიდებულებაში.
გაუთავებელი ტაიმაუტები: „ჩამოკიდებული“ კონექტორები და ტყვიების ამოწურვა.
': latest' და mutable ჭდეები: არაპროგნოზირებადი runtime შეკრება.
ღია გაჟონვა: გაჟონვა და უკონტროლო დამოკიდებულება.
PDB- ის არარსებობა: განახლებები „დაარტყა“ მთელ აუზს.

16) მინი ფლეიბუკები

ა. ასწია CPU throttle% payments სერვისში

1. შეამოწმეთ limits/requests და შეამოწმეთ ცხელი ბილიკები.
2. დროებით გაზარდეთ requests, ჩართეთ ავტო სკეიტი p95 ლატენტით.
3. ჩართეთ ლიმიტების/კურსების ქეში-ფოლბეკი, შეამციროთ მოთხოვნის სირთულე.
4. პოსტფიქსი: დენორმალიზაცია/ინდექსები, ლიმიტის გადასინჯვა.

B. Rost 429 და საჩივრები API- ს შესახებ

1. ანგარიში კლავიშებზე/ორგანიზაციებზე, რომლებიც კვოტას ეყრდნობიან.
2. შეიყვანეთ hierarchical 5.tas (per-org-per-key), აამაღლეთ burst გოლდისთვის.
3. კომუნიკაცია და guidance backoff- ისთვის; ჩართეთ adaptive limiting.

ვ. მასობრივი OOM kills

1. Concurrency შემცირება, ჩართეთ heap ლიმიტი და პროფილირება.
2. გადაანგარიშეთ Xmx/GOMEMLIMIT რეალური საკუთრების ქვეშ.
3. გადამზადება GC/puls, დაამატეთ swap-off და რბილი ლიმიტი ალერტები.

17) კონფიგურაციის მაგალითები

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- სთან.
პოლიტიკოსის დარღვევების ინციდენტები პოსტ-შურისმაძიებელი და წესების განახლება.
შესაბამისობის დაშბორდები უკავშირდება გამოშვებულ კალენდარს.

19) შედეგი

აღსრულების პოლიტიკოსები პლატფორმისთვის „მოაჯირია“: ისინი ხელს არ უშლიან სწრაფად წასვლას, ისინი არ დაეცემა. დეკლარაციული შეზღუდვები, ავტომატური იძულება, კარგი მეტრიკა და გამონაკლისის დისციპლინა ქაოტურ ოპერაციას კონტროლირებად და პროგნოზირებად სისტემად აქცევს - კონტროლირებადი ღირებულებით და სტაბილური SLO.