Scalabilità automatica orizzontale dei pod (HPA)

Questo documento descrive come abilitare la scalabilità automatica orizzontale dei pod (HPA) per Google Cloud Managed Service per Prometheus. Puoi attivare l'HPA in uno dei seguenti modi:

Devi scegliere un approccio oppure l'altro. Non puoi utilizzare entrambi perché le definizioni delle risorse si sovrappongono, come descritto in Risoluzione dei problemi.

Utilizza l'adattatore per le metriche personalizzate per Stackdriver

L'adattatore per metriche personalizzate di Stackdriver supporta l'esecuzione di query sulle metriche di Managed Service per Prometheus a partire dalla versione 0.13.1 dell'adattatore.

Per impostare una configurazione HPA di esempio utilizzando l'adattatore Stackdriver per metriche personalizzate:

  1. Configura la raccolta gestita nel tuo cluster.

  2. Installa l'adattatore Stackdriver per metriche personalizzate nel tuo cluster.

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter_new_resource_model.yaml

  3. Esegui il deployment di un esportatore di metriche Prometheus di esempio e di una risorsa HPA:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/examples/prometheus-to-sd/custom-metrics-prometheus-sd.yaml

    Questo comando esegue il deployment di un'applicazione di esportazione che emette la metrica foo e una risorsa HPA. L'HPA scala questa applicazione fino a 5 repliche per raggiungere il valore target per la metrica foo.

  4. Definisci una risorsa PodMonitoring inserendo la configurazione seguente in un file denominato podmonitoring.yaml.

    apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: prom-example
spec:
  selector:
    matchLabels:
      run: custom-metric-prometheus-sd
  endpoints:
  - port: 8080
    interval: 30s

  5. Esegui il deployment della nuova risorsa PodMonitoring:

    kubectl -n default apply -f podmonitoring.yaml

    Entro un paio di minuti, Managed Service per Prometheus elabora le metriche estrapolate dall'esportatore e le archivia in Cloud Monitoring utilizzando un nome nel formato lungo. Le metriche di Prometheus vengono archiviate con le seguenti convenzioni:

    • Il prefisso prometheus.googleapis.com.
    • In genere questo suffisso è uno dei seguenti: gauge, counter, summary o histogram, anche se le metriche non digitate potrebbero avere il suffisso unknown o unknown:counter. Per verificare il suffisso, cerca la metrica in Cloud Monitoring utilizzando Metrics Explorer.

  6. Aggiorna l'HPA di cui è stato eseguito il deployment per eseguire query sulla metrica da Cloud Monitoring. La metrica foo viene importata come prometheus.googleapis.com/foo/gauge. Per rendere la metrica interrogabile dalla risorsa HorizontalPodAutoscaler di cui è stato eseguito il deployment, devi utilizzare il nome nel formato lungo nell'HPA di cui è stato eseguito il deployment, ma devi modificarlo sostituendo tutte le barre (/) con il carattere barra verticale (|): prometheus.googleapis.com|foo|gauge. Per ulteriori informazioni, consulta la sezione Metriche disponibili da Stackdriver del repository dell'adattatore per le metriche personalizzate.

    1. Aggiorna l'HPA di cui è stato eseguito il deployment eseguendo questo comando:

      kubectl edit hpa custom-metric-prometheus-sd

    2. Modifica il valore del campo pods.metric.name da foo a prometheus.googleapis.com|foo|gauge. La sezione spec dovrebbe avere il seguente aspetto:

      spec:
   maxReplicas: 5
   metrics:
   - pods:
       metric:
         name: prometheus.googleapis.com|foo|gauge
       target:
         averageValue: "20"
         type: AverageValue
     type: Pods
   minReplicas: 1

    In questo esempio, la configurazione HPA cerca che il valore medio della metrica prometheus.googleapis.com/foo/gauge sia 20. Poiché il deployment imposta il valore della metrica su 40, il controller HPA aumenta il numero di pod fino al valore del campo maxReplicas (5) per cercare di ridurre il valore medio della metrica in tutti i pod a 20.

    La query HPA ha come ambito lo spazio dei nomi e il cluster in cui è installata la risorsa HPA, pertanto metriche identiche in altri cluster e spazi dei nomi non influiscono sulla scalabilità automatica.

  7. Per osservare lo scale up del carico di lavoro, esegui questo comando:

    kubectl get hpa custom-metric-prometheus-sd --watch

    Il valore del campo REPLICAS cambia da 1 a 5.

    NAME                          REFERENCE                                TARGETS        MINPODS   MAXPODS   REPLICAS   AGE
custom-metric-prometheus-sd   Deployment/custom-metric-prometheus-sd   40/20          1         5         5          *

  8. Per fare lo scale down del deployment, aggiorna il valore della metrica target in modo che sia superiore a quello della metrica esportata. In questo esempio, il deployment imposta il valore della metrica prometheus.googleapis.com/foo/gauge su 40. Se imposti il valore target su un numero superiore a 40, il deployment verrà fatto fare lo scale down.

    Ad esempio, utilizza kubectl edit per modificare il valore del campo pods.target.averageValue nella configurazione HPA da 20 a 100.

    kubectl edit hpa custom-metric-prometheus-sd

    Modifica la sezione delle specifiche in modo che corrisponda a quanto segue:

    spec:
  maxReplicas: 5
  metrics:
  - pods:
      metric:
        name: prometheus.googleapis.com|foo|gauge
      target:
        averageValue: "100"
        type: AverageValue
  type: Pods
  minReplicas: 1

  9. Per osservare lo fare lo scale down del carico di lavoro, esegui questo comando:

    kubectl get hpa custom-metric-prometheus-sd --watch

    Il valore del campo REPLICAS cambia da 5 a 1. In base alla progettazione, questo avviene più lentamente rispetto allo scale up del numero di pod:

    NAME                          REFERENCE                                TARGETS        MINPODS   MAXPODS   REPLICAS   AGE
custom-metric-prometheus-sd   Deployment/custom-metric-prometheus-sd   40/100          1         5         1          *

  10. Per eseguire la pulizia dell'esempio di cui è stato eseguito il deployment, esegui questi comandi:

    kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter_new_resource_model.yaml
kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/examples/prometheus-to-sd/custom-metrics-prometheus-sd.yaml
kubectl delete podmonitoring/prom-example

Per ulteriori informazioni, consulta l'esempio di Prometheus nel repository dell'adattatore per metriche personalizzate di Stackdriver o consulta Scalabilità di un'applicazione.

Utilizza l'adattatore Prometheus

Le configurazioni dell'adattatore Prometheus esistenti possono essere utilizzate per scalare automaticamente con poche modifiche. La configurazione dell'adattatore Prometheus per la scalabilità mediante Managed Service per Prometheus ha due limitazioni aggiuntive rispetto alla scalabilità mediante Prometheus a monte:

Poiché i dati possono richiedere un po' più di tempo per essere disponibili in Managed Service per Prometheus rispetto a quelli a monte di Prometheus, la configurazione della logica di scalabilità automatica eccessivamente entusiasta potrebbe causare comportamenti indesiderati. Sebbene non vi sia alcuna garanzia sull'aggiornamento dei dati, i dati sono in genere disponibili per le query 3-7 secondi dopo l'invio a Managed Service per Prometheus, escludendo qualsiasi latenza di rete.

Tutte le query eseguite dall'adattatore Prometheus hanno un ambito globale. Ciò significa che se hai applicazioni in due spazi dei nomi che emettono metriche con nomi identici, una configurazione HPA che utilizza questa metrica viene scalata utilizzando i dati di entrambe le applicazioni. Ti consigliamo di utilizzare sempre i filtri namespace o cluster in PromQL per evitare la scalabilità utilizzando dati errati.

Per impostare una configurazione HPA di esempio utilizzando l'adattatore Prometheus e la raccolta gestita, segui questi passaggi:

  1. Configura la raccolta gestita nel tuo cluster.
  2. Esegui il deployment del proxy UI frontend di Prometheus nel tuo cluster. Se utilizzi Workload Identity, devi anche configurare e autorizzare un account di servizio.
  3. Esegui il deployment dei manifest nella directory examples/hpa/ all'interno del repository prometheus-engine:
    • example-app.yaml: un deployment e un servizio di esempio che emette metriche.
    • pod-monitoring.yaml: una risorsa che configura lo scraping delle metriche di esempio.
    • hpa.yaml: la risorsa HPA che configura la scalabilità per il carico di lavoro.

  4. Assicurati che prometheus-adapter sia installato nel cluster. A questo scopo, puoi eseguire il deployment del manifest di installazione di esempio nel cluster. Questo manifest è configurato per:

    • Esegui una query su un proxy frontend di cui è stato eseguito il deployment nello spazio dei nomi default.
    • Invia PromQL per calcolare e restituire la metrica http_requests_per_second dal deployment di esempio.

  5. Esegui questi comandi, ciascuno in una sessione separata del terminale:

    1. Genera il carico HTTP sul servizio prometheus-example-app: 
      kubectl run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://prometheus-example-app; done"
    2. Guarda Horizontal Pod Autoscaler: 
      kubectl get hpa prometheus-example-app --watch
    3. Osserva lo scale up del carico di lavoro: 
      kubectl get po -lapp.kubernetes.io/name=prometheus-example-app --watch

  6. Interrompi la generazione del carico HTTP utilizzando Ctrl+C e osserva lo scale down del carico di lavoro.

Risoluzione dei problemi

L'adattatore Stackdriver per metriche personalizzate utilizza le definizioni di risorse con gli stessi nomi di quelli contenuti nell'adattatore Prometheus, ovvero prometheus-adapter. Questa sovrapposizione nei nomi significa che l'esecuzione di più adattatori nello stesso cluster causa errori.

Se installi l'adattatore Prometheus in un cluster sul quale in precedenza era installato l'adattatore Stackdriver per metriche personalizzate, potresti generare errori come FailedGetObjectMetric a causa di nomi in conflitto. Per risolvere il problema, potresti dover eliminare gli apiservices v1beta1.external.metrics.k8s.io, v1beta1.custom.metrics.k8s.io e v1beta2.custom.metrics.k8s.io precedentemente registrati dall'adattatore delle metriche personalizzate.

Suggerimenti per la risoluzione dei problemi:

  • Alcune metriche di sistema di Cloud Monitoring, come le metriche Pub/Sub, hanno un ritardo di almeno 60 secondi. Poiché l'adattatore Prometheus esegue le query utilizzando il timestamp corrente, eseguire query su queste metriche utilizzando l'adattatore Prometheus potrebbe causare erroneamente l'assenza di dati. Per eseguire query sulle metriche ritardate, utilizza il modificatore offset in PromQL per modificare lo offset temporale della query in base alla quantità necessaria.

  • Per verificare che il proxy UI frontend funzioni come previsto e non ci siano problemi con le autorizzazioni, esegui questo comando in un terminale:

    kubectl -n NAMESPACE_NAME port-forward svc/frontend 9090

    Quindi, apri un altro terminale ed esegui questo comando:

    curl --silent 'localhost:9090/api/v1/series?match%5B%5D=up'

    Quando il proxy dell'interfaccia utente frontend funziona correttamente, la risposta nel secondo terminale è simile alla seguente:

    curl --silent 'localhost:9090/api/v1/series?match%5B%5D=up' | jq .
{
  "status": "success",
  "data": [
     ...
  ]
}

    Se ricevi un errore 403, significa che il proxy dell'interfaccia utente frontend non è configurato correttamente. Per informazioni su come risolvere l'errore 403, consulta la guida relativa alla configurazione e autorizzazione di un account di servizio.

  • Per verificare che l'apiserver delle metriche personalizzate sia disponibile, esegui questo comando:

    kubectl get apiservices.apiregistration.k8s.io v1beta1.custom.metrics.k8s.io

    Quando l'apiserver è disponibile, la risposta è simile alla seguente:

    $ kubectl get apiservices.apiregistration.k8s.io v1beta1.custom.metrics.k8s.io
NAME                            SERVICE                         AVAILABLE   AGE
v1beta1.custom.metrics.k8s.io   monitoring/prometheus-adapter   True        33m

  • Per verificare che l'HPA funzioni come previsto, esegui questo comando:

    $ kubectl describe hpa prometheus-example-app
Name:                                  prometheus-example-app
Namespace:                             default
Labels:                                
Annotations:                           
Reference:                             Deployment/prometheus-example-app
Metrics:                               ( current / target )
"http_requests_per_second" on pods:  11500m / 10
Min replicas:                          1
Max replicas:                          10
Deployment pods:                       2 current / 2 desired
Conditions:
Type            Status  Reason              Message
----            ------  ------              -------
AbleToScale     True    ReadyForNewScale    recommended size matches current size
ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from pods metric http_requests_per_second
ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
Events:
Type     Reason               Age                   From                       Message
----     ------               ----                  ----                       -------
Normal   SuccessfulRescale    47s                   horizontal-pod-autoscaler  New size: 2; reason: pods metric http_requests_per_second above target

    Quando la risposta contiene un'istruzione come FailedGetPodsMetric, si verifica l'errore HPA. Di seguito è riportata una risposta alla chiamata describe quando l'HPA ha esito negativo:

    $ kubectl describe hpa prometheus-example-app
Name:                                  prometheus-example-app
Namespace:                             default
Reference:                             Deployment/prometheus-example-app
Metrics:                               ( current / target )
  "http_requests_per_second" on pods:   / 10
Min replicas:                          1
Max replicas:                          10
Deployment pods:                       1 current / 1 desired
Conditions:
  Type            Status  Reason               Message
  ----            ------  ------               -------
  AbleToScale     True    ReadyForNewScale     recommended size matches current size
  ScalingActive   False   FailedGetPodsMetric  the HPA was unable to compute the replica count: unable to get metric http_requests_per_second: unable to fetch metrics from custom metrics API: the server could not find the metric http_requests_per_second for pods
  ScalingLimited  False   DesiredWithinRange   the desired count is within the acceptable range
Events:
  Type     Reason               Age                   From                       Message
  ----     ------               ----                  ----                       -------
  Warning  FailedGetPodsMetric  104s (x11 over 16m)   horizontal-pod-autoscaler  unable to get metric http_requests_per_second: unable to fetch metrics from custom metrics API: the server could not find the metric http_requests_per_second for pods

    Quando l'HPA restituisce un errore, assicurati di generare metriche con load-generator. Puoi controllare direttamente l'API delle metriche personalizzate con il comando:

    kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/" | jq .

    Un output corretto dovrebbe essere simile a questo:

    $ kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/" | jq .
  {
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "custom.metrics.k8s.io/v1beta1",
  "resources": [
     {
        "name": "namespaces/http_requests_per_second",
        "singularName": "",
        "namespaced": false,
        "kind": "MetricValueList",
        "verbs": [
        "get"
        ]
     },
     {
        "name": "pods/http_requests_per_second",
        "singularName": "",
        "namespaced": true,
        "kind": "MetricValueList",
        "verbs": [
        "get"
        ]
     }
  ]
  }

    Se non sono presenti metriche, non ci saranno dati in "resources" nell'output, ad esempio:

    kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/" | jq .
{
"kind": "APIResourceList",
"apiVersion": "v1",
"groupVersion": "custom.metrics.k8s.io/v1beta1",
"resources": []
}