12 marca 2024
12 min
EffiLab Team

Kubernetes auto-scaling: teoria vs praktyka

Dlaczego domyślne ustawienia HPA nie działają i jak skonfigurować skalowanie, które rzeczywiście oszczędza pieniądze.

KubernetesScaling
Powrót do bloga

Kubernetes auto-scaling: teoria vs praktyka

Problem z domyślnymi ustawieniami HPA

Horizontal Pod Autoscaler w Kubernetes brzmi świetnie w teorii, ale w praktyce większość zespołów ma z nim problemy. Dlaczego?

Typowe błędy konfiguracji

  1. Zbyt agresywne skalowanie
  2. Brak proper metrics
  3. Ignorowanie startup time
  4. Nieprawidłowe resource requests

Praktyczny setup HPA

1. Właściwe metryki

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: webapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: webapp
  minReplicas: 2
  maxReplicas: 50
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 10
        periodSeconds: 60

2. Custom metrics z Prometheus

- type: Pods
  pods:
    metric:
      name: http_requests_per_second
    target:
      type: AverageValue
      averageValue: "100"

VPA vs HPA: kiedy co używać?

| Scenario | Recommendation | Powód | |----------|---------------|--------| | Predictable load | HPA | Lepszy cost control | | Variable workload | HPA + VPA | Optimal resource usage | | Batch jobs | VPA only | Single execution optimization | | Microservices | HPA | Better availability |

Real-world case study

Przed optymalizacją:

  • 20 podów zawsze running
  • $2,400/miesiąc koszty compute
  • 90% idle time w night hours

Po optymalizacji:

  • 2-15 podów w zależności od load
  • $800/miesiąc koszty compute
  • 67% oszczędności

Best practices

  1. Ustaw proper resource requests
  2. Monitoruj lag metryki
  3. Testuj na non-prod pierwsz
  4. Używaj PodDisruptionBudgets

Problemy z Kubernetes scaling? Umów konsultację.