რესურსების დამგეგმავი და მანქანის სკეილინგი

მოკლე რეზიუმე

სტაბილური სკეილინგი ინახება ოთხ საყრდენზე:

1. სწორი მოთხოვნები/ლიმიტები და QoS კლასები.

2. სწორი სტილი (ტოპოლოგია, აფინიტები, პრიორიტეტები, წინასიტყვაობა).

3. მრავალ დონის სკეილინგი: HPA/VPA/KEDA + Cluster/Node autoscaler + warm pools.

4. SLO ორიენტირებული ლოგიკა (latency/queue depth) ანტივირუსული და ბიუჯეტებით.

რესურსების ძირითადი მოდელი

Requests/Limits და QoS კლასები

Requests = გარანტიები დამგეგმავისთვის; Limits = ჭერი runtime.
QoS: Guaranteed (req = lim CPU/Memory), Burstable (ნაწილობრივ), BestEffort (არაფერი).
წარმოების სერვისები მძიმე SLO - Guaranteed/Burstable; ფონი - Burstable/BestEffort.

CPU/მეხსიერება/IO/ქსელი

CPU - ელასტიური (დრო), მეხსიერება - მკაცრი (OOM-kill ჭარბი).
IO/ქსელში ცალკე განათავსეთ ლიმიტები/პრიორიტეტები (cgroups/TC), წინააღმდეგ შემთხვევაში „ხმაურიანი მეზობლები“.

GPU/ამაჩქარებლები

მოითხოვეთ ვექტორული (GPU = 1, VRAM პროფილების საშუალებით), გამოიყენეთ nodeSelector/taints და PodPriority კრიტიკისთვის.
ინვესტიციისთვის - batch size და გათბობის მოდელები.

Scheduling პოლიტიკოსები

პრიორიტეტები, წინასწარი ემისია და PDB

PriorityClass კრიტიკული გზებისთვის (გადახდა, ლოგინი), ნებადართულია წინასწარი ემპაცია.
PodDisrupite Budget იცავს მინიმალურ შენიშვნებს ევაკუაციის/აპდეიტის დროს.

აფინიტი/ტოპოლოგია

node/pod affinity კოლონიზაციისთვის/დეკოლოკაციისთვის (მაგალითად, არ დააყენოთ შენიშვნები ერთ მასპინძელზე).
topologySpreadConstraints ათანაბრებს სუბსიდიებს ზონებში/AZ.
NUMA/ტოპოლოგია: pin-CPU/hugepages, სადაც დაბალი ლატენტობა მნიშვნელოვანია.

თეინტები და ტოლერანტები

გამოიკვლიეთ pulls: 'yshell', 'batch', 'gpu', 'system'. კრიტიკა უფრო მეტ მეზობელს მოითმენს.

ავტო სკეილინგი: დონე და სიგნალები

1) HPA (Horizontal Pod Autoscaler)

Skaylite skalites prektions: CPU/Memory/castomy (Prometheus Adapter).
კარგი სიგნალები: latency p95/p99, queue length/lag, RPS per pod, consumer lag.
Anti flapping: სტაბილიზაცია (stabilization Window), მინიმალური ნაბიჯი, cooldown.

HPA- ს მაგალითი:

yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: { name: api-hpa }
spec:
scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: api }
minReplicas: 6 maxReplicas: 120 behavior:
scaleUp:
stabilizationWindowSeconds: 60 policies: [{ type: Percent, value: 100, periodSeconds: 60 }]
scaleDown:
stabilizationWindowSeconds: 300 policies: [{ type: Percent, value: 20, periodSeconds: 60 }]
metrics:
- type: Pods pods:
metric:
name: http_server_request_duration_seconds_p95 target:
type: AverageValue averageValue: "0.25" # 250ms

2) VPA (Vertical Pod Autoscaler)

Tuninguet requests/limits რეალური მოხმარებისთვის (განაახლებს რეკომენდაციებს).
რეჟიმები: 'Off' (კოლექცია), 'Auto' (გადატვირთვა), 'Initial' (მხოლოდ დაწყებისთანავე).
პრაქტიკა: ჩართეთ 'Off', შეაგროვეთ სტატისტიკა და გამოიყენეთ გამოშვებისას.

3) KEDA/დამონტაჟებული სკეილინგი

რეაგირებს გარე სიგნალებზე: Kafka lag, SQS depth, Redis length, Prometheus.
იდეალურია მოვლენების/რიგების კონსიუმერებისთვის (EDA).

KEDA ScaledObject (Kafka lag):

yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: { name: consumer-scale }
spec:
scaleTargetRef: { name: txn-consumer }
minReplicaCount: 2 maxReplicaCount: 200 cooldownPeriod: 120 pollingInterval: 5 triggers:
- type: kafka metadata:
bootstrapServers: broker:9092 consumerGroup: tx-cg topic: payments lagThreshold: "10000"

4) Cluster/Node Autoscaler (CA) + Warm Pools

CA დასძენს/ასუფთავებს nods დეფიციტით/ჭარბი რაოდენობით.
Warm pools: წინასწარ გაცხელებული nods/მომზადებული სურათები (აჩქარებს cold start).
მწვერვალებისთვის - step-scaling და გაფართოებული minNodes წინასწარ.

რეაქციის სიჩქარე და დათბობა

რეაქციის SLO შეფერხება: წინა ფენა - 1-2 წუთი, ზურგჩანთები/BD - ცალკე და წინასწარ.
დათბობა: TLS/DNS/კონექტორები, მოდელების დატვირთვა, ქეში და JIT დათბობა.
Shadow დატვირთვა ღონისძიებამდე ჯადოსნური გზის „გადაზიდვისთვის“.

ანტი-ფლოპი და სტაბილურობა

ჰისტერეზი მეტრიკებზე, გაბრტყელება (იხ. საშუალო).
Windows stabilization HPA- ში, დიდი „scaleDown“ - ში.
Stape Skaling ნაცვლად „ხერხი“; შენიშვნების შეცვლის უფლება.
Budget skaling: შეზღუდეთ ტრეფიკის/რეპლიკების% წუთში.

დაკვირვება და SLO

საკვანძო SLI:

p95/99 latency, error rate, throughput, queue depth/lag, CPU/Memory saturation, pod pending time, node pressure.

ალერტა:

ზრდა pending pods, unschedulable მოვლენა, IP/ქვესახეების დეფიციტი, გამოსახულების გრძელი, evictions.
ტრეისი: tail-based sampling p99 კუდებზე, ჩვენ ვხედავთ ვიწრო ადგილებს skale- ის დროს.

FinOps: ელასტიურობის ღირებულება

მეტრიკი: $1000 RPS ,/ms p95 $ ,/$ რეზერვი.
მიქსი: on-demand + reserved + spot (არა-კრიტიკისთვის).
Skale- ის ბარიერი დაკავშირებულია შეცდომის ღირებულებასთან: ზოგჯერ სასარგებლოა warm რეზერვების შენარჩუნება.

სპეციფიკა iGaming/fintech

მატჩების/ტურნირების მწვერვალები: წინასწარ გაზარდეთ 'minReplicas' და minNodes, ჩართეთ warm pools და გაათბეთ ქეში/მოდელები.
გადახდის კონსუტერები: KEDA lag + idempotence, პროვაიდერების ლიმიტები (PSP), როგორც გარე დეგრადაციის გამომწვევი.
ანტიბოტი: ცალკე აუზი, წესების სწრაფი მასშტაბები, „ნაცრისფერი“ მარშრუტები.
მარეგულირებელი: PDB შესაბამისობის სერვისებში, პრიორიტეტები უფრო მაღალია, ვიდრე batch.

ჩეკის ფურცლები

დიზაინი

Requests/limits მოცემულია პროფილის მიხედვით; QoS შეირჩა.
PriorityClass, PDB, taints/tolerations და topologySpread - მორგებულია.
HPA SLO მეტრებში, არა მხოლოდ CPU.
VPA 'Off- ში რეკომენდაციების შეგროვების მიზნით (დაგეგმილია მიგრაცია' Auto ').
KEDA/ღონისძიების დატვირთვის ხაზები.
CA + warm pools, გამოსახულებები ქეშირებულია (გამოსახულების პრე-პული).

ოპერაცია

მითითებულია Windows და cooldowns (flapping გამორიცხულია).
ალერტები pending/unschedulable, lag, p95, error-rate.
Runbooks: „არ არსებობს ნოდი“, „სურათი არ ვრცელდება“, „OOM/evict“, „ქარიშხალი“.
Capacity მიმოხილვა ყოველთვიურად: skall- ის ფაქტი გეგმა/ღირებულება.

ტიპიური შეცდომები

HPA მხოლოდ CPU- სთვის არის lat რეგრესია IO/BD ლიმიტით.
PDB და კრიტიკის პრიორიტეტების არარსებობა პირველ რიგში წინასწარ განსაზღვრავს.
კრიტიკისა და ბატის ნაზავი ერთ აუზზე taints- ის გარეშე არის „ხმაურიანი მეზობლები“.
ნულოვანი დათბობა - ცივი სტარტები მწვერვალზე.
აგრესიული 'scaleDown' დალია და კონტეინერების thrash.
KEDA idempotent- ის გარეშე არის შეტყობინებების დუბლიკატები ქარიშხლის დროს.

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

1) პიკის მოვლენამდე (T-30 წუთი)

1. გაზარდეთ 'minReplicas '/minNodes, გააქტიურეთ warm pools.
2. გაათბეთ CDN/DNS/TLS/კონექტორები, ჩამოტვირთეთ მოდელები.
3. ჩართეთ „ნაცრისფერი“ მარშრუტები/ბოტების ლიმიტები.
4. შეამოწმეთ dashboards: pending/lag/p95.

2) unschedulable დეფიციტი

1. შეამოწმეთ CA, ღრუბლის კვოტები, ქვესახეები/IP.
2. დროებით შეამცირეთ batch- ის ლიმიტები, შეიტანეთ პრესა დაბალი პრიორიტეტებისთვის.
3. აიღეთ დროებით უფრო მაღალი ინსტანციის ტიპი ან მეორე აუზი.

3) ხაზის ზრდა

1. KEDA: scale up გამომწვევი; 2) აამაღლეთ კონსუტერის ლიმიტები;

2. ჩართეთ idempotence-keys და backpressure მწარმოებლები.

4) ხერხი

1. გაზარდეთ stabilization/cooldown; 2) გადავიდეთ ნაბიჯზე;

2. დაალაგეთ მეტრი ექსპონენციალური საშუალო.

ყალბი ყალბი ფურცლები

VPA (რეკომენდაციების შეგროვება):

yaml apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: { name: api-vpa }
spec:
targetRef: { apiVersion: "apps/v1", kind: Deployment, name: api }
updatePolicy: { updateMode: "Off" } # собираем рекомендации

Cluster Autoscaler (დროშის იდეები, კონცეფცია):


--balance-similar-node-groups
--expander=least-waste
--max-empty-bulk-delete=10
--scale-down-utilization-threshold=0.5
--scale-down-delay-after-add=10m

Topology spread (ერთგვაროვნება ზონების მიხედვით):

yaml topologySpreadConstraints:
- maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: { matchLabels: { app: api } }

შედეგი

ეფექტური განლაგება და მანქანის სკეილინგი არის სწორი მოთხოვნები/ლიმიტები + ჭკვიანი სტეილინგი + მრავალ დონის სკეილინგი (HPA/VPA/KEDA/CA) + დათბობა და ანტი-ფუფუნება, რომელიც უკავშირდება SLO- ს და მილიწამების ღირებულებას. დააფიქსირეთ პოლიტიკოსები IaC- ში, დააკვირდით „სწორ“ მეტრიკებს (latency/lag), შეინახეთ warm რეზერვი მწვერვალებისთვის - და პლატფორმა იქნება ელასტიური, პროგნოზირებადი და ეკონომიური.