როგორ მუშაობს Horizontal Pod Autoscaler და როგორ უკავშირდება ის Cluster Autoscaler-ს?

Question

IT Interview Practice · Accepted Answer

**Horizontal Pod Autoscaler (HPA)** ამატებს ან აშორებს **Pod ასლებს** დაკვირვებული მეტრიკების მიხედვით (CPU, მეხსიერება ან custom). **Cluster Autoscaler (CA)** ამატებს ან აშორებს **node-ებს**, როცა Pod-ები ვერ იგეგმებიან ან node-ები ნაკლებად გამოიყენება. ისინი სხვადასხვა ფენაზე მოქმედებენ და ერთად მუშაობენ.

## ორი autoscaler, ორი ფენა

```text
HPA  → scales PODS  (more/fewer replicas of a Deployment)     — reacts to LOAD
CA   → scales NODES (grows/shrinks the cluster's machines)     — reacts to PENDING Pods
VPA  → (bonus) adjusts a Pod's requests/limits                 — reacts to right-sizing

Typical flow: load rises → HPA adds Pods → Pods can't fit → CA adds a node →
              Pods schedule. Load drops → HPA removes Pods → node idle → CA removes it.
```

## როგორ მუშაობს HPA-ს მართვის მარყუჟი

```text
Every ~15s the HPA controller:
  1. reads current metric (e.g. avg CPU across Pods) from metrics-server / custom API
  2. computes:  desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)
  3. scales the Deployment toward that (bounded by minReplicas/maxReplicas)
Example: 4 Pods at 80% CPU, target 50% → 4 * 80/50 = 6.4 → 7 replicas.
Stabilization windows dampen flapping (esp. on scale-down).
```

## HPA-ს manifest

```yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60      # საშ. CPU შენარჩუნება REQUEST-ის ~60%-ზე
  behavior:                           # არასავალდებულო: scale up/down სიჩქარის რეგულირება
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # მიმდინარე/სამიზნე მეტრიკა, ასლების რაოდენობა
kubectl top pods                      # საჭიროებს metrics-server-ს
```

## მნიშვნელოვანი დამოკიდებულებები და გაფრთხილებები

```text
• HPA on CPU/memory REQUIRES metrics-server installed; utilization is relative to REQUESTS
  → if requests are unset/wrong, HPA math is meaningless. Set requests correctly.
• Custom/external metrics (RPS, queue depth) need an adapter (Prometheus Adapter, KEDA).
• HPA and manual `replicas` conflict — let the HPA own the replica count.
• Cluster Autoscaler needs correct requests too: it looks at Pending Pods' REQUESTS to
  decide node scaling. Node scale-up takes minutes (provisioning), so keep headroom.
```

## რატომ არის ეს მნიშვნელოვანი

autoscaling არის ის, რაც Kubernetes-ს საშუალებას აძლევს სიმძლავრე მოთხოვნას ავტომატურად შეუსაბამოს, ხოლო ორი ფენის გაგება senior-დონის ცოდნაა, რომელიც ხარჯ-ეფექტიან, მდგრად კლასტერებს გამოარჩევს ზედმეტად ან ნაკლებად უზრუნველყოფილისგან. მთავარი აზრობრივი მოდელი ისაა, რომ **HPA მასშტაბირებს Pod-ებს** დატვირთვის საპასუხოდ (ასლების რაოდენობას არეგულირებს დაკვირვებული CPU-დან, მეხსიერებიდან ან custom მეტრიკებიდან), ხოლო **Cluster Autoscaler მასშტაბირებს node-ებს** scheduling-ის წნეხის საპასუხოდ (ამატებს მანქანებს, როცა Pod-ები Pending-ია, აშორებს, როცა node-ები უქმია) — ისინი სხვადასხვა ფენაზე მოქმედებენ და თანამშრომლობენ: HPA-ს Pod-ების დამატება მხოლოდ მაშინ შეუძლია, თუ ადგილია, ხოლო CA სწორედ ამ ადგილს აწვდის. HPA-ს მართვის მარყუჟის — `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)` ფორმულის, პერიოდული შეჯერებისა და flapping-ის თავიდან ამცილებელი stabilization ფანჯრების — გაგება საშუალებას გაძლევთ დააკონფიგურიროთ და debug-ი გაუკეთოთ მას, და არა ჯადოსნობად აღიქვათ. გაფრთხილებებია, სადაც senior-ის განსჯა ჩანს: HPA CPU/მეხსიერებაზე **საჭიროებს metrics-server-ს** და utilization-ს **request-ების მიმართ** ითვლის, ამიტომ არასწორი ან არარსებული request-ები მის მათემატიკას აზრს უკარგავს; custom მეტრიკებს (requests-per-second, queue depth) სჭირდებათ adapter, როგორიც Prometheus Adapter ან KEDA; ხოლო node-ის scale-up წუთებს იღებს, ამიტომ სათადარიგო მარაგი (headroom) მნიშვნელოვანია. რადგან სიმძლავრის სწორად შერჩევა პირდაპირ მოქმედებს საიმედოობაზე ტრაფიკის პიკებისას და ღრუბლის ხარჯზე ჩუმ პერიოდებში, და რადგან ორივე autoscaler სწორად დაყენებულ რესურსების request-ებზეა დამოკიდებული, HPA-სა და Cluster Autoscaler-ის დაუფლება ფუნდამენტურია production Kubernetes-ის ეფექტიანად და საიმედოდ ოპერირებისთვის.

ორი autoscaler, ორი ფენა

როგორ მუშაობს HPA-ს მართვის მარყუჟი

HPA-ს manifest

მნიშვნელოვანი დამოკიდებულებები და გაფრთხილებები

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები