Sari la conținutul principal

HPA și incidentul controlat

Vom produce o degradare repetabilă, o vom observa, apoi vom reveni la configurația normală. Scopul nu este doar să vedem grafice, ci să formulăm și să verificăm o ipoteză.

1. Starea inițială​

Într-un terminal păstrați port-forward-ul API:

kubectl port-forward service/ticketing-api -n cc-lab5 8080:80

În alt terminal urmăriți HPA și podurile:

kubectl get hpa,pods -n cc-lab5 --watch

Inspectați decizia HPA:

kubectl describe hpa ticketing-api -n cc-lab5

Observați că utilizarea CPU este raportată ca procent din request-ul de 25m, nu din capacitatea totală a nodului.

2. Trafic de referință​

DURATION=120 CONCURRENCY=8 ./scripts/load.sh

Urmăriți dashboard-ul și notați:

  • request rate
  • error rate
  • p95
  • numărul de replici
  • CPU pe pod.

3. Activarea incidentului​

Fișierul values-incident.yaml introduce:

  • 700 ms latență artificială
  • probabilitate 0.25 pentru răspunsuri 503
  • 40 ms de lucru CPU pe cerere.
helm upgrade ticketing charts/ticketing \
  --namespace cc-lab5 \
  --values charts/ticketing/values-lab5.yaml \
  --values charts/ticketing/values-incident.yaml \
  --wait --timeout 5m

Porniți din nou trafic, cu o concurență mai mare:

DURATION=180 CONCURRENCY=12 ./scripts/load.sh

4. Investigația​

Folosiți sursele în această ordine:

Simptomul​

În dashboard verificați creșterea p95 și a ratei 5xx. În Prometheus verificați alertele.

Reacția platformei​

kubectl get hpa,pods -n cc-lab5
kubectl describe hpa ticketing-api -n cc-lab5
kubectl top pods -n cc-lab5
kubectl get events -n cc-lab5 --sort-by=.metadata.creationTimestamp | tail -n 20

Dovezile din loguri​

kubectl logs deployment/ticketing-api -n cc-lab5 --since=5m \
  | grep -E '"status":503|"duration_ms"'

Ipoteza​

Formulați o explicație care leagă valorile configurate de semnalele observate. De exemplu:

Creșterea latenței și a erorilor a apărut imediat după rollout-ul configurației incident. HPA a adăugat replici din cauza CPU, dar nu a eliminat erorile injectate în fiecare pod.

5. Recuperarea​

Eliminați overlay-ul incidentului printr-un nou upgrade cu valorile normale:

helm upgrade ticketing charts/ticketing \
  --namespace cc-lab5 \
  --values charts/ticketing/values-lab5.yaml \
  --wait --timeout 5m

Generați încă un minut de trafic și verificați că rata de erori și latența revin la normal. HPA va reduce replicile numai după fereastra de stabilizare configurată.

Ce nu rezolvă HPA

Autoscaling-ul poate adăuga capacitate când resursa limitativă este CPU. Nu repară automat o dependență defectă, un bug, erori injectate în toate replicile sau o bază de date saturată.