Questo tutorial spiega come ridurre i costi dimezzando un programmato autoscaler su Google Kubernetes Engine (GKE). Questo tipo di gestore della scalabilità automatica aumenta o diminuisce il numero di cluster in base a una pianificazione basata sull'ora del giorno o sul giorno della settimana. Un'automazione della scalabilità pianificata è utile se il tuo traffico presenta picchi e cali prevedibili, ad esempio se sei un rivenditore regionale o se il tuo software è destinato a dipendenti le cui ore di lavoro sono limitate a una parte specifica del giorno.
Il tutorial è rivolto a sviluppatori e operatori che vogliono aumentare in modo affidabile il numero di cluster prima dell'arrivo dei picchi e ridurlo di nuovo per risparmiare di notte, nei fine settimana o in qualsiasi altro momento in cui sono online meno utenti. L'articolo presuppone che tu abbia dimestichezza con Docker, Kubernetes, Kubernetes CronJobs, GKE e Linux.
Introduzione
Molte applicazioni presentano pattern di traffico non uniformi. Ad esempio, i lavoratori di un'organizzazione potrebbero interagire con un'applicazione solo durante il giorno. Di conseguenza, i server del data center per l'applicazione rimangono inattivi di notte.
Oltre ad altri vantaggi, Google Cloud può aiutarti a risparmiare allocando dinamicamente l'infrastruttura in base al carico del traffico. In alcuni casi, una semplice configurazione di scalabilità automatica può gestire il problema di allocazione del traffico non uniforme. In questo caso, non cambiare. Tuttavia, in altri casi, variazioni improvvise dei pattern di traffico richiedono configurazioni di scalabilità automatica più precise per evitare l'instabilità del sistema durante gli scale up e l'overprovisioning del cluster.
Questo tutorial si concentra su scenari in cui le variazioni improvvise dei pattern di traffico sono ben comprese e vuoi fornire suggerimenti al gestore della scalabilità automatica che la tua infrastruttura sta per registrare picchi. Questo documento mostra come eseguire il ridimensionamento dei cluster GKE al mattino e di notte, ma puoi utilizzare un approccio simile per aumentare e diminuire la capacità per qualsiasi evento noto, ad esempio eventi di picco, campagne pubblicitarie, traffico del fine settimana e così via.
Ridurre le dimensioni di un cluster se hai sconti per impegno di utilizzo
Questo tutorial spiega come ridurre i costi riducendo al minimo i cluster GKE durante le ore di punta. Tuttavia, se hai acquistato un sconto per utilizzo vincolato, è importante capire come funzionano questi sconti in combinazione con l'autoscaling.
I contratti basati sull'impegno di utilizzo ti offrono prezzi molto scontati quando ti impegni a pagare per una quantità definita di risorse (vCPU, memoria e altre). Tuttavia, per determinare la quantità di risorse da impegnare, devi sapere in anticipo quante risorse vengono utilizzate dai tuoi carichi di lavoro nel tempo. Per aiutarti a ridurre i costi, nel seguente diagramma sono illustrate le risorse da includere e da non includere nella pianificazione.
Come mostrato nel diagramma, l'allocazione delle risorse in base a un contratto di utilizzo a termine è uniforme. Le risorse coperte dal contratto devono essere in uso per la maggior parte del tempo per essere degne dell'impegno che hai preso. Pertanto, non devi includere le risorse utilizzate durante i picchi nel calcolo delle risorse impegnate. Per le risorse con picchi, ti consigliamo di utilizzare le opzioni di scalabilità automatica di GKE. Queste opzioni includono l'autoscalabilità pianificata descritta in questo documento 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 di utilizzo a livello di impegno per una determinata quantità di risorse, non riduci i costi riducendo il cluster al di sotto del livello minimo. In questi scenari, ti consigliamo di provare a pianificare alcuni job per colmare le lacune durante i periodi di bassa domanda di calcolo.
Architettura
Il seguente diagramma mostra l'architettura per l'infrastruttura e il gestore della scalabilità automatica pianificato di cui esegui il deployment in questo tutorial. Il gestore della scalabilità automatica programmata è costituito da un insieme di componenti che collaborano per gestire la scalabilità in base a una programmazione.
In questa architettura, un insieme di CronJobs Kubernetes esporta le informazioni note sui pattern di traffico in una metrica personalizzata di Cloud Monitoring. Questi dati vengono poi letti da un gestitore della scalabilità automatica dei pod orizzontali (HPA) di Kubernetes come input per stabilire quando l'HPA deve scalare il tuo carico di lavoro. Insieme ad altre metriche di carico, come l'utilizzo della CPU target, 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'HPA Kubernetes.
- Configura i componenti per il gestore della scalabilità automatica pianificata e aggiorna l'HPA in modo che legga da una metrica personalizzata pianificata.
- Configura un avviso da attivare quando l'autoscalatore pianificato non funziona correttamente.
- Generare carico per l'applicazione.
- Esamina come l'HPA risponde ai normali aumenti del traffico e alle metriche personalizzate pianificate che configuri.
Il codice di questo tutorial si trova in un repository GitHub.
Costi
In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:
Per generare una stima dei costi basata sull'utilizzo previsto,
utilizza il Calcolatore prezzi.
Prima di iniziare
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the GKE, Artifact Registry and the Cloud Monitoring APIs.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the GKE, Artifact Registry and the Cloud Monitoring APIs.
prepara l'ambiente
In the Google Cloud console, 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.
In Cloud Shell, configura l'ID progetto Google Cloud, il tuo indirizzo email, 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 per ricevere una notifica quando l'autoscalatore pianificato non funziona correttamente.
Se vuoi, puoi scegliere una regione e una zona diverse per questo tutorial.
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 dai CronJob 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 dell'HPA da leggere 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 configurerai in questo tutorial.
Crea il cluster GKE
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
Non si tratta di una configurazione di produzione, ma è una configurazione adatta per 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. Attiva anche il profilo
optimize-utilization
per velocizzare il processo di riduzione.
Esegui il deployment dell'applicazione di esempio
Esegui il deployment dell'applicazione di esempio senza il gestore della scalabilità automatica pianificato:
kubectl apply -f ./k8s
Apri il file
k8s/hpa-example.yaml
.La seguente voce mostra i contenuti del file.
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 (impostazioniname: cpu
etype: Utilization
).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!
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
mostra10
, che corrisponde al valore delminReplicas
campo nel filehpa-example.yaml
.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 più infrastruttura perchéminReplicas
nel filehpa-example.yaml
è impostato su 10.L'impostazione di
minReplicas
su un valore come 10 è una strategia comune utilizzata da aziende come i rivenditori, che si aspettano un aumento improvviso del traffico nelle prime ore del giorno lavorativo. Tuttavia, l'impostazione di valori elevati perminReplicas
HPA può aumentare i costi perché il cluster non può ridursi, nemmeno di notte quando il traffico delle applicazioni è ridotto.
Configurare un gestore della scalabilità automatica pianificato
In Cloud Shell, installa l'adattatore Custom Metrics - 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 alle metriche personalizzate di Cloud Monitoring.
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
Compila e carica 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
Esegui il deployment dei CronJob che esportano le metriche personalizzate e la versione aggiornata dell'HPA che le legge:
sed -i.bak s/PROJECT_ID/$PROJECT_ID/g ./k8s/scheduled-autoscaler/scheduled-autoscale-example.yaml kubectl apply -f ./k8s/scheduled-autoscaler
Apri ed esamina il file
k8s/scheduled-autoscaler/scheduled-autoscale-example.yaml
.La seguente voce mostra i contenuti del file.
Questa configurazione specifica che i CronJob devono esportare il conto delle repliche del pod suggerite in una metrica personalizzata denominata
custom.googleapis.com/scheduled_autoscaler_example
in base all'ora del giorno. Per semplificare la sezione di monitoraggio di questo tutorial, la configurazione del campo pianificazione definisce i ridimensionamenti orari. Per la produzione, puoi personalizzare questa pianificazione in base alle esigenze della tua attività.Apri ed esamina il file
k8s/scheduled-autoscaler/hpa-example.yaml
.La seguente voce mostra i contenuti del file.
Questa configurazione specifica che l'oggetto HPA deve sostituire l'HPA implementato 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 ora la scalabilità automatica viene attivata da due fattori.In questo scenario con più metriche, l'HPA calcola un conteggio di repliche proposto per ogni metrica e poi sceglie la metrica che restituisce il valore più alto. È importante capire che il ridimensionamento automatico pianificato può proporre che in un determinato momento il numero di pod debba essere 1. Tuttavia, se l'utilizzo effettivo della CPU è superiore a quello previsto per un pod, l'HPA crea più repliche.
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 da ciò che ha fatto di recente il gestore della scalabilità automatica. In particolare, i valori di
minReplicas
enodes
saranno diversi in punti diversi del ciclo di ridimensionamento.Ad esempio, approssimativamente tra i minuti 51 e 60 di ogni ora (che rappresenta un periodo di picco del traffico), il valore HPA per
minReplicas
sarà 10 e il valore dinodes
sarà 4.Al contrario, per i minuti da 1 a 50 (che rappresentano un periodo di traffico inferiore), il valore
minReplicas
dell'HPA sarà 1 e il valorenodes
sarà 1 o 2, a seconda del numero di pod allocati e rimossi. Per i valori più bassi (da 1 a 50 minuti), il completamento dello scaling down del cluster potrebbe richiedere fino a 10 minuti.
Configurare gli avvisi per quando il gestore della scalabilità automatica pianificata non funziona correttamente
In un ambiente di produzione, in genere è utile sapere quando i CronJob non compilano la metrica personalizzata. A questo scopo, puoi creare un avviso che si attiva quando uno stream custom.googleapis.com/scheduled_autoscaler_example
è assente per un periodo di cinque minuti.
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, consigliamo di utilizzare una strategia meno asincrona impostando il canale di notifica susms
opagerduty
.Imposta una variabile con il valore visualizzato nel segnaposto
NOTIFICATION_CHANNEL_ID
:NOTIFICATION_CHANNEL_ID=NOTIFICATION_CHANNEL_ID
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 non è presente dopo cinque minuti.Vai alla pagina Avvisi di Cloud Monitoring per visualizzare il criterio di avviso.
Fai clic su Criterio di scalabilità automatica pianificata e verifica i dettagli del criterio di avviso.
Generare un carico nell'applicazione di esempio
In Cloud Shell, esegui il deployment del generatore di carico:
kubectl apply -f ./k8s/load-generator
La seguente voce 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
load-generator
. Invia richieste al tuo serviziophp-apache
ogni pochi millisecondi. Il comandosleep
simula le variazioni della 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 dell'HPA.
Visualizzare la scalabilità in risposta al traffico o alle metriche pianificate
In questa sezione, esamini le visualizzazioni che mostrano gli effetti dell'aumento e della riduzione della scalabilità.
In Cloud Shell, crea una nuova dashboard:
gcloud monitoring dashboards create \ --config-from-file=./monitoring/dashboard.yaml
Vai alla pagina Dashboard di Cloud Monitoring:
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 scaling up e scaling down e per capire in che modo la diversa distribuzione del carico durante la giornata 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 di pod desiderato) mostra una serie temporale della metrica personalizzata che viene esportata in Cloud Monitoring tramite i CronJob che hai configurato in Configurazione di un ridimensionamento automatico pianificato.
Utilizzo CPU (richiesto e utilizzato) mostra una serie temporale della CPU richiesta (rossa) e dell'utilizzo effettivo della CPU (blu). Quando il carico è basso, l'HPA rispetta la decisione di utilizzo presa dal 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 (pianificato e effettivo) + Utilizzo medio della CPU mostra una visualizzazione simile alle precedenti. Il conteggio dei pod (rosso) aumenta a 10 ogni ora come pianificato (blu). Il numero di 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%).
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
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Passaggi successivi
- Scopri di più sull'ottimizzazione dei costi di GKE in Best practice per l'esecuzione di applicazioni Kubernetes con ottimizzazione dei costi su GKE.
- Trova suggerimenti di progettazione e best practice per ottimizzare i costi dei carichi di lavoro Google Cloud in Framework dell'architettura di Google Cloud: ottimizzazione dei costi.
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.