Riduzione dei costi con lo scale down dei cluster GKE durante le ore di punta

Last reviewed 2022-11-24 UTC

Questo tutorial spiega come ridurre i costi eseguendo il deployment di un gestore della scalabilità automatica pianificato su Google Kubernetes Engine (GKE). Questo tipo di gestore della scalabilità automatica esegue lo scale up o lo scale down dei cluster in base a una pianificazione in base all'ora del giorno o al giorno della settimana. Un gestore della scalabilità automatica pianificato è utile se il tuo traffico presenta un flusso e un flusso prevedibili, ad esempio se sei un rivenditore regionale o se il tuo software è per dipendenti il cui orario di lavoro è limitato a una parte specifica della giornata.

Il tutorial è rivolto agli sviluppatori e agli operatori che vogliono fare lo scale up dei cluster in modo affidabile prima dell'arrivo dei picchi e poi ridimensionarli per risparmiare denaro la sera, nei fine settimana o in qualsiasi altro momento quando meno utenti sono online. In questo articolo si presume che tu abbia familiarità con Docker, Kubernetes, Kubernetes CronJob, GKE e Linux.

Introduzione

Molte applicazioni presentano modelli di traffico non uniformi. Ad esempio, i lavoratori di un'organizzazione potrebbero utilizzare un'applicazione solo durante il giorno. Di conseguenza, i server del data center per quell'applicazione sono inattivi di notte.

Oltre ad altri vantaggi, Google Cloud può aiutarti a risparmiare denaro tramite l'allocazione dinamica dell'infrastruttura in base al carico del traffico. In alcuni casi, una semplice configurazione con scalabilità automatica può gestire la difficoltà di allocazione del traffico non uniforme. Se è il tuo caso, non abbandonare il video. Tuttavia, in altri casi, cambiamenti improvvisi nei pattern di traffico richiedono configurazioni di scalabilità automatica più precise per evitare l'instabilità del sistema durante lo scale up ed evitare l'overprovisioning del cluster.

Questo tutorial si concentra sugli scenari in cui le variazioni brusche dei modelli di traffico sono ben comprese e vuoi fornire suggerimenti al gestore della scalabilità automatica che la tua infrastruttura sta per subire picchi. Questo documento mostra come fare lo scale up dei cluster GKE al mattino e lo scale down alla sera, ma puoi utilizzare un approccio simile per aumentare e ridurre la capacità per tutti gli eventi noti, come eventi di picco di scalabilità, campagne pubblicitarie, traffico nel fine settimana e così via.

Fare lo scale down di un cluster se disponi di sconti per impegno di utilizzo

Questo tutorial spiega come ridurre i costi riducendo al minimo i tuoi cluster GKE al di fuori delle ore di punta. Tuttavia, se hai acquistato uno sconto per impegno di utilizzo, è importante capire come funzionano questi sconti in combinazione con la scalabilità automatica.

I contratti per impegno di utilizzo ti offrono prezzi molto scontati quando ti impegni a pagare per una quantità prestabilita di risorse (vCPU, memoria e altre). Tuttavia, per determinare la quantità di risorse da impegnare, devi sapere in anticipo quante risorse vengono utilizzate dai carichi di lavoro nel tempo. Per aiutarti a ridurre i costi, il seguente diagramma illustra le risorse da includere nella pianificazione.

Distribuzione di risorse, con visualizzazione di una base di risorse impegnate sempre allocate e di risorse con scalabilità automatica in risposta alla domanda (picchi).

Come mostra il diagramma, l'allocazione delle risorse in un contratto per impegno di utilizzo è fissa. Le risorse coperte dal contratto devono essere utilizzate la maggior parte del tempo per poter valere l'impegno assunto. Pertanto, non devi includere risorse utilizzate durante i picchi nel calcolo delle risorse impegnate. Per risorse elevate, consigliamo di utilizzare le opzioni di scalabilità automatica di GKE. Queste opzioni includono il gestore della scalabilità automatica pianificato discusso in questo articolo o altre opzioni gestite descritte in Best practice per l'esecuzione di applicazioni Kubernetes con ottimizzazione dei costi su GKE.

Se hai già un contratto per impegno di utilizzo per una determinata quantità di risorse, non puoi ridurre i costi facendo lo scale down del tuo cluster al di sotto di questo valore minimo. In questi scenari, ti consigliamo di provare a pianificare alcuni job per colmare le lacune durante i periodi di bassa domanda di computing.

Architettura

Il seguente diagramma mostra l'architettura dell'infrastruttura e del gestore della scalabilità automatica pianificata di cui esegui il deployment in questo tutorial. Il gestore della scalabilità automatica pianificato è costituito da un insieme di componenti che lavorano insieme per gestire la scalabilità in base a una pianificazione.

Architettura che mostra i componenti che insieme costituiscono il gestore della scalabilità automatica pianificata.

In questa architettura, un set di CronJobs Kubernetes esporta informazioni note sui pattern di traffico in una metrica personalizzata di Cloud Monitoring. Questi dati vengono poi letti da un Horizontal Pod Autoscaler (HPA) di Kubernetes come input per capire quando l'HPA dovrebbe scalare il carico di lavoro. Insieme ad altre metriche di carico, come l'utilizzo target della CPU, l'HPA decide come scalare le repliche per un determinato deployment.

Obiettivi

  • Creare un cluster GKE.
  • Eseguire il deployment di un'applicazione di esempio che utilizza un HPA di Kubernetes.
  • Imposta i componenti per il gestore della scalabilità automatica pianificato e aggiorna l'HPA in modo che legga da una metrica personalizzata pianificata.
  • Configura un avviso da attivare quando il gestore della scalabilità automatica pianificato non funziona correttamente.
  • Generare il carico sull'applicazione.
  • Esamina in che modo l'HPA risponde ai normali aumenti del traffico e alle metriche personalizzate pianificate che configuri.

Il codice per questo tutorial si trova in un repository GitHub.

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud possono essere idonei a una prova senza costi aggiuntivi.

Prima di iniziare

  1. Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.

  2. Nella pagina del selettore di progetti della console Google Cloud, seleziona o crea un progetto Google Cloud.

    Vai al selettore progetti

  3. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

  4. Abilita le API GKE, Artifact Registry and the Cloud Monitoring.

    Abilita le API

    5.

  5. Nella pagina del selettore di progetti della console Google Cloud, seleziona o crea un progetto Google Cloud.

    Vai al selettore progetti

  6. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

  7. Abilita le API GKE, Artifact Registry and the Cloud Monitoring.

    Abilita le API

    8.

prepara l'ambiente

  1. Nella console Google Cloud, attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell che mostra un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installato e con valori già impostati per il progetto attuale. L'inizializzazione della sessione può richiedere alcuni secondi.

  2. In Cloud Shell, configura l'ID progetto Google Cloud, il tuo indirizzo email, la zona di computing e la regione:

    PROJECT_ID=YOUR_PROJECT_ID
ALERT_EMAIL=YOUR_EMAIL_ADDRESS
gcloud config set project $PROJECT_ID
gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-f

    Sostituisci quanto segue:

    • YOUR_PROJECT_ID: il nome del progetto Google Cloud in uso.
    • YOUR_EMAIL_ADDRESS: un indirizzo email per ricevere notifiche quando il gestore della scalabilità automatica pianificato non funziona correttamente.

    Se vuoi, puoi scegliere una regione e una zona diverse per questo tutorial.

  3. Clona il repository GitHub di kubernetes-engine-samples:

    git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples/
cd kubernetes-engine-samples/cost-optimization/gke-scheduled-autoscaler

    Il codice di questo esempio è strutturato nelle seguenti cartelle:

    • Root: contiene il codice utilizzato dai CronJob per esportare le metriche personalizzate in Cloud Monitoring.
    • k8s/: contiene un esempio di deployment con un HPA di Kubernetes.
    • k8s/scheduled-autoscaler/: contiene i CronJob che esportano una metrica personalizzata e una versione aggiornata dell'HPA per la lettura da una metrica personalizzata.
    • k8s/load-generator/: contiene un deployment Kubernetes con un'applicazione per simulare l'utilizzo orario.
    • monitoring/: contiene i componenti di Cloud Monitoring che configuri in questo tutorial.

Crea il cluster GKE

  1. In Cloud Shell, crea un cluster GKE per eseguire il gestore della scalabilità automatica pianificato:

    gcloud container clusters create scheduled-autoscaler \
    --enable-ip-alias \
    --release-channel=stable \
    --machine-type=e2-standard-2 \
    --enable-autoscaling --min-nodes=1 --max-nodes=10 \
    --num-nodes=1 \
    --autoscaling-profile=optimize-utilization

    L'output è simile al seguente:

    NAME                   LOCATION       MASTER_VERSION   MASTER_IP      MACHINE_TYPE   NODE_VERSION     NUM_NODES  STATUS
scheduled-autoscaler   us-central1-f  1.22.15-gke.100  34.69.187.253  e2-standard-2  1.22.15-gke.100  1          RUNNING

    Questa non è una configurazione di produzione, ma è adatta per questo tutorial. In questa configurazione, configuri il gestore della scalabilità automatica dei cluster con un minimo di 1 nodo e un massimo di 10 nodi. Puoi anche abilitare il profilo optimize-utilization per accelerare il processo di scale down.

Esegui il deployment dell'applicazione di esempio

  1. Esegui il deployment dell'applicazione di esempio senza il gestore della scalabilità automatica pianificato:

    kubectl apply -f ./k8s

  2. Apri il file k8s/hpa-example.yaml.

    Nell'elenco che segue vengono mostrati i contenuti del file.

    spec:
  maxReplicas: 20
  minReplicas: 10
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60

    Nota che il numero minimo di repliche (minReplicas) è impostato su 10. Questa configurazione imposta anche la scalabilità del cluster in base all'utilizzo della CPU (le impostazioni name: cpu e type: Utilization).

  3. Attendi che l'applicazione diventi disponibile:

    kubectl wait --for=condition=available --timeout=600s deployment/php-apache
EXTERNAL_IP=''
while [ -z $EXTERNAL_IP ]
do
    EXTERNAL_IP=$(kubectl get svc php-apache -o jsonpath={.status.loadBalancer.ingress[0].ip})
    [ -z $EXTERNAL_IP ] && sleep 10
done
curl -w '\n' http://$EXTERNAL_IP

    Quando l'applicazione è disponibile, l'output è il seguente:

    OK!

  4. Verifica le impostazioni:

    kubectl get hpa php-apache

    L'output è simile al seguente:

    NAME         REFERENCE               TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache   9%/60%    10        20        10         6d19h

    La colonna REPLICAS mostra 10, che corrisponde al valore del campo minReplicas nel file hpa-example.yaml.

  5. Controlla se il numero di nodi è aumentato a 4:

    kubectl get nodes

    L'output è simile al seguente:

    NAME                                                  STATUS   ROLES    AGE   VERSION
gke-scheduled-autoscaler-default-pool-64c02c0b-9kbt   Ready    <none>   21S   v1.17.9-gke.1504
gke-scheduled-autoscaler-default-pool-64c02c0b-ghfr   Ready    <none>   21s   v1.17.9-gke.1504
gke-scheduled-autoscaler-default-pool-64c02c0b-gvl9   Ready    <none>   21s   v1.17.9-gke.1504
gke-scheduled-autoscaler-default-pool-64c02c0b-t9sr   Ready    <none>   21s   v1.17.9-gke.1504

    Quando hai creato il cluster, hai impostato una configurazione minima utilizzando il flag min-nodes=1. Tuttavia, l'applicazione di cui hai eseguito il deployment all'inizio di questa procedura richiede una maggiore infrastruttura perché il valore minReplicas nel file hpa-example.yaml è impostato su 10.

    L'impostazione di minReplicas su un valore simile a 10 è una strategia comune utilizzata dalle aziende, come i rivenditori, che prevede un improvviso aumento del traffico nelle prime ore del giorno lavorativo. Tuttavia, l'impostazione di valori elevati per l'attributo minReplicas HPA può aumentare i costi perché il cluster non può ridursi, nemmeno di notte, quando il traffico dell'applicazione è basso.

Configura un gestore della scalabilità automatica pianificato

  1. In Cloud Shell, installa l'adattatore per metriche personalizzate - Cloud Monitoring nel tuo cluster GKE:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter_new_resource_model.yaml
kubectl wait --for=condition=available --timeout=600s deployment/custom-metrics-stackdriver-adapter -n custom-metrics

    Questo adattatore consente la scalabilità automatica dei pod in base a metriche personalizzate di Cloud Monitoring.

  2. Crea un repository in Artifact Registry e concedi le autorizzazioni di lettura:

    gcloud artifacts repositories create gke-scheduled-autoscaler \
  --repository-format=docker --location=us-central1
gcloud auth configure-docker us-central1-docker.pkg.dev
gcloud artifacts repositories add-iam-policy-binding gke-scheduled-autoscaler \
   --location=us-central1 --member=allUsers --role=roles/artifactregistry.reader

  3. Crea ed esegui il push del codice dell'esportatore metrica personalizzata:

    docker build -t us-central1-docker.pkg.dev/$PROJECT_ID/gke-scheduled-autoscaler/custom-metric-exporter .
docker push us-central1-docker.pkg.dev/$PROJECT_ID/gke-scheduled-autoscaler/custom-metric-exporter

  4. Esegui il deployment dei CronJob che esportano metriche personalizzate ed esegue il deployment della versione aggiornata dell'HPA che legge da queste metriche personalizzate:

    sed -i.bak s/PROJECT_ID/$PROJECT_ID/g ./k8s/scheduled-autoscaler/scheduled-autoscale-example.yaml
kubectl apply -f ./k8s/scheduled-autoscaler

  5. Apri ed esamina il file k8s/scheduled-autoscaler/scheduled-autoscale-example.yaml.

    Nell'elenco che segue vengono mostrati i contenuti del file.

    apiVersion: batch/v1
kind: CronJob
metadata:
  name: scale-up
spec:
  schedule: "50-59/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: custom-metric-extporter
            image: us-central1-docker.pkg.dev/PROJECT_ID/gke-scheduled-autoscaler/custom-metric-exporter
            command:
              - /export
              - --name=scheduled_autoscaler_example
              - --value=10
          restartPolicy: OnFailure
      backoffLimit: 1
---
apiVersion: batch/v1
kind: CronJob
metadata:
  name: scale-down
spec:
  schedule: "1-49/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: custom-metric-extporter
            image: us-central1-docker.pkg.dev/PROJECT_ID/gke-scheduled-autoscaler/custom-metric-exporter
            command:
              - /export
              - --name=scheduled_autoscaler_example
              - --value=1
          restartPolicy: OnFailure
      backoffLimit: 1

    Questa configurazione specifica che i CronJob devono esportare il numero delle repliche dei pod suggerite in una metrica personalizzata denominata custom.googleapis.com/scheduled_autoscaler_example in base all'ora del giorno. Per facilitare la sezione di monitoraggio di questo tutorial, la configurazione del campo di pianificazione definisce scale-up e scale down orari. Per la produzione, puoi personalizzare questa pianificazione in base alle tue esigenze aziendali.

  6. Apri ed esamina il file k8s/scheduled-autoscaler/hpa-example.yaml.

    Nell'elenco seguente sono riportati i contenuti del file.

    spec:
  maxReplicas: 20
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  - type: External
    external:
      metric:
        name: custom.googleapis.com|scheduled_autoscaler_example
      target:
          type: AverageValue
          averageValue: 1

    Questa configurazione specifica che l'oggetto HPA deve sostituire l'oggetto HPA di cui è stato eseguito il deployment in precedenza. Nota che la configurazione riduce il valore in minReplicas a 1. Ciò significa che è possibile fare lo scale down del carico di lavoro fino al minimo. La configurazione aggiunge anche una metrica esterna (type: External). Questa aggiunta significa che la scalabilità automatica ora è attivata da due fattori.

    In questo scenario con più metriche, l'HPA calcola un conteggio di repliche proposto per ogni metrica, poi sceglie la metrica che restituisce il valore più alto. È importante capire questo aspetto: il gestore della scalabilità automatica pianificato può proporre che in un determinato momento il numero di pod sia 1. Tuttavia, se l'utilizzo effettivo della CPU è superiore al previsto per un pod, l'HPA crea più repliche.

  7. Controlla di nuovo il numero di nodi e di repliche HPA eseguendo di nuovo ciascuno di questi comandi:

    kubectl get nodes
kubectl get hpa php-apache

    L'output visualizzato dipende dalle operazioni eseguite di recente dal gestore della scalabilità automatica pianificato. In particolare, i valori di minReplicas e nodes saranno diversi in base ai diversi punti del ciclo di scalabilità.

    Ad esempio, circa i minuti da 51 a 60 di ogni ora (che rappresentano un periodo di traffico di picco), il valore HPA per minReplicas sarà 10, mentre il valore di nodes sarà 4.

    Al contrario, per i minuti da 1 a 50 (che rappresenta un periodo di traffico più basso), il valore minReplicas HPA sarà 1 e il valore nodes sarà 1 o 2, a seconda del numero di pod allocati e rimossi. Per i valori più bassi (minuti da 1 a 50), potrebbero essere necessari fino a 10 minuti prima che lo scale down del cluster venga completato.

Configura avvisi per i casi in cui il gestore della scalabilità automatica pianificato non funziona correttamente

In un ambiente di produzione, in genere è consigliabile sapere quando i CronJob non compilano la metrica personalizzata. A questo scopo, puoi creare un avviso che si attivi quando uno stream custom.googleapis.com/scheduled_autoscaler_example è assente per un periodo di cinque minuti.

  1. In Cloud Shell, crea un canale di notifica:

    gcloud beta monitoring channels create \
    --display-name="Scheduled Autoscaler team (Primary)" \
    --description="Primary contact method for the Scheduled Autoscaler team lead"  \
    --type=email \
    --channel-labels=email_address=${ALERT_EMAIL}

    L'output è simile al seguente:

    Created notification channel NOTIFICATION_CHANNEL_ID.

    Questo comando crea un canale di notifica di tipo email per semplificare i passaggi del tutorial. Negli ambienti di produzione, ti consigliamo di adottare una strategia meno asincrona impostando il canale di notifica su sms o pagerduty.

  2. Imposta una variabile con il valore visualizzato nel segnaposto NOTIFICATION_CHANNEL_ID:

    NOTIFICATION_CHANNEL_ID=NOTIFICATION_CHANNEL_ID

  3. Esegui il deployment del criterio di avviso:

    gcloud alpha monitoring policies create \
    --policy-from-file=./monitoring/alert-policy.yaml \
    --notification-channels=$NOTIFICATION_CHANNEL_ID

    Il file alert-policy.yaml contiene la specifica per l'invio di un avviso se la metrica non è presente dopo cinque minuti.

  4. Vai alla pagina Avvisi di Cloud Monitoring per visualizzare il criterio di avviso.

    Vai ad Avvisi

  5. Fai clic su Criterio del gestore della scalabilità automatica pianificato e verifica i dettagli del criterio di avviso.

Genera carico nell'applicazione di esempio

  • In Cloud Shell, esegui il deployment del generatore di carico:

    kubectl apply -f ./k8s/load-generator

    Nell'elenco seguente viene mostrato lo script load-generator:

    command: ["/bin/sh", "-c"]
args:
- while true; do
    RESP=$(wget -q -O- http://php-apache.default.svc.cluster.local);
    echo "$(date +%H)=$RESP";
    sleep $(date +%H | awk '{ print "s("$0"/3*a(1))*0.5+0.5" }' | bc -l);
  done;

    Questo script viene eseguito nel cluster finché non elimini il deployment di load-generator. Invia richieste al tuo servizio php-apache a intervalli di pochi millisecondi. Il comando sleep simula le modifiche alla distribuzione del carico durante la giornata. Utilizzando uno script che genera traffico in questo modo, puoi capire cosa succede quando combini l'utilizzo della CPU e le metriche personalizzate nella configurazione HPA.

Visualizza la scalabilità in risposta al traffico o alle metriche pianificate

In questa sezione esaminerai le visualizzazioni che mostrano gli effetti dell'aumento e dello scale down.

  1. In Cloud Shell, crea una nuova dashboard:

    gcloud monitoring dashboards create \
    --config-from-file=./monitoring/dashboard.yaml

  2. Vai alla pagina Dashboard di Cloud Monitoring:

    Vai a Dashboard

  3. Fai clic su Dashboard del gestore della scalabilità automatica pianificata.

    Nella dashboard vengono visualizzati tre grafici. Devi attendere almeno 2 ore (preferibilmente 24 ore o più) per vedere le dinamiche degli scale up e dello scale down e per vedere in che modo la diversa distribuzione del carico durante la giornata influisce sulla scalabilità automatica.

    Per avere un'idea di ciò che mostrano i grafici, puoi studiare i seguenti grafici, che presentano una visione dell'intera giornata:

    • Metrica pianificata (numero di pod desiderato) mostra una serie temporale della metrica personalizzata esportata in Cloud Monitoring tramite i CronJob configurati in Configurare un gestore della scalabilità automatica pianificato.

      Grafico della domanda di pod, che mostra un picco ogni ora.

    • La colonna Utilizzo CPU (richiesta e utilizzo) mostra una serie temporale di utilizzo della CPU richiesta (rosso) e dell'utilizzo effettivo della CPU (blu). Quando il carico è basso, l'HPA rispetta la decisione di utilizzo da parte del gestore della scalabilità automatica pianificato. Tuttavia, quando il traffico aumenta, l'HPA aumenta il numero di pod in base alle esigenze, come puoi vedere per i punti dati tra le 12:00 e le 18:00.

      Grafico dell'utilizzo della CPU, che mostra la crescita della domanda durante il giorno fino alle 16:00 per poi diminuire.

    • Numero di pod (pianificati ed effettivi) + Utilizzo medio della CPU mostra una visualizzazione simile a quelle precedenti. Il numero di pod (rosso) aumenta a 10 ogni ora come pianificato (in blu). Il numero dei pod aumenta e diminuisce naturalmente nel tempo in risposta al carico (12:00 e 18:00). L'utilizzo medio della CPU (arancione) rimane al di sotto del target impostato (60%).

      2 grafici. Uno mostra la domanda di pod con picchi di domanda ogni ora. L'altra mostra che l'utilizzo della CPU aumenta o diminuisce, ma si aggiunge al valore elevato configurato.

Esegui la pulizia

Per evitare che al tuo Account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Elimina il progetto

  1. Nella console Google Cloud, vai alla pagina Gestisci risorse.

    Vai a Gestisci risorse

  2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
  3. Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Passaggi successivi