Informazioni sulle configurazioni dell'utilità di ridimensionamento
La v2 versione dell'API HPA consente di ottimizzare alcuni aspetti del comportamento usando una nuova chiave nel file YAML denominato spec.behavior. Accetta due altre chiavi: scaleDown e scaleUp, che definiscono il comportamento dell'HPA quando si riduce e quando si aumentano le prestazioni.
Sono consentiti i valori seguenti per ognuna di queste chiavi:
| Chiave | Type | Descrizione |
|---|---|---|
| stabilizationWindowSeconds | int | Periodo in cui HPA cerca le metriche per calcolare lo stato desiderato. Il valore predefinito per scaleDown è di cinque minuti e non esiste alcuna finestra di stabilizzazione per scaleUp. |
| selectPolicy | string | Tipo di criterio selezionato da usare. Questo valore può essere Min, Max o Disabled. |
| criteri | matrice di HPAScalingPolicy |
Matrice di possibili criteri da applicare. |
L'oggetto HPAScalingPolicy è definito come oggetto con le chiavi seguenti:
| Chiave | Type | Descrizione |
|---|---|---|
| type | string | Tipo di criterio; può essere Percent o Pods. |
| value | int | Valore del criterio. |
| periodSeconds | int | Periodo di tempo necessario prima che questo criterio possa essere applicato di nuovo. |
I criteri di ridimensionamento consentono di ottimizzare il funzionamento del ridimensionamento. Ad esempio, è possibile disabilitare completamente l'operazione di riduzione impostando un scaleDown criterio su Disabled, come illustrato nell'esempio seguente:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: contoso-website
namespace: hpa-contoso
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: contoso-website
minReplicas: 1
maxReplicas: 10
behavior:
scaleDown:
selectPolicy: Disabled
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 20
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 50
È anche possibile impostare il numero di repliche da aumentare in una volta definendo un criterio scaleUp, in questo modo:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: contoso-website
namespace: hpa-contoso
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: contoso-website
minReplicas: 1
maxReplicas: 10
behavior:
scaleUp:
selectPolicy: Max
stabilizationWindowSeconds: 120
policies:
- type: Percent
value: 30
periodSeconds: 60
- type: Pods
value: 7
periodSeconds: 90
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 20
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 50
In questo manifesto si indica all'HPA di cercare gli ultimi 120 secondi di metriche per calcolare lo stato desiderato e ottenere il massimo di questi valori. Al termine, calcola il 30% dei pod esistenti, arrotonda questo numero e lo confronta con il valore fisso di sette pod. selectPolicy Poiché è impostato su Max, accetta il numero maggiore di questi due numeri e applica tale criterio, quindi attende periodSeconds prima di applicare nuovamente i criteri.
Si supponga, ad esempio, che il sito Web sia in esecuzione con 18 pod e quindi si verifichi un picco che dura circa 120 secondi. Lo stato desiderato viene ottenuto calcolando il 30% dei pod correnti in esecuzione, ovvero 5,4 (arrotondato a 6). Questo valore viene confrontato con il numero di pod nel secondo criterio, ovvero 7. Poiché la selectPolicy chiave è impostata su Max, usa il valore più grande di questi due valori. L'HPA viene quindi ridimensionato di 7 e attende 90 secondi prima di aumentare nuovamente le prestazioni. Se il picco ha continuato fino a 25 pod, il calcolo viene eseguito di nuovo. Il 30% di 25 pod è 7,5 (arrotondato a 8) ed è maggiore di 7. A questo momento, HPA crea otto nuovi pod e attende 60 secondi prima di aumentare di nuovo le prestazioni.