Planowanie zasobów i automatyczne skalowanie

Krótkie podsumowanie

1. Poprawne żądania/limity i klasy QoS.

2. Prawidłowe układanie (topologia, powinowactwo, priorytety, uprzedzenie).

3. Wielopoziomowe automatyczne skalowanie: HPA/VPA/KEDA + Cluster/Node autoscaler + ciepłe baseny.

4. Logika zorientowana na SLO (głębokość opóźnienia/kolejki) z anty-klapowania i budżetów.

Podstawowy model zasobów

Żądania/limity i klasy QoS

Wnioski = gwarancje dla harmonogramu; Limity = pułapy dla czasu trwania.
QoS: Guaranteed (req = lim by CPU/Memory), Burstable (częściowo), KeyEffort (nic).
Usługi produkcyjne z twardymi SLO - Guaranteed/Burstable; tło - pęcherz/wysiłek.

Procesor/pamięć/IO/sieć

Procesor - elastyczny (współdzielenie czasu), pamięć - twardy (OOM-kill, jeśli przekroczony).
W sieci IO ustawić granice/priorytety oddzielnie (cgroups/TC), inaczej „hałaśliwe sąsiadów”.

GPU/akceleratory

Zapytaj wektor (GPU = 1, VRAM poprzez profile), użyj węzła Selector/tains i PodPriority do krytyki.
Do wnioskowania - wielkość partii i ogrzewanie modelu.

Zasady planowania

Priorytety, pierwszeństwo i WPB

Klasa dla ścieżek krytycznych (płatności, logowanie), preempcja jest dozwolona.
PodDis Budget chroni minimalne wskazówki podczas ewakuacji/aktualizacji.

Powinowactwo/topologia

powinowactwo węzła/podłoża do kolokacji/dekolokacji (na przykład, nie umieszczać replik na jednym gospodarzu).
Najwyższe granice Ograniczenia dostosowują słuchy do stref/AZ.
NUMA/topologia: pin-CPU/uściski, w których ważne jest niskie opóźnienie.

Teyinths i tolerancje

Oddzielne puli: 'prod',' partia ',' gpu ',' system '. Krytyka wytrzymuje mniej sąsiadów.

Automatyczne skalowanie: poziomy i sygnały

1) HPA (Horizontal Pod Autoscaler)

Repliki strąków według metryki: CPU/Memory/custom (Prometheus Adapter).
Dobre sygnały: opóźnienie p95/p99, długość kolejki/lag, RPS na strąk, opóźnienie konsumenckie.
Zapobieganie klapowaniu: stabilizacja (stabilizacja okna), minimalny krok, chłodzenie.

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)

Żądania/limity dotyczące rzeczywistego zużycia (zalecenia dotyczące aktualizacji).
Tryby: 'Off', 'Auto' (restart), 'Initial' (tylko na początku).
Praktyka: włącz 'Off' → zbierz statystyki → stosuje się do wydań.

3) Skalowanie oparte na KEDA/kolejce

Reaguje na sygnały zewnętrzne: Kafka lag, głębokość SQS, długość Redis, Prometheus.
Idealny dla konsumentów imprezy/kolejki (EDA).

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) Klaster/węzeł Autoskaler (CA) + ciepłe baseny

CA dodaje/usuwa węzły przy niedoborze/nadmiarze.
Ciepłe baseny: wstępnie podgrzane węzły/przygotowane obrazy (przyspieszenie zimnego startu).
Dla szczytów - stopniowe skalowanie i powiększanie minNodes z wyprzedzeniem.

Szybkość reakcji i ocieplenie

Opóźnienie reakcji SLO: warstwa przednia ≤ 1-2 minuty, podpory/DB - oddzielnie i z wyprzedzeniem.
Rozgrzewka: połączenia TLS/DNS/, modele ładowania, nagrzewanie pamięci podręcznej i JIT.
Obciążenie cieniem do „pompowania” zimnej ścieżki do zdarzenia.

Zapobieganie klapom i stabilność

Histereza na metrykach, wygładzanie (średnie).
Okna stabilizacyjne w HPA, duże w ' Down'.
Skalowanie krokowe zamiast „piły”; limit szybkości do modyfikacji replik.
Skalowanie budżetu: ograniczyć% ruchu/replik dodawanych na minutę.

Obserwowalność i SLO

• p95/99 opóźnienie, prędkość błędu, przepustowość, głębokość/lag kolejki, CPU/nasycenie pamięci, czas oczekiwania na podanie, ciśnienie węzła.

• Oczekujące na wzrost strąki, niezaplanowane zdarzenia, niedobór IP/podsieci, długie ciągnięcie obrazu, eksmisje.
• Szlaki: pobieranie próbek na podstawie ogona na ogonach p99 → widzimy wąskie gardła podczas skalowania.

FinOps: koszt elastyczności

Mierniki: $/1000 RPS, $/ms p95, $/godzinę rezerwy.
Mix: na żądanie + zarezerwowany + spot (bez krytyki).
Próg automatycznej skali jest związany z kosztem błędu: czasami opłacalne jest utrzymanie ciepłego zasobu.

Specyfika dla iGaming/fintech

Mecz/turniej szczyty: podnieść 'minReplicas' i minNodes z wyprzedzeniem, włączyć ciepłe baseny i rozgrzać bufory/modele.
Konsumenci płatności: KEDA według lag + idempotency, limit dostawcy (PSP) jako zewnętrzny czynnik wyzwalający degradację.
Antibot: oddzielny basen, szybka skala zasad, szare szlaki.
Regulacja: PDB dla usług zgodności, priorytety są wyższe niż dla partii.

Arkusze kontrolne

Projekt

• Wnioski/limity określone poprzez profilowanie danych; Wybrano QoS.
• Klasa , PDB, tains/tolerancje i top Spread - skonfigurowane.
• HPA przez metryki SLO, nie tylko procesor.
• VPA do „Off” w celu zebrania zaleceń (planowana jest migracja do „Auto”).
• Kolejki obciążenia KEDA/Event.
• CA + ciepłe baseny, obrazy są buforowane (obrazek przed pociągnięciem).

Operacja

• Ustawione są okna stabilizacyjne i okna okienne (wyłączone z klapowania).
• Wpisy do oczekujących/nieprzewidzianych, opóźnienia, p95, wskaźnik błędów.
• Książki startowe: „brak węzłów”, „obraz nie rozciąga się”, „OOM/eksmisja”, „burza retray”.
• Miesięczny przegląd przepustowości: fakt skala vs plan/koszt.

Częste błędy

HPA tylko przez CPU → lat-regresja z limitami IO/bazy danych.
Brak WPB i priorytetów → krytyka będzie pierwsza.
Mieszanie krytyki i partii na tym samym basenie bez bajek → „hałaśliwi sąsiedzi”.
Zero ogrzewania → zimno zaczyna się na szczycie.
Agresywne kontenery z piłą i thrashem.
KEDA bez idempotencji → duplikat wiadomości w burzy.

Mini playbooks

1) Przed wydarzeniem szczytowym (T-30 min)

1. Zwiększ 'minReplicas '/minNodes, aktywuj ciepłe baseny.
2. Ogrzewanie CDN/DNS/TLS/połączenia, modele obciążenia.
3. Zawiera szare trasy/limity dla botów.
4. Sprawdź deski rozdzielcze: oczekujące/lag/p95.

2) Niedobór węzła (nieplanowany)

1. Sprawdź CA, kwoty w chmurze, podsieci/IP.
2. Tymczasowo obniżyć limity partii, włączyć pierwszeństwo dla niskich priorytetów.
3. Podnieś tymczasowo większy typ instancji lub drugą pulę.

3) Wzrost opóźnienia w kolejce

1. KEDA: skala w górę przez wyzwalacz; 2) zwiększenie limitów konsumenckich;

2. Włącz klucze idempotencji i producentów ciśnienia wstecznego.

4) Repliki piły

1. Zwiększenie stabilizacji/chłodzenia; 2) przełączenie na skalowanie stopniowe;

2. wygładzić metrykę ze średnią wykładniczą.

Łóżeczko Config

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

Wynik

Wydajny harmonogram i automatyczne skalowanie są poprawne żądania/limity + inteligentne układanie + wielopoziomowe skalowanie (HPA/VPA/KEDA/CA) + ocieplenie i antyklapowanie, związane z kosztem SLO i milisekundowym. Fix polityki w IaC, obserwować przez „poprawne” mierniki (opóźnienie/opóźnienie), utrzymać ciepłe zapasy w szczytach - a platforma będzie elastyczny, przewidywalny i ekonomiczny.