Kaynak Planlayıcı ve Otomatik Ölçekleme

Kısa özet

1. Doğru istek/limit ve QoS sınıfları.

2. Doğru istifleme (topoloji, yakınlık, öncelikler, ön hazırlık).

3. Çok seviyeli otomatik ölçekleme: HPA/VPA/KEDA + Cluster/Node autoscaler + sıcak havuzlar.

4. Kanat çırpma önleyici ve bütçeli SLO yönelimli mantık (gecikme/kuyruk derinliği).

Temel kaynak modeli

İstekler/Sınırlar ve QoS Sınıfları

İstekler = zamanlayıcı için garantiler; Limitler = çalışma zamanı için tavanlar.
QoS: Garantili (req = CPU/Bellek tarafından lim), Burstable (kısmen), BestEffort (hiçbir şey).
Sert SLO'larla üretim hizmetleri - Garantili/Burstable; Arka plan - Burstable/BestEffort.

CPU/Bellek/IO/Ağ

CPU - elastik (zaman paylaşımı), bellek - sabit (aşılırsa OOM-kill).
IO/ağda, sınırları/öncelikleri ayrı ayrı ayarlayın (cgroups/TC), aksi takdirde "gürültülü komşular".

GPU/Hızlandırıcılar

Vektöre sorun (GPU = 1, profiller aracılığıyla VRAM), eleştiri için nodeSelector/tains ve PodPriority kullanın.
Çıkarım için - parti boyutu ve model ısıtma.

Zamanlama Politikaları

Öncelikler, ön hazırlık ve PDB

Kritik yollar için PriorityClass (ödemeler, giriş), önizlemeye izin verilir.
PodDisruptionBudget, tahliye/güncellemeler sırasında minimum ipuçlarını korur.

Yakınlık/Topoloji

Kolokasyon/dekolokasyon için düğüm/pod afinitesi (örneğin, kopyaları bir ana bilgisayara koymayın).
TopologySpreadConditions, ocakları/AZ bölgelerine hizalar.
NUMA/topoloji: Düşük gecikmenin önemli olduğu pin-CPU/hugepages.

Teyintler ve toleranslar

Ayrı havuzlar: 'prod', 'batch', 'gpu', 'system'. Eleştiri daha az komşuya dayanır.

Otomatik ölçekleme: seviyeler ve sinyaller

1) HPA (Yatay Pod Autoscaler)

Kapsüllerin kopyalarını metriklere göre ölçeklendirin: CPU/Bellek/özel (Prometheus Adaptörü).
İyi sinyaller: gecikme p95/p99, kuyruk uzunluğu/gecikme, pod başına RPS, tüketici gecikmesi.
Anti-çırpma: stabilizasyon (stabilizasyonPencere), minimum adım, dolum süresi.

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 (Dikey Pod Autoscaler)

Gerçek tüketim için istekleri/sınırları ayarlar (güncelleme önerileri).
Modlar: 'Kapalı', 'Otomatik' (yeniden başlatma), 'İlk' (yalnızca başlangıçta).
Uygulama: 'Kapalı'yı açın - istatistik toplayın - bültenlere uygulanır.

3) KEDA/kuyruk tabanlı ölçekleme

Dış sinyallere tepki verir: Kafka gecikmesi, SQS derinliği, Redis uzunluğu, Prometheus.
Etkinlik/Kuyruk Tüketicileri (EDA) için idealdir.

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) Küme/Düğüm Autoscaler (CA) + Sıcak Havuzlar

CA, eksiklik/fazlalıktaki düğümleri ekler/kaldırır.
Sıcak havuzlar: önceden ısıtılmış düğümler/hazırlanmış görüntüler (soğuk başlangıcı hızlandırın).
Zirveler için - önceden adım ölçekleme ve büyütülmüş minNodes.

Reaksiyon hızı ve ısınma

SLO reaksiyon gecikmesi: ön katman ≤ 1-2 dakika, arka uçlar/DB - ayrı ayrı ve önceden.
Isınma: TLS/DNS/bağlantıları, yükleme modelleri, önbellek ısınma ve JIT.
Olayın soğuk yolunu "pompalamak" için gölge yükü.

Anti-çırpma ve stabilite

Metriklerde histerezis, yumuşatma (exp. medium).
HPA'da sabitleme pencereleri, 'scaleDown'da büyük.
"Testere" yerine adım ölçekleme; Kopyaları değiştirmek için hız sınırı.
Bütçe ölçekleme: dakika başına eklenen trafik/çoğaltma yüzdesini sınırlayın.

Gözlemlenebilirlik ve SLO

• P95/99 gecikme, hata oranı, işlem hacmi, kuyruk derinliği/gecikmesi, CPU/Bellek doygunluğu, pod bekleme süresi, düğüm basıncı.

• Büyüme bekleyen bölmeler, planlanamayan olaylar, IP/alt ağ sıkıntısı, görüntü çekme uzun, tahliyeler.
• Yollar: p99 kuyruklarında kuyruk tabanlı örnekleme - ölçeklendirirken darboğazlar görüyoruz.

FinOps: elastikiyet maliyeti

Metrikler: $/1000 RPS, $/ms p95, $/saat rezerv.
Mix: on-demand + reserved + spot (eleştirilmeyenler için).
Otomatik ölçek eşiği, hatanın maliyeti ile ilgilidir: bazen sıcak stok tutmak kârlıdır.

İGaming/fintech için Özgüllük

Maç/turnuva zirveleri:'minReplicas've minNodes'u önceden yükseltin, sıcak havuzları açın ve önbellekleri/modelleri ısıtın.
Ödeme tüketicileri: KEDA by lag + idempotency, sağlayıcı limitleri (PSP) bozulmanın dış tetikleyicileri olarak.
Antibot: ayrı bir havuz, kuralların hızlı bir ölçeği, "gri" yollar.
Düzenleyici: Uyumluluk hizmetleri için PDB, öncelikler toplu işlemlerden daha yüksektir.

Sayfaları kontrol edin

Tasarım

• Profil verileri tarafından belirtilen talepler/sınırlar; QoS seçildi.
• PriorityClass, PDB, tains/tolerations and topologySpread - yapılandırılmış.
• HPA, sadece CPU değil, SLO metriklerine göre.
• VPA'dan 'Kapalı'ya öneriler toplamak için (' Otomatik'e geçiş planlanmıştır).
• KEDA/Olay Yükleme Kuyrukları.
• CA + sıcak havuzlar, görüntüler önbelleğe alınır (görüntü ön çekme).

Operasyon

• Sabitleme pencereleri ve bekleme süreleri ayarlanır (çırpma hariç).
• Bekleyen/programlanamayan, gecikme, p95, hata oranı uyarıları.
• Runbooks: "no nodes", "image does not stretch", "OOM/evict", "retray storm".
• Aylık kapasite incelemesi: ölçek gerçeği vs plan/maliyet.

Yaygın hatalar

Yalnızca CPU tarafından HPA, IO/veritabanı sınırlarıyla lat-regresyon.
PDB ve önceliklerin eksikliği - eleştiri ilk olacak.
Eleştiriyi ve partiyi aynı havuzda karıştırmak, "gürültülü komşular".
Sıfır ısıtma - soğuk zirvede başlar.
Agresif 'scale' Down '- testere ve thrash kapları.
Idempotency olmadan KEDA - Bir fırtınada yinelenen mesajlar.

Mini oyun kitapları

1) Zirve olayından önce (T-30 dk)

1. 'MinReplicas'/minNode'ları artırın, sıcak havuzları etkinleştirin.
2. CDN/DNS/TLS/bağlantılarını ısıtın, modelleri yükleyin.
3. Botlar için gri yollar/sınırlar ekleyin.
4. Kontrol panoları: bekleyen/lag/p95.

2) Düğüm eksikliği (planlanamayan)

1. CA, bulut kotaları, alt ağlar/IP'yi kontrol edin.
2. Geçici olarak daha düşük parti limitleri, düşük öncelikler için ön alım sağlar.
3. Geçici olarak daha büyük bir örnek türü veya ikinci bir havuz oluşturun.

3) Kuyruktaki gecikmenin büyümesi

1. KEDA: tetiğe göre ölçek büyütme; 2) tüketici limitlerini yükseltmek;

2. Idempotency tuşlarını ve geri basınç üreticilerini etkinleştirin.

4) Testere kopyaları

1. Stabilizasyon/dolum süresini artırın; 2) adım ölçeklemeye geçin;

2. Metriği üstel bir ortalama ile düzeltin.

Config beşiği

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

--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 } }

Sonuç

Verimli zamanlayıcı ve otomatik ölçekleme, doğru istekler/sınırlar + akıllı yığınlama + çok düzeyli ölçekleme (HPA/VPA/KEDA/CA) + ısınma ve çırpmayı önleme, SLO ve milisaniye maliyetine bağlıdır. IaC'deki politikaları düzeltin, "doğru" metriklerle (gecikme/gecikme) gözlemleyin, zirveler altında sıcak stok tutun - platform elastik, öngörülebilir ve ekonomik olacaktır.