Kubernetes HorizontalPodAutoscaler (HPA v2) Generator

Kubernetes HorizontalPodAutoscaler (HPA v2) Generator

K8s 1.23+ GA

Erstellen Sie autoskalierende HPA v2 YAML-Manifeste mit CPU- und Speicher-Zielauslastung, benutzerdefinierten Metriken und Stabilisierungsrichtlinien für Scale-Up und Scale-Down.

Presets:
HPA-Konfiguration
Replika-GrenzenScale: 2 → 10 Pods
minReplicas
maxReplicas
Kubernetes-Scheduling-Hinweis: Bei nachlassendem Datenverkehr skaliert HPA niemals unter minReplicas (2), und begrenzt die Erweiterung auf maximal maxReplicas (10).
Replicas: 2-10Metrics: 2
Target: api-service
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-service-hpa
  namespace: production
  labels:
    app.kubernetes.io/name: api-service
    app.kubernetes.io/managed-by: toolsaa-k8s-hpa-generator
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-service
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 75
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      selectPolicy: Max
      policies:
        - type: Percent
          value: 100
          periodSeconds: 15
        - type: Pods
          value: 4
          periodSeconds: 15
    scaleDown:
      stabilizationWindowSeconds: 300
      selectPolicy: Min
      policies:
        - type: Percent
          value: 10
          periodSeconds: 60
Lines: 46Size: 1035 B
autoscaling/v2 syntax ready
API-Version
autoscaling/v2 (K8s 1.23+)
Zielmetriken
2 Regeln konfiguriert
Verhaltensstabilisierung
300s s Abkühlfenster

Client-seitige Verarbeitung

Hochleistungsfähige Verarbeitung, die vollständig im Browserspeicher ausgeführt wird.

Null-Server-Upload Datenschutz

Alle Nutzdaten bleiben strikt lokal ohne externe Serverkommunikation.

Produktionsreifer Export

Saubere, optimierte Ausgabeformate, bereit für den sofortigen Einsatz in Kubernetes.

Technische Referenz & Architektur-Leitfaden

Kubernetes HorizontalPodAutoscaler (HPA v2) Generator — Referenz-Leitfaden

Erstellen Sie autoskalierende HPA v2 YAML-Manifeste mit CPU- und Speicher-Zielauslastung, benutzerdefinierten Metriken und Stabilisierungsrichtlinien für Scale-Up und Scale-Down.

Wichtige Parameter & Steuerelemente

scaleTargetRefObjekt (apiVersion, kind, name)

Gibt die Ziel-Workload-Ressource für das Autoscaling an, üblicherweise ein Deployment, StatefulSet oder ReplicaSet unter apps/v1.

Standard: { apiVersion: "apps/v1", kind: "Deployment", name: "my-app" }
minReplicas / maxReplicasGanzzahl (positiv)

Definiert die absoluten Unter- und Obergrenzen für Pod-Replikate. Der Controller skaliert unter keinen Umständen unter minReplicas oder über maxReplicas.

Standard: minReplicas: 2, maxReplicas: 10
metricsArray (Resource | ContainerResource | Pods | Object | External)

Liste der Metrikregeln für die Controller-Auswertung. Unterstützt Ressourcenmetriken (averageUtilization oder averageValue für CPU/Speicher), ContainerResource und benutzerdefinierte/externe Metriken.

Standard: [{ type: "Resource", resource: { name: "cpu", target: { type: "Utilization", averageUtilization: 70 } } }]
behavior.scaleDownObjekt (stabilizationWindowSeconds, policies, selectPolicy)

Stabilisierungszeitfenster und Drosselungsrichtlinien beim Scale-Down zur Vermeidung von Flattern (Thrashing) und für einen geordneten Pod-Abbau.

Standard: { stabilizationWindowSeconds: 300, selectPolicy: "Min", policies: [{ type: "Percent", value: 10, periodSeconds: 60 }] }
behavior.scaleUpObjekt (stabilizationWindowSeconds, policies, selectPolicy)

Definiert die Scale-Up-Expansionsrate zur schnellen Bewältigung von Lastspitzen mit konfigurierbaren Verzögerungen und Burst-Wachstumsrichtlinien.

Standard: { stabilizationWindowSeconds: 0, selectPolicy: "Max", policies: [{ type: "Percent", value: 100, periodSeconds: 15 }, { type: "Pods", value: 4, periodSeconds: 15 }] }

Profi-Tipps & Best Practices

Der HPA-Controller berechnet

Der HPA-Controller berechnet prozentuale Auslastungen strikt relativ zu 'resources.requests', nicht zu 'limits'. Fehlen die Requests im Deployment, zeigt der HPA den Status '<unknown>/target%' an und verweigert die Skalierung.

Halten Sie

Halten Sie 'behavior.scaleUp.stabilizationWindowSeconds: 0' für eine sofortige Reaktion auf Lastspitzen, setzen Sie aber 'behavior.scaleDown.stabilizationWindowSeconds: 300' (5 Minuten). Dies verhindert ständige Schwankungen bei Lastwechseln.

Besitzt Ihr Dienst ein strenges

Besitzt Ihr Dienst ein strenges PodDisruptionBudget (z. B. minAvailable: 80%), vermeiden Sie drastische Abbaurichtlinien (z. B. 50% Reduktion alle 15s). Nutzen Sie 'type: Percent, value: 10' oder feste Pod-Schritte, um Eviction-Fehler zu vermeiden.

Die gleichzeitige Ausführung von HPA

Die gleichzeitige Ausführung von HPA und VPA auf CPU oder Speicher erzeugt Konflikte in den Kontrollschleifen. Kombinieren Sie HPA lieber mit anwendungsbezogenen Metriken (z. B. HTTP-Requests oder Warteschlangenlänge), während VPA die Pod-Dimensionierung übernimmt.

Häufige Fallstricke & Fehlerbehebung

HPA meldet 'TARGETS: <unknown>/70%' und führt keine Skalierung aus.

Überprüfen Sie, ob alle Container im Deployment 'resources.requests.cpu' (oder Speicher) deklariert haben. Prüfen Sie mit 'kubectl top pods' und 'kubectl get apiservice v1beta1.metrics.k8s.io', ob der Kubernetes Metrics Server ordnungsgemäß läuft.

Workload zeigt ständiges Flattern (schnelles Hoch- und Runterskalieren).

Erhöhen Sie 'behavior.scaleDown.stabilizationWindowSeconds' auf 300 bis 600 Sekunden. Ergänzen Sie defensive Richtlinien mit 'selectPolicy: Min', sodass Pods schrittweise über mehrere Minuten abgebaut werden.

Benutzerdefinierte oder externe Metriken scheitern mit 'unable to fetch metrics: metric not found'.

Prüfen Sie, ob der Metrik-Adapter (z. B. Prometheus Adapter, KEDA, Datadog Cluster Agent) aktiv und in 'kubectl get apiservices' registriert ist. Vergleichen Sie Metriknamen und Label-Selektoren mit dem Schema des Anbieters.

Häufig gestellte Fragen (FAQ)

Was ist der Hauptunterschied zwischen autoscaling/v1 und autoscaling/v2?▼

Die ältere API 'autoscaling/v1' unterstützte ausschließlich prozentuale CPU-Zielauslastung für Deployments. 'autoscaling/v2' (Standard seit Kubernetes 1.23+) unterstützt mehrere Metriken gleichzeitig (CPU, Speicher, benutzerdefinierte und externe Dienste), containerbezogene Metriken sowie präzise 'behavior'-Stabilisierungsrichtlinien.

Welche mathematische Formel nutzt der HPA zur Berechnung der Replikate?▼

Die Formel lautet: gewünschteReplikate = ceil[aktuelleReplikate * (aktuellerMetrikwert / ZielMetrikwert)]. Beispiel: Bei 4 Replikaten mit 80% CPU und einem Ziel von 50% errechnet der HPA ceil[4 * (80 / 50)] = ceil[6.4] = 7 Replikate. Liegt das Verhältnis innerhalb einer Toleranz von 10% (0.9 bis 1.1), wird keine Aktion ausgelöst.

Warum gilt speicherbasiertes Autoscaling (Memory) als risikoreich?▼

Im Gegensatz zur CPU, die bei Leerlauf sofort abfällt, behalten viele Runtimes (wie Java JVM, Go oder Node.js) alloziierten Arbeitsspeicher oder verzögern die Garbage Collection. Der Speicherverbrauch bleibt daher auch nach Lastabfall hoch, was ein Zurückskalieren verhindert.

Wie funktionieren selectPolicy: Min und Max in den HPA-Verhaltensregeln?▼

Sind mehrere Richtlinien definiert, entscheidet 'selectPolicy' über das Auswahlkriterium: 'Min' wählt die Richtlinie mit der geringsten Replikatsänderung (konservativ), während 'Max' die Richtlinie mit der größten Änderung (aggressiv) wählt. Scale-Up nutzt standardmäßig 'Max' für schnelle Reaktionszeiten.

Unterstützt HPA das Herunterskalieren auf null Replikate (Scale to Zero)?▼

Natives HPA v2 erlaubt 'minReplicas: 0' ab Kubernetes 1.23 (Feature-Gate HPAScaleToZero, standardmäßig aktiv ab 1.28), jedoch ausschließlich bei Custom- oder External-Metriken (da 0 Pods keine CPU/Speicher-Daten liefern). Für vollständige Event-gesteuerte Scale-to-Zero-Architekturen empfiehlt sich KEDA oder Knative.

Verwandte Werkzeuge & Dienstprogramme

Alle Werkzeuge →
Redis (redis.conf) Konfigurations-Builder & Performance-TunerEntwickler

Erstellen Sie produktionsreife redis.conf-Konfigurationen mit optimierten maxmemory-Richtlinien, RDB/AOF-Persistenz, Netzwerkbindung und robuster ACL-Sicherheit.

Werkzeug öffnen→
PostgreSQL (postgresql.conf) Hardware-Tuning & Builder Entwickler-HandbuchEntwickler

Berechnen und generieren Sie optimierte postgresql.conf-Einstellungen basierend auf Hardwarespezifikationen (shared_buffers, work_mem, effective_cache_size, max_connections).

Werkzeug öffnen→
Tägliche Off-Peak-DatenbanksicherungEntwickler

Erstellen Sie produktionsreife systemd-Timer-Units und zugehörige Oneshot-Services mit OnCalendar-Planung, OnBootSec-Intervallen, Persistent-Ausführung und zufälligen Verzögerungen.

Werkzeug öffnen→
TypeScript (tsconfig.json) Konfigurations-Generator Entwickler-HandbuchEntwickler

Erstellen Sie moderne, robuste tsconfig.json-Konfigurationen für Next.js, Node.js, Vite oder Bibliotheken mit Strict Mode, Pfad-Aliasen und optimaler Modulauflösung.

Werkzeug öffnen→
Entwicklerhandbuch für den JSON zu ClickHouse CREATE TABLE DDL GeneratorEntwickler

Konvertieren Sie JSON-Dokumente in ClickHouse SQL DDL mit MergeTree-Engine, UInt/Int/Float/String/DateTime-Typen sowie Array/Nested-Spaltenzuordnungen.

Werkzeug öffnen→
JSON zu Google BigQuery Tabellenschema GeneratorEntwickler

Analysieren und konvertieren Sie JSON-Objekte in Google Cloud BigQuery-Tabellenschema-JSON mit RECORD-Modus, STRING-, INTEGER-, NUMERIC- und TIMESTAMP-Feldern.

Werkzeug öffnen→