Générateur de Kubernetes HorizontalPodAutoscaler (HPA v2)

Générateur de Kubernetes HorizontalPodAutoscaler (HPA v2)

K8s 1.23+ GA

Générez des manifestes YAML HPA v2 avec objectifs d'utilisation CPU et mémoire, métriques personnalisées et politiques de stabilisation de mise à l'échelle.

Presets:
Configuration du HPA
Limites de réplicasScale: 2 → 10 pods
minReplicas
maxReplicas
Note d'ordonnancement Kubernetes : Lorsque le trafic diminue, le HPA ne descendra jamais en dessous de minReplicas (2), et limitera l'expansion rapide à maxReplicas (10).
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
Version de l'API
autoscaling/v2 (K8s 1.23+)
Métriques Cibles
2 règles configurées
Stabilisation du Comportement
300s s fenêtre de temporisation

Traitement Côté Client

Traitement haute performance exécuté entièrement dans la mémoire du navigateur.

Confidentialité Sans Envoi Serveur

Toutes les configurations restent strictement locales sans aucune communication avec un serveur externe.

Export Prêt pour la Production

Formats de sortie propres et optimisés, prêts pour un déploiement immédiat avec kubectl.

Référence technique et guide d'architecture

Guide Développeur du Générateur Kubernetes HorizontalPodAutoscaler (HPA v2) — Guide de référence

Générez des manifestes YAML HPA v2 avec objectifs d'utilisation CPU et mémoire, métriques personnalisées et politiques de stabilisation de mise à l'échelle.

Paramètres clés et contrôles

scaleTargetRefobjet (apiVersion, kind, name)

Spécifie la ressource de charge de travail cible à ajuster, généralement un Deployment, StatefulSet ou ReplicaSet sous apps/v1.

Par défaut : { apiVersion: "apps/v1", kind: "Deployment", name: "my-app" }
minReplicas / maxReplicasentier (positif)

Définit les limites minimale et maximale absolues du nombre de répliques de pods. Le contrôleur ne dépassera jamais ces bornes, quelles que soient les conditions de charge.

Par défaut : minReplicas: 2, maxReplicas: 10
metricstableau (Resource | ContainerResource | Pods | Object | External)

Liste des règles de métriques évaluées par le contrôleur. Prend en charge les métriques de ressources (averageUtilization ou averageValue sur CPU/mémoire), ContainerResource et métriques externes/personnalisées.

Par défaut : [{ type: "Resource", resource: { name: "cpu", target: { type: "Utilization", averageUtilization: 70 } } }]
behavior.scaleDownobjet (stabilizationWindowSeconds, policies, selectPolicy)

Fenêtre de stabilisation et politiques de limitation de débit appliquées lors du scale-down pour éviter les oscillations rapides (flapping) et assurer l'arrêt propre des pods.

Par défaut : { stabilizationWindowSeconds: 300, selectPolicy: "Min", policies: [{ type: "Percent", value: 10, periodSeconds: 60 }] }
behavior.scaleUpobjet (stabilizationWindowSeconds, policies, selectPolicy)

Définit la réactivité d'extension du scale-up pour absorber les pics de trafic soudains, avec délais de stabilisation et politiques d'accroissement par rafale.

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

Conseils de pro et bonnes practices

Le contrôleur HPA calcule les

Le contrôleur HPA calcule les pourcentages d'utilisation exclusivement par rapport aux 'resources.requests', et non aux 'limits'. Si les requêtes sont omises dans le Deployment, le HPA affiche l'état '<unknown>/target%' et refuse d'ajuster l'échelle.

Conservez

Conservez 'behavior.scaleUp.stabilizationWindowSeconds: 0' pour répondre instantanément aux pics de charge, tout en paramétrant 'behavior.scaleDown.stabilizationWindowSeconds: 300' (5 minutes). Cela empêche les oscillations rapides lorsque le trafic fluctue autour du seuil.

Si votre application applique un PDB

Si votre application applique un PDB strict (ex. minAvailable: 80%), évitez les politiques de réduction brutales (ex. suppression de 50% des pods toutes les 15s). Utilisez 'type: Percent, value: 10' ou un nombre fixe de 1 à 2 pods pour éviter les rejets d'éviction.

Faire fonctionner HPA et VPA

Faire fonctionner HPA et VPA simultanément sur le CPU ou la mémoire crée des boucles de contrôle conflictuelles. Si les deux sont requis, configurez le HPA sur des métriques applicatives (taux de requêtes HTTP, files d'attente) et confiez le dimensionnement des conteneurs au VPA.

Pièges courants et dépannage

Le statut HPA affiche 'TARGETS: <unknown>/70%' et n'exécute aucune mise à l'échelle.

Vérifiez que tous les conteneurs du Deployment cible définissent explicitement 'resources.requests.cpu' (ou mémoire). Assurez-vous également que le Metrics Server Kubernetes est sain en exécutant 'kubectl top pods' et 'kubectl get apiservice v1beta1.metrics.k8s.io'.

La charge de travail subit des oscillations perpétuelles (scale-up suivi immédiatement d'un scale-down).

Augmentez 'behavior.scaleDown.stabilizationWindowSeconds' à 300 ou 600 secondes. Configurez des règles scaleDown défensives avec 'selectPolicy: Min' pour que la réduction du nombre de pods s'échelonne sur plusieurs minutes.

Les métriques personnalisées ou externes renvoient 'unable to fetch metrics: metric not found'.

Vérifiez que votre adaptateur de métriques (Prometheus Adapter, KEDA, Datadog Cluster Agent) est déployé et enregistré sous 'kubectl get apiservices'. Vérifiez que le nom de la métrique et les sélecteurs d'étiquettes correspondent exactement au catalogue exposé.

Foire aux questions (FAQ)

Quelle est la différence fondamentale entre autoscaling/v1 et autoscaling/v2 ?▼

L'API historique 'autoscaling/v1' ne permettait que l'ajustement des Deployments en fonction du pourcentage d'utilisation CPU. La version 'autoscaling/v2' (standard depuis Kubernetes 1.23+) gère plusieurs métriques simultanées (CPU, mémoire, métriques personnalisées et services externes), des métriques ciblées par conteneur et des politiques fines de 'behavior' pour la stabilisation.

Quelle est la formule mathématique employée par le HPA pour calculer les répliques ?▼

La formule appliquée est: répliquesDésirées = ceil[répliquesActuelles * (valeurMétriqueActuelle / valeurMétriqueCible)]. Par exemple, avec 4 répliques à 80% de CPU pour un objectif de 50%, le HPA calcule ceil[4 * (80 / 50)] = ceil[6.4] = 7 répliques. Si le ratio reste dans une marge de tolérance de 10% (0.9 à 1.1), aucune action de mise à l'échelle n'est déclenchée.

Pourquoi l'autoscaling basé sur la mémoire est-il considéré comme délicat ?▼

Contrairement au CPU qui redescend dès que le trafic s'interrompt, les runtimes applicatifs (tels que Java JVM, Go ou Node.js) conservent la mémoire allouée ou diffèrent l'exécution du ramasse-miettes (garbage collector). La mémoire consommée reste donc élevée même en l'absence de trafic, empêchant le HPA de réduire les répliques.

Comment fonctionnent selectPolicy: Min et Max dans les politiques de comportement HPA ?▼

Lors de la déclaration de plusieurs politiques dans scaleUp ou scaleDown, 'selectPolicy' détermine la règle prioritaire: 'Min' retient la politique entraînant la variation du nombre de répliques la plus faible (choix conservateur), tandis que 'Max' retient la plus forte variation (choix réactif). ScaleUp applique 'Max' par défaut pour absorber les pics.

Le HPA Kubernetes autorise-t-il la mise à l'échelle vers zéro réplique (scale-to-zero) ?▼

L'API native HPA v2 autorise 'minReplicas: 0' depuis Kubernetes 1.23 (activé par défaut en 1.28+), mais uniquement avec des métriques personnalisées ou externes (aucun pod actif ne pouvant émettre de métriques CPU/mémoire). Pour des architectures complètes orientées événements avec retour à zéro, l'utilisation de KEDA ou Knative demeure la norme industrielle.

Outils et utilitaires connexes

Tous les outils →
Générateur et Optimiseur de Configuration de Production Redis (redis.conf)Développement

Générez des fichiers de configuration redis.conf taillés pour la production avec gestion fine de maxmemory, persistance RDB/AOF, liaison réseau étanche et authentification ACL.

Ouvrir l'outil→
Guide Développeur : Optimiseur et Générateur Hardware pour PostgreSQL (postgresql.conf)Développement

Calculez et générez des paramètres postgresql.conf optimisés en fonction des spécifications matérielles (shared_buffers, work_mem, effective_cache_size, max_connections).

Ouvrir l'outil→
Guide Développeur du Générateur d'Unités Systemd (.timer et .service) sous LinuxDéveloppement

Créez et structurez des unités de minuterie systemd et des services associés prêts pour la production avec planification OnCalendar, intervalles OnBootSec, exécution Persistent et délais aléatoires.

Ouvrir l'outil→
Guide Développeur du Générateur de Configuration TypeScript (tsconfig.json)Développement

Générez des configurations tsconfig.json modernes et robustes pour Next.js, Node.js, Vite ou bibliothèques avec mode strict, alias de chemins et résolution de modules.

Ouvrir l'outil→
Guide Développeur : Générateur de DDL CREATE TABLE JSON vers ClickHouseDéveloppement

Convertissez des documents JSON en DDL SQL ClickHouse avec moteur MergeTree, types UInt/Int/Float/String/DateTime et mappage de colonnes Array/Nested.

Ouvrir l'outil→
Guide Développeur : Générateur de Schéma de Table Google BigQuery depuis JSONDéveloppement

Déduisez et convertissez des objets JSON en schémas de table Google Cloud BigQuery au format JSON avec prise en charge des types RECORD, STRING, INTEGER, NUMERIC et TIMESTAMP.

Ouvrir l'outil→