برنامه ریز منابع و مقیاس خودکار

خلاصه ای کوتاه

مقیاس بندی پایدار در چهار پشتیبانی پشتیبانی می شود:

1. درخواست ها/محدودیت ها و کلاس های QoS را اصلاح کنید.

2. انباشت صحیح (توپولوژی، میل، اولویت ها، پیشگیری).

3. مقیاس خودکار چند سطح: HPA/VPA/KEDA + خوشه/گره خودکار + استخر گرم.

4. منطق SLO گرا (عمق تاخیر/صف) با ضد flapping و بودجه.

مدل منابع پایه

درخواست ها/محدودیت ها و کلاس های QoS

درخواست ها = تضمین برای زمانبندی ؛ محدودیت = سقف برای زمان اجرا.
QoS: تضمین شده (req = lim توسط CPU/حافظه)، Burstable (تا حدی)، BestEffort (هیچ چیز).
خدمات تولید با SLO های سخت - تضمین شده/Burstable ؛ پس زمینه - Burstable/BestEffort.

پردازنده/حافظه/IO/شبکه

CPU - الاستیک (به اشتراک گذاری زمان)، حافظه - سخت (OOM کشتن اگر بیش از حد).
در IO/شبکه، محدودیت ها/اولویت ها را به طور جداگانه (cgroups/TC) تنظیم کنید، در غیر این صورت «همسایگان پر سر و صدا».

GPU/شتاب دهنده ها

درخواست بردار (GPU = 1، VRAM از طریق پروفایل)، استفاده از nodeSelector/tains و PodPriority برای انتقاد.
برای استنتاج - اندازه دسته ای و حرارت مدل.

سیاست های برنامه ریزی

اولویت ها، پیشگیری و PDB

PriorityClass برای مسیرهای بحرانی (پرداختها، ورود)، پیشدستی مجاز است.
PodDisruptionBudget حداقل نشانه ها را در هنگام تخلیه/به روز رسانی محافظت می کند.

وابستگی/توپولوژی

وابستگی گره/غلاف برای colocation/decolocation (به عنوان مثال، کپی را در یک میزبان قرار ندهید).
topologySpreadConstraints تراز hearths به/مناطق AZ.
NUMA/توپولوژی: پین CPU/hugepages که در آن تاخیر کم مهم است.

فنجان چای و تحمل

استخرهای جداگانه: «prod»، «batch»، «gpu»، «system». انتقاد باعث می شود همسایگان کمتری داشته باشند.

مقیاس خودکار: سطوح و سیگنال ها

1) HPA (افقی غلاف خودکار)

مقیاس کپی از غلاف توسط معیارهای: CPU/حافظه/سفارشی (آداپتور Prometheus).
سیگنال های خوب: تاخیر p95/p99، طول صف/تاخیر، RPS در هر غلاف، تاخیر مصرف کننده.
ضد ضربه زدن: تثبیت کننده (تثبیت کننده پنجره)، حداقل مرحله، 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 (عمودی غلاف خودکار)

درخواست آهنگ/محدودیت برای مصرف واقعی (به روز رسانی توصیه).
حالت ها: «خاموش»، «خودکار» (راه اندازی مجدد)، «اولیه» (فقط در شروع).
تمرین: روشن کردن «خاموش» → جمع آوری آمار → درخواست برای انتشار.

3) مقیاس بندی مبتنی بر KEDA/صف

به سیگنال های خارجی واکنش نشان می دهد: تاخیر کافکا، عمق SQS، طول Redis، Prometheus.
ایده آل برای مصرف کنندگان رویداد/صف (EDA).

KEDA ScaledObject (تاخیر کافکا):

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) خوشه/گره Autoscaler (CA) + استخرهای گرم

CA گره ها را در کمبود/بیش از حد اضافه/حذف می کند.
استخرهای گرم: گره های پیش گرم شده/تصاویر آماده شده (سرعت شروع سرد).
برای قله - گام به مقیاس و minNodes بزرگ در پیش است.

میزان واکنش و گرم شدن

تاخیر واکنش SLO: لایه جلو ≤ 1-2 دقیقه، backends/DB - به طور جداگانه و در پیشبرد.
گرم کردن: TLS/DNS/اتصالات، مدل های بارگیری، گرم کردن حافظه پنهان و JIT.
بار سایه برای «پمپاژ» مسیر سرد به رویداد.

ضد ضربه و ثبات

هیسترزیس در معیارها، صاف کردن (exp. medium).
پنجره های تثبیت در HPA، بزرگ در «scaleDown».
گام به گام به جای «دیدم» ؛ محدودیت نرخ برای تغییر کپی.
مقیاس بودجه: محدود کردن درصد ترافیک/کپی اضافه شده در هر دقیقه.

قابلیت مشاهده و SLO

SLI های کلیدی:

p95/99 تاخیر، نرخ خطا، توان، عمق صف/تاخیر، CPU/اشباع حافظه، غلاف در انتظار زمان، فشار گره.

هشدارها:

رشد غلاف در انتظار، حوادث غیر قابل برنامه ریزی، کمبود IP/زیر شبکه، کشش تصویر طولانی، اخراج.
مسیرهای پیاده روی: نمونه برداری مبتنی بر دم در دم p99 → ما می بینیم تنگناها زمانی که پوسته پوسته شدن.

FinOps: هزینه کشش

معیارها: $/1000 RPS، $/ms p95، $/ساعت رزرو.
مخلوط: بر اساس تقاضا + رزرو شده + نقطه (برای غیر انتقاد).
آستانه مقیاس خودکار مربوط به هزینه خطا است: گاهی اوقات سودآور است که سهام گرم را حفظ کند.

ویژگی برای iGaming/fintech

قله های مسابقه/مسابقات: از قبل «minReplicas» و minNodes را بالا ببرید، استخرهای گرم را روشن کنید و کش ها/مدل ها را گرم کنید.
مصرف کنندگان پرداخت: KEDA با تاخیر + idemotency، محدودیت ارائه دهنده (PSP) به عنوان عوامل خارجی تخریب.
Antibot: یک استخر جداگانه، مقیاس سریع قوانین، مسیرهای «خاکستری».
نظارتی: PDB برای خدمات انطباق، اولویت ها بالاتر از دسته ای است.

بررسی برگه ها

طراحی سایت

درخواست ها/محدودیت های مشخص شده توسط داده های پروفایل ؛ QoS انتخاب شده است.
PriorityClass، PDB، tains/tolerations و topologySpread - پیکربندی شده است.
HPA توسط معیارهای SLO، نه فقط CPU.
VPA به «خاموش» برای جمع آوری توصیه ها (مهاجرت به «خودکار» برنامه ریزی شده است).
صفهای بارگذاری KEDA/رویداد.
CA + استخر گرم، تصاویر ذخیره شده (تصویر قبل از کشش).

عملیات اجرایی

پنجره تثبیت و cooldowns تنظیم می شوند (flapping حذف).
هشدار به در انتظار/unschedulable، تاخیر، p95، خطا نرخ.
Runbooks: «بدون گره»، «تصویر کشش ندارد»، «OOM/اخراج»، «طوفان retray».
ظرفیت بررسی ماهانه: واقعیت مقیاس در مقابل برنامه/هزینه.

اشتباهات رایج

HPA فقط توسط CPU → lat-regression با محدودیتهای IO/پایگاه داده.
فقدان PDB و اولویت ها، انتقاد اول خواهد بود.
مخلوط کردن انتقاد و دسته ای در همان استخر بدون tains → «همسایگان پر سر و صدا».
صفر گرمایش → سرد در اوج شروع می شود.
تهاجمی «scaleDown» → ظروف اره و شلاق.
KEDA بدون idemotency → پیام های تکراری در طوفان.

کتاب های کوچک

1) قبل از رویداد اوج (T-30 دقیقه)

1. «minReplicas »/minNodes را افزایش دهید، استخرهای گرم را فعال کنید.
2. گرم کردن CDN/DNS/TLS/اتصالات، مدل های بار.
3. شامل مسیرهای خاکستری/محدودیت برای رباتها.
4. داشبورد را بررسی کنید: انتظار/تاخیر/p95.

2) کمبود گره (غیر قابل برنامه ریزی)

1. CA، سهمیه های ابر، زیر شبکه ها/IP را بررسی کنید.
2. به طور موقت محدودیت های دسته ای را کاهش می دهد، پیش فرض را برای اولویت های پایین فعال می کند.
3. بالا بردن یک نوع نمونه به طور موقت بزرگتر و یا استخر دوم.

3) رشد تاخیر در صف

1. KEDA: مقیاس بالا توسط ماشه ؛ 2) افزایش محدودیت های مصرف کننده ؛

2. فعال کردن کلید های idempotency و تولید کنندگان فشار پس زمینه.

4) کپی اره

1. افزایش ثبات/خنک کننده ؛ 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" } # собираем рекомендации

خوشه 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

گسترش توپولوژی:

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

نتیجه گیری

زمانبندی کارآمد و مقیاس بندی خودکار، درخواست ها/محدودیت های صحیح + انباشت هوشمند + مقیاس بندی چند سطحی (HPA/VPA/KEDA/CA) + گرم شدن و ضد فلاپ، با SLO و هزینه میلی ثانیه گره خورده است. سیاست های ثابت در IaC، با معیارهای «صحیح» (تاخیر/تاخیر)، نگه داشتن سهام گرم تحت قله - و پلت فرم الاستیک، قابل پیش بینی و مقرون به صرفه خواهد بود.