Riduzione dei costi grazie allo scale down dei cluster GKE al di fuori delle ore di punta

Last reviewed 2022-11-24 UTC

Questo tutorial spiega come ridurre i costi eseguendo il deployment di una gestore della scalabilità automatica su Google Kubernetes Engine (GKE). Questo tipo di gestore della scalabilità automatica i cluster in alto o in basso in base a una pianificazione basata sull'ora del giorno o sul giorno settimana. Un gestore della scalabilità automatica pianificato è utile se il tuo traffico presenta variazioni prevedibili ad esempio se sei un rivenditore regionale o se il tuo software è 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 in modo affidabile prima che arrivino i picchi, e ridimensionarli di nuovo per risparmiare denaro di notte, nei fine settimana o in qualsiasi altro momento in cui ci sono meno utenti online. L'articolo presuppone che hai familiarità con Docker, Kubernetes, Kubernetes CronJob, GKE e Linux.

Introduzione

Molte applicazioni presentano pattern di traffico non uniformi. Ad esempio, i lavoratori in un'organizzazione potrebbe utilizzare un'applicazione solo durante il giorno. Come come risultato, i server dei data center per quell'applicazione sono inattivi di notte.

Oltre ad altri vantaggi, Google Cloud può aiutarti a risparmiare denaro tramite per l'allocazione dell'infrastruttura in base al carico del traffico. In alcuni casi, una semplice a scalabilità automatica può gestire la sfida di allocazione del traffico non uniforme. Se è il tuo caso, continua così. Tuttavia, in altri casi, si verificano drastiche variazioni modelli di traffico richiedono configurazioni di scalabilità automatica più precise per evitare instabilità del sistema durante gli scale up ed evitare il provisioning eccessivo del cluster.

Questo tutorial è incentrato sugli scenari in cui vengono apportate modifiche significative ai modelli di traffico ben compreso e vuoi fornire suggerimenti al gestore della scalabilità automatica dell'infrastruttura stanno per subire dei picchi. Questo documento mostra come scalare i cluster GKE si alzano di mattina e restano inattivi di notte, utilizzare un approccio simile per aumentare e diminuire la capacità per qualsiasi ad esempio eventi di picco, campagne pubblicitarie, traffico nel fine settimana e così via.

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

Questo tutorial spiega come ridurre i costi facendo lo scale down i cluster GKE al minimo al di fuori delle ore di punta. Tuttavia, se hai acquistato un sconto per impegno di utilizzo, è importante capire come questi sconti funzionino in combinazione con e la scalabilità automatica.

I contratti basati su impegno di utilizzo ti offrono prezzi fortemente scontati se ti impegni a pagando per una quantità prestabilita di risorse (vCPU, memoria e altro). Tuttavia, per a determinare la quantità di risorse da impegnare, devi sapere in anticipo molte risorse utilizzate dai carichi di lavoro nel tempo. Per aiutarti a ridurre i costi, il seguente diagramma illustra le risorse che dovresti o meno includere nella pianificazione.

Distribuzione delle risorse, con una base di risorse impegnate sempre allocate e risorse che vengono scalate automaticamente in risposta alla domanda (picchi).

Come mostra il diagramma, l'allocazione delle risorse in base a un contratto per impegno di utilizzo è piatta. Per essere implementate, le risorse coperte dal contratto devono essere in uso nella maggior parte dei casi dell'impegno assunto. Pertanto, non devi includere risorse utilizzate durante i picchi di calcolo delle risorse impegnate. Per punte consigliamo di usare il gestore della scalabilità automatica di GKE le opzioni di CPU e memoria disponibili. Queste opzioni includono il gestore della scalabilità automatica pianificato illustrato o altre opzioni gestite illustrate 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 riduci i costi facendo lo scale down del cluster al di sotto di questo valore minimo. Nel scenari di questo tipo, ti consigliamo di provare a pianificare alcuni job per colmare durante i periodi di scarsa domanda di computing.

Architettura

Il seguente diagramma mostra l'architettura per l'infrastruttura e pianificato del gestore della scalabilità automatica di cui eseguirai 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 programmazione.

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

In questa architettura, è stato creato un insieme CronJobs esportare informazioni note sui modelli di traffico in un Metrica personalizzata di Cloud Monitoring. Questi dati vengono poi letti da un cluster Kubernetes HPA (Horizontal Pod Autoscaler) come input per capire quando l'HPA deve scalare il carico di lavoro. Insieme ad altri come l'utilizzo target della CPU, l'HPA decide come scalare le repliche per un determinato deployment.

Obiettivi

  • Creare un cluster GKE.
  • Esegui il deployment di un'applicazione di esempio che utilizza un cluster Kubernetes HPA.
  • Configura i componenti per il gestore della scalabilità automatica pianificato e aggiorna l'HPA per leggere da una metrica personalizzata pianificata.
  • Configura un avviso da attivare quando l'Austoscaler pianificato non funzionando correttamente.
  • Generare il carico sull'applicazione.
  • Esaminare come l'HPA risponde ai normali aumenti del traffico e alla metriche personalizzate pianificate da te configurate.

Il codice per questo tutorial è in un repository GitHub.

Costi

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

Per generare una stima dei costi basata sull'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

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. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  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. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  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. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. In Cloud Shell, configura l'ID progetto Google Cloud, nonché la zona e la regione di computing:

    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 per progetto che stai utilizzando.
    • YOUR_EMAIL_ADDRESS: un indirizzo email per ricevere notifiche se il gestore della scalabilità automatica pianificato non funziona correttamente.

    Puoi scegliere una regione e una zona diverse per questo tutorial, se vuoi.

  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 in questo esempio è strutturato nelle seguenti cartelle:

    • Radice: contiene il codice utilizzato dai CronJob per esportare le metriche a Cloud Monitoring.
    • k8s/: contiene un esempio di deployment che include un HPA Kubernetes.
    • k8s/scheduled-autoscaler/: contiene i CronJob che esportano un file personalizzato e una versione aggiornata dell'HPA per leggere da una metrica personalizzata.
    • k8s/load-generator/: contiene un deployment Kubernetes con per simulare l'utilizzo orario.
    • monitoring/: contiene i componenti di Cloud Monitoring che hai configurare in questo tutorial.

crea il cluster GKE

  1. In Cloud Shell, crea un cluster GKE eseguendo 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

    Non è una configurazione di produzione, ma una configurazione adatte a questo tutorial. In questa configurazione, configuri gestore della scalabilità automatica dei cluster con un minimo di 1 nodo e un massimo di 10 nodi. Puoi anche attivare optimize-utilization del profilo per velocizzare 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

    Tieni presente 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 sia 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 dell'attributo minReplicas nel file hpa-example.yaml.

  5. Controlla se il numero di nodi è salito 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 min-nodes=1 flag. Tuttavia, l'applicazione di cui hai eseguito il deployment all'inizio di questa procedura richiede più infrastruttura Il valore di minReplicas nel file hpa-example.yaml è impostato su 10.

    L'impostazione di minReplicas su un valore simile a 10 è una strategia comune usata aziende come i retailer, che si aspettano un improvviso aumento del traffico nei nelle prime ore della giornata lavorativa. Tuttavia, l'impostazione di valori elevati per HPA minReplicas può aumentare i costi perché il cluster non può essere ridotto, nemmeno di notte quando il traffico delle applicazioni è ridotto.

Configura un gestore della scalabilità automatica pianificato

  1. In Cloud Shell, installa Metriche personalizzate - Scheda 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 abilita la scalabilità automatica dei pod in base alla configurazione personalizzata di Cloud Monitoring metriche di valutazione.

  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 di esportazione 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 le metriche personalizzate ed eseguono il deployment dell'HPA che legge dalle seguenti 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 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 conteggio delle repliche dei pod suggeriti in base a una metrica personalizzata custom.googleapis.com/scheduled_autoscaler_example in base all'ora giorno. Per facilitare la sezione dedicata al monitoraggio di questo tutorial, la configurazione dei campi di pianificazione definisce scale up e scale down orari. Per produzione, puoi personalizzare questa pianificazione in base alle tue esigenze aziendali.

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

    Il seguente elenco mostra 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'HPA di cui è stato eseguito il deployment in precedenza. Nota che la configurazione riduce il valore tra minReplicas e 1. Ciò significa che è possibile fare lo scale down del carico di lavoro minimo. La configurazione aggiunge anche metrica esterna (type: External). Questa aggiunta significa che ora viene attivata la scalabilità automatica da due fattori.

    In questo scenario con più metriche, l'HPA calcola una replica proposta conta per ogni metrica, poi sceglie la metrica che restituisce il valore valore. È importante capirlo: il gestore della scalabilità automatica pianificato può propone che in un dato momento il conteggio dei pod debba essere 1. Ma se l'effettiva l'utilizzo della CPU è più alto del previsto per un pod, l'HPA crea o lo scale out mediante repliche di lettura.

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

    kubectl get nodes
kubectl get hpa php-apache

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

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

    Al contrario, per i minuti da 1 a 50 (che rappresenta un periodo di tempo del traffico), il valore HPA minReplicas sarà 1 e il valore nodes 1 o 2, a seconda di quanti pod sono stati allocati. rimosso. Per i valori più bassi (minuti da 1 a 50), potrebbero essere necessari fino a 10 minuti per completare lo scale down del cluster.

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

In un ambiente di produzione, di solito è utile sapere quando i CronJob non compilare la metrica personalizzata. A questo scopo, puoi creare un avviso si attiva quando uno stream custom.googleapis.com/scheduled_autoscaler_example viene in assenza 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'istanza canale di notifica di tipo email per semplificare i passaggi del tutorial. Negli ambienti di produzione, ti consigliamo di utilizzare una strategia meno asincrona impostando il valore canale di notifica a sms o pagerduty.

  2. Imposta una variabile con il valore visualizzato nella 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 inviare un avviso se la metrica è assente 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 pianificata e verifica i dettagli del criterio di avviso.

Genera carico per l'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 load-generator e deployment continuo. Invia richieste al servizio php-apache a intervalli di alcune millisecondi. Il comando sleep simula le modifiche della distribuzione del carico durante il giorno. Utilizzando uno script che genera traffico in questo modo, può capire cosa succede quando combini l'utilizzo della CPU e della tua configurazione HPA.

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

In questa sezione esaminerai le visualizzazioni che mostrano gli effetti delle lo scale up e lo 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:

    Accedi a Dashboard

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

    Nella dashboard sono visualizzati tre grafici. Devi attendere almeno 2 ore (idealmente, 24 ore o più) per vedere le dinamiche delle scale up e scale down e vedere la diversa distribuzione del carico durante il giorno influisce sulla scalabilità automatica.

    Per darti un'idea di cosa mostrano i grafici, puoi studiare quanto segue: che offrono una vista di un'intera giornata:

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

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

    • Utilizzo della CPU (richiesto o utilizzato) mostra una serie temporale di CPU richiesta (rosso) e utilizzo effettivo della CPU (blu). Quando il carico viene basso, l'HPA rispetta la decisione di utilizzo del gestore della scalabilità automatica pianificato. Tuttavia, quando il traffico aumenta, l'HPA aumenta il numero di pod, come mostrato 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 rispetto a quelli effettivi) + Utilizzo medio della CPU mostra un valore visualizzazione simile ai precedenti. Il numero di pod (rosso) aumenta a 10 ogni ora come da programma (blu). Il conteggio dei pod aumenta naturalmente diminuisce nel tempo in risposta al carico (12:00 e 18:00). CPU media (arancione) rimane al di sotto del target impostato (60%).

      2 grafici. Uno mostra la domanda di pod con un picco ogni ora. L'altro mostra che l'utilizzo della CPU aumenta e diminuisce, ma si completa 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