Centro di Conoscenza DevOps
Centro di Conoscenza DevOps

Una Guida Pratica all'Ottimizzazione dell'Horizontal Pod Autoscaler (HPA) di Kubernetes

Massimizza le prestazioni ottimali delle tue applicazioni e l'efficienza dei costi con questa guida pratica all'ottimizzazione dell'Horizontal Pod Autoscaler (HPA) di Kubernetes. Impara a configurare HPA utilizzando metriche CPU, personalizzate ed esterne, e a padroneggiare i comportamenti di scaling avanzati con `stabilizationWindowSeconds` e `policies`. Questo articolo fornisce passaggi concreti, esempi di codice e migliori pratiche per garantire che i tuoi deployment Kubernetes si adattino dinamicamente ai carichi fluttuanti, prevengano l'eccessivo provisioning delle risorse e mantengano un'elevata disponibilità.

30 visualizzazioni

Una Guida Pratica all'Ottimizzazione dell'Horizontal Pod Autoscaler (HPA) di Kubernetes

Kubernetes ha rivoluzionato il modo in cui le applicazioni vengono deployate, gestite e scalate. Al centro delle sue capacità di scaling si trova l'Horizontal Pod Autoscaler (HPA), un potente meccanismo che regola automaticamente il numero di repliche di pod in un deployment, replication controller, replicaset o statefulset in base all'utilizzo osservato della CPU o ad altre metriche selezionate. Sebbene l'HPA offra immensi vantaggi per la gestione di carichi fluttuanti, il suo vero potenziale si sblocca attraverso un'attenta configurazione e ottimizzazione.

Questa guida approfondisce gli aspetti pratici della configurazione e dell'ottimizzazione dell'Horizontal Pod Autoscaler di Kubernetes. Tratteremo concetti fondamentali, parametri chiave, strategie di ottimizzazione avanzate e best practice per garantire che le tue applicazioni possano adattarsi efficientemente alla domanda, mantenere le prestazioni sotto carichi variabili e ottimizzare i costi dell'infrastruttura. Alla fine di questo articolo, avrai una solida comprensione di come sfruttare appieno l'HPA.

Comprendere l'Horizontal Pod Autoscaler (HPA)

L'HPA scala automaticamente il numero di pod nella tua applicazione, aumentandoli o diminuendoli per corrispondere alla domanda attuale. Monitora continuamente le metriche specificate e le confronta con i valori target. Se la metrica osservata supera il target, l'HPA avvia un evento di scale-up; se scende al di sotto, attiva un scale-down. Questa regolazione dinamica assicura che la tua applicazione disponga di risorse sufficienti per funzionare in modo ottimale senza un provisioning eccessivo.

L'HPA può scalare in base a:

  • Metriche delle Risorse: Principalmente utilizzo della CPU e utilizzo della memoria (disponibili tramite l'API metrics.k8s.io, solitamente servita dal Kubernetes Metrics Server).
  • Metriche Personalizzate: Metriche specifiche dell'applicazione esposte tramite l'API custom.metrics.k8s.io (ad es., richieste al secondo, profondità della coda, connessioni attive). Queste richiedono tipicamente un adattatore come prometheus-adapter.
  • Metriche Esterne: Metriche provenienti da fonti esterne al cluster esposte tramite l'API external.metrics.k8s.io (ad es., dimensione della coda di Google Cloud Pub/Sub, lunghezza della coda di AWS SQS). Anche queste richiedono un server API di metriche personalizzate in grado di recuperare metriche esterne.

Prerequisiti per un'Ottimizzazione Efficace dell'HPA

Prima di immergerti nelle configurazioni HPA, assicurati che questi elementi fondamentali siano presenti:

1. Definire Richieste e Limiti di Risorse Accurati

Questo è forse il prerequisito più cruciale. L'HPA si basa fortemente su richieste di CPU e memoria correttamente definite per calcolare le percentuali di utilizzo. Se un pod non ha richieste di CPU definite, l'HPA non può calcolare il suo utilizzo della CPU, rendendo impossibile lo scaling basato sulla CPU.

  • Requests (Richieste): Definiscono le risorse minime garantite per i tuoi container. L'HPA utilizza questi valori per determinare l'utilizzo target per pod.
  • Limits (Limiti): Definiscono le risorse massime che un container può consumare. I limiti impediscono a un singolo pod di consumare risorse eccessive e di influenzare altri pod sullo stesso nodo.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: my-image:latest
        resources:
          requests:
            cpu: "200m"  # 20% of a CPU core
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"

2. Installare il Kubernetes Metrics Server

Affinché l'HPA utilizzi le metriche di utilizzo della CPU e della memoria, il Kubernetes Metrics Server deve essere installato nel tuo cluster. Raccoglie le metriche delle risorse dai Kubelet e le espone tramite l'API metrics.k8s.io.

3. Osservabilità dell'Applicazione

Per metriche personalizzate o esterne, la tua applicazione deve esporre le metriche pertinenti (ad es., tramite un endpoint Prometheus) e avrai bisogno di un modo per raccogliere ed esporre queste metriche all'API di Kubernetes, tipicamente utilizzando un adattatore Prometheus o un server API di metriche personalizzate.

Configurazione HPA: Parametri Chiave

Esaminiamo la struttura base di un manifest HPA:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Parametri chiave:

  • scaleTargetRef: Definisce la risorsa target (ad es., Deployment) che l'HPA scalerà. Specifica apiVersion, kind e name.
  • minReplicas: Il numero minimo di pod a cui l'HPA si ridurrà. È buona pratica impostarlo ad almeno 1 o 2 per alta disponibilità, anche sotto carico zero.
  • maxReplicas: Il numero massimo di pod a cui l'HPA si espanderà. Questo agisce come una salvaguardia contro scaling incontrollati e limita i costi.
  • metrics: Un array che definisce le metriche che l'HPA dovrebbe monitorare.
    • type: Può essere Resource, Pods, Object o External.
    • resource.name: Per il tipo Resource, specifica cpu o memory.
    • target.type: Per il tipo Resource, Utilization (percentuale di risorsa richiesta) o AverageValue (valore assoluto).
    • averageUtilization: Per il tipo Utilization, la percentuale target. L'HPA calcola il numero desiderato di pod basandosi su current_utilization / target_utilization * current_pods_count.

Ottimizzazione dell'HPA per Reattività e Stabilità

Oltre la configurazione di base, l'HPA offre opzioni di ottimizzazione avanzate, specialmente con autoscaling/v2 (o v2beta2 nelle versioni più vecchie), per gestire il comportamento di scaling in modo più granulare.

1. Target di CPU e Memoria (averageUtilization / averageValue)

Impostare la giusta utilizzazione target è cruciale. Un target inferiore significa scaling più precoce (più reattivo, potenzialmente più costoso), mentre un target superiore significa scaling più tardivo (meno reattivo, potenzialmente più economico ma con rischio di degrado delle prestazioni).

  • Come Determinare i Target Ottimali: Il load testing e la profilazione sono i tuoi migliori amici. Aumenta gradualmente il carico sulla tua applicazione mentre monitori l'utilizzo delle risorse e le metriche di performance (latenza, tassi di errore). Identifica l'utilizzo di CPU/memoria al quale la tua applicazione inizia a degradare le prestazioni. Imposta il tuo target HPA al di sotto di questa soglia, tipicamente nell'intervallo 60-80% per la CPU.
  • Atto di Bilanciamento: Punta a un target che lasci un margine sufficiente per picchi imprevisti ma che non sia così basso da risultare costantemente sovra-provisionato.

2. Comportamento di Scaling (campo behavior)

Introdotto in HPA autoscaling/v2, il campo behavior fornisce un controllo granulare sugli eventi di scale-up e scale-down, prevenendo il "thrashing" (cicli rapidi di scale-up e scale-down).

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60 # Wait 60s before scaling up again
      policies:
      - type: Pods
        value: 4
        periodSeconds: 15 # Add max 4 pods every 15 seconds
      - type: Percent
        value: 100
        periodSeconds: 15 # Or double the current pods every 15 seconds (whichever is less restrictive)
    scaleDown:
      stabilizationWindowSeconds: 300 # Wait 5 minutes before scaling down
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60 # Remove max 50% of pods every 60 seconds
      selectPolicy: Max # Choose the policy that allows for the 'most aggressive' (least number of) pods

Configurazione scaleUp:

  • stabilizationWindowSeconds: Questo previene cicli rapidi di scale-up e scale-down (flapping). L'HPA considera le metriche di questa finestra temporale quando esegue lo scale-up, assicurando che si ridimensioni solo se la metrica più alta persiste. Un valore tipico è 30-60 secondi.
  • policies: Definisce come vengono aggiunti i pod durante un evento di scale-up. Puoi definire più policy, e l'HPA userà quella che consente il numero più alto di pod (scale-up più aggressivo).
    • type: Pods: Aumenta di un numero fisso di pod. value specifica il numero di pod da aggiungere. periodSeconds definisce la finestra temporale in cui questa policy si applica.
    • type: Percent: Aumenta di una percentuale del conteggio attuale dei pod. value è la percentuale.

Configurazione scaleDown:

  • stabilizationWindowSeconds: Più critico per lo scaleDown, specifica per quanto tempo l'HPA deve osservare le metriche al di sotto del target prima di considerare la riduzione. Una finestra più lunga (ad es., 300-600 secondi) previene scale-down prematuri durante cali temporanei, evitando "cold starts" e cali di performance. Questa è un'impostazione cruciale per ambienti stabili.
  • policies: Simile a scaleUp, definisce come vengono rimossi i pod. L'HPA utilizza la policy che si traduce nel numero più basso di pod (scale-down più aggressivo) se selectPolicy è Min, o la policy che si traduce nel numero più alto di pod se selectPolicy è Max.
    • type: Pods: Rimuove un numero fisso di pod.
    • type: Percent: Rimuove una percentuale dei pod attuali.

  • selectPolicy: Determina quale policy applicare quando vengono definite più policy scaleDown. Min è il default e generalmente raccomandato per un downscaling più conservativo; Max selezionerebbe la policy che si traduce nel maggior numero di pod (downscaling meno aggressivo).

  • Attenzione: Fai attenzione con policy di scaleDown aggressive o stabilizationWindowSeconds brevi per lo scaleDown. Se la tua applicazione ha lunghi tempi di inizializzazione o gestisce connessioni stateful, un downscaling rapido può portare a interruzioni del servizio o maggiore latenza per gli utenti.

Metriche e Strategie HPA Avanzate

Mentre CPU e memoria sono comuni, molte applicazioni scalano meglio su metriche personalizzate o esterne che riflettono il loro carico di lavoro effettivo.

1. Metriche Personalizzate

Usa metriche personalizzate quando CPU/memoria non sono un indicatore diretto del carico o del collo di bottiglia delle prestazioni della tua applicazione. Esempi: richieste HTTP al secondo (QPS), connessioni attive, lunghezza della coda di messaggi, backlog di job batch.

Per usare metriche personalizzate:
1. La tua applicazione deve esporre queste metriche (ad es., tramite un exporter Prometheus).
2. Implementa un adattatore di metriche personalizzate (ad es., prometheus-adapter) che possa raccogliere queste metriche ed esporle tramite l'API custom.metrics.k8s.io.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa-qps
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 15
  metrics:
  - type: Pods # Or Object if the metric is for the deployment as a whole
    pods:
      metric:
        name: http_requests_per_second # The name of the metric exposed by your application/adapter
      target:
        type: AverageValue
        averageValue: "10k" # Target 10,000 requests per second per pod

2. Metriche Esterne

Le metriche esterne sono utili quando il carico di lavoro della tua applicazione è guidato da un sistema esterno non direttamente in esecuzione su Kubernetes. Esempi: profondità della coda AWS SQS, lag di un topic Kafka, backlog di una sottoscrizione Pub/Sub.

Per usare metriche esterne:
1. Hai bisogno di un server API di metriche personalizzate in grado di recuperare metriche dal tuo sistema esterno (ad es., un adattatore specifico per AWS CloudWatch o GCP Monitoring).

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-worker-hpa-sqs
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-worker
  minReplicas: 1
  maxReplicas: 20
  metrics:
  - type: External
    external:
      metric:
        name: aws_sqs_queue_messages_visible # Metric name from your external source
        selector:
          matchLabels:
            queue: my-queue-name
      target:
        type: AverageValue
        averageValue: "100" # Target 100 messages visible in the queue per pod

3. Metriche Multiple

L'HPA può essere configurato per monitorare più metriche contemporaneamente. Quando vengono specificate più metriche, l'HPA calcola il numero di repliche desiderato per ogni metrica in modo indipendente e quindi seleziona il più alto di questi conteggi di repliche desiderati. Questo assicura che l'applicazione si ridimensioni sufficientemente per tutte le dimensioni di carico osservate.

# ... (HPA boilerplate)
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "10k"

Monitoraggio e Validazione

L'ottimizzazione efficace dell'HPA è un processo iterativo che richiede monitoraggio e validazione continui:

  • Osservare gli Eventi HPA: Usa kubectl describe hpa <nome-hpa> per vedere lo stato, gli eventi e le decisioni di scaling dell'HPA. Questo fornisce preziose intuizioni sul motivo per cui l'HPA ha scalato su o giù.
  • Monitorare Metriche e Repliche: Usa il tuo stack di osservabilità (ad es., Prometheus, Grafana) per visualizzare l'utilizzo delle risorse della tua applicazione (CPU, memoria), metriche personalizzate/esterne e il numero effettivo di repliche di pod nel tempo. Correlali con i cambiamenti nel carico in entrata.
  • Test di Carico: Simula carichi previsti e di picco per convalidare la reattività dell'HPA e assicurare che la tua applicazione funzioni come previsto sotto stress. Regola i parametri HPA in base a questi test.

Best Practice per l'Ottimizzazione dell'HPA

  • Inizia con Richieste/Limiti di Risorse Ben Definiti: Sono il fondamento di un HPA basato sulle risorse accurato. Senza di essi, l'HPA non può funzionare efficacemente per CPU/memoria.
  • Imposta minReplicas e maxReplicas Realistici: minReplicas fornisce una base per la disponibilità, mentre maxReplicas agisce come una rete di sicurezza contro costi incontrollati e l'esaurimento delle risorse.
  • Regola Gradualmente l'Utilizzo Target: Inizia con un target di CPU leggermente conservativo (ad es., 60-70%) e itera. Non puntare al 100% di utilizzo, poiché non lascia alcun buffer per latenza o picchi di elaborazione.
  • Sfrutta stabilizationWindowSeconds: Essenziale per prevenire rapide oscillazioni di scaling. Usa una finestra più lunga per scaleDown (ad es., 5-10 minuti) rispetto a scaleUp (ad es., 1-2 minuti) per garantire la stabilità.
  • Dai Priorità alle Metriche Specifiche dell'Applicazione: Se CPU o memoria non correlano direttamente con i colli di bottiglia delle prestazioni della tua applicazione, usa metriche personalizzate o esterne per uno scaling più accurato ed efficiente.
  • Monitora, Testa, Itera: L'ottimizzazione dell'HPA non è una configurazione una tantum. Il comportamento dell'applicazione, i pattern di traffico e l'infrastruttura sottostante possono cambiare. Rivedi regolarmente le prestazioni dell'HPA e regola le impostazioni secondo necessità.
  • Comprendi le Caratteristiche di Scaling della Tua Applicazione: Scala linearmente con le richieste? Ha lunghi tempi di avvio? È stateful? Queste caratteristiche influenzano la tua strategia HPA.

Conclusione

L'Horizontal Pod Autoscaler di Kubernetes è un componente critico per la costruzione di applicazioni resilienti, economiche e performanti in un ambiente Kubernetes. Comprendendo i suoi meccanismi fondamentali, definendo richieste di risorse accurate e ottimizzando attentamente i suoi parametri di comportamento di scaling, puoi assicurare che le tue applicazioni si adattino automaticamente a carichi variabili con precisione.

L'ottimizzazione efficace dell'HPA è un viaggio continuo di misurazione, osservazione e regolazione. Abbraccia il processo iterativo, sfrutta le metriche avanzate dove appropriato e monitora continuamente le prestazioni della tua applicazione per sbloccare il pieno potenziale dello scaling dinamico all'interno di Kubernetes.