Riduzione dei costi riducendo i cluster GKE durante le ore di punta

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 , il tuo indirizzo email e la zona e la regione di calcolo:

   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 il progetto che stai utilizzando.
   • YOUR_EMAIL_ADDRESS: un indirizzo email a cui inviare notifiche quando il gestore della scalabilità automatica pianificata non funziona correttamente.

   Se vuoi, puoi scegliere un'altra regione e zona per questo tutorial.

3. Clona il repository GitHub 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:

   • Root: contiene il codice utilizzato da CronJobs per esportare le metriche personalizzate in Cloud Monitoring.
   • k8s/: contiene un esempio di deployment con un HPA Kubernetes.
   • k8s/scheduled-autoscaler/: contiene i CronJob che esportano una metrica personalizzata e una versione aggiornata di HPA per leggere da una metrica personalizzata.
   • k8s/load-generator/: contiene un deployment Kubernetes con un'applicazione per simulare l'utilizzo orario. Un deployment è un oggetto API Kubernetes che consente di eseguire più repliche di pod distribuite tra i nodi di un cluster.
   • 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 lo scalatore automatico 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 si tratta di una configurazione di produzione, ma di una configurazione adatta a questo tutorial. In questa configurazione, configuri il gestore della scalabilità automatica del cluster con un minimo di 1 nodo e un massimo di 10 nodi. Puoi anche attivare il profilo optimize-utilization per velocizzare il processo di riduzione.

Esegui il deployment dell'applicazione di esempio

1. Esegui il deployment dell'applicazione di esempio senza lo strumento di scalabilità automatica pianificata:

   kubectl apply -f ./k8s
   

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

   Il seguente elenco mostra 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 che hai deployment all'inizio di questa procedura richiede più infrastruttura perché minReplicas nel file hpa-example.yaml è impostato su 10.

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

Configurare un gestore della scalabilità automatica pianificata

1. In Cloud Shell, installa l'adattatore delle 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 alle 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 e invia il codice dell'esportatore di 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 e della versione aggiornata dell'HPA che legge 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.

   Il seguente elenco mostra 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 suggerito in una metrica personalizzata chiamata 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 della pianificazione definisce gli aumenti e le riduzioni orari. Per la produzione, puoi personalizzare questa pianificazione in base alle esigenze della tua attività.

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 che è stato deployment in precedenza. Tieni presente che la configurazione riduce il valore in minReplicas a 1. Ciò significa che il carico di lavoro può essere ridotto al minimo. La configurazione aggiunge anche una metrica esterna (type: External). Questa aggiunta significa che la scalabilità automatica ora viene attivata da due fattori.

   In questo scenario con più metriche, HPA calcola un numero di repliche proposto per ogni metrica e poi sceglie la metrica che restituisce il valore più alto. È importante capire che lo scalatore automatico pianificato può proporre che in un determinato momento il conteggio dei 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 repliche HPA eseguendo di nuovo ciascuno di questi comandi:

   kubectl get nodes
   kubectl get hpa php-apache
   

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

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

   Al contrario, per i minuti da 1 a 50 (che rappresentano un periodo di traffico inferiore), il valore di HPA minReplicas sarà 1 e il valore di nodes sarà 1 o 2, a seconda di quanti pod sono stati allocati e rimossi. Per i valori inferiori (da 1 a 50 minuti), potrebbero essere necessari fino a 10 minuti prima che il cluster completi la riduzione.

Configura avvisi per quando il gestore della scalabilità automatica pianificata non funziona correttamente

In un ambiente di produzione, in genere vuoi sapere quando i CronJob non compilano la metrica personalizzata. A questo scopo, puoi creare un avviso che si attiva quando qualsiasi 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 utilizzare 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 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 Norme di scalabilità automatica pianificata e verifica i dettagli delle norme 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
  

  Il seguente elenco mostra 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. Effettua richieste al tuo servizio php-apache ogni pochi millisecondi. Il comando sleep simula le modifiche alla distribuzione del carico durante il giorno. 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.

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

In questa sezione, esamini le visualizzazioni che mostrano gli effetti dello scale up 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:

   Accedi a Dashboard

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

   La dashboard mostra tre grafici. Devi attendere almeno 2 ore (idealmente, 24 ore o più) per vedere le dinamiche di scalabilità e ridimensionamento e per vedere in che modo la diversa distribuzione del carico durante il giorno influisce sulla scalabilità automatica.

   Per farti un'idea di cosa mostrano i grafici, puoi studiare i seguenti grafici, che presentano una visualizzazione di un'intera giornata:

   • Metrica pianificata (numero desiderato di pod) mostra una serie temporale della metrica personalizzata esportata in Cloud Monitoring tramite i CronJob che hai configurato in Configurazione di uno scalatore automatico pianificato.

     

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

     

   • Numero di pod (pianificati vs effettivi) + Utilizzo medio della CPU mostra una visualizzazione simile a quelle precedenti. Il conteggio dei pod (rosso) aumenta a 10 ogni ora come pianificato (blu). Il conteggio 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 che hai impostato (60%).