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.
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.
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, utilizzi i seguenti componenti fatturabili di Google Cloud:
Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi.
Prima di iniziare
- 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.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
-
Abilita le API GKE, Artifact Registry and the Cloud Monitoring.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
-
Abilita le API GKE, Artifact Registry and the Cloud Monitoring.
prepara l'ambiente
Nella console Google Cloud, 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.
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.
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
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
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
.Nell'elenco che segue vengono mostrati i contenuti del file.
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 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 del campominReplicas
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 una maggiore infrastruttura perché il valoreminReplicas
nel filehpa-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'attributominReplicas
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
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.
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
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
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
Apri ed esamina il file
k8s/scheduled-autoscaler/scheduled-autoscale-example.yaml
.Nell'elenco che segue vengono mostrati i contenuti del file.
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.Apri ed esamina il file
k8s/scheduled-autoscaler/hpa-example.yaml
.Nell'elenco seguente sono riportati i contenuti del file.
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.
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
enodes
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 dinodes
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 valorenodes
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.
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 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 l'invio di 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 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 serviziophp-apache
a intervalli di pochi millisecondi. Il comandosleep
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.
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.
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.
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.
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%).
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
- Nella console Google Cloud, vai alla pagina Gestisci risorse.
- Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
- Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.
Passaggi successivi
- Scopri di più sull'ottimizzazione dei costi di GKE, consulta le best practice per l'esecuzione di applicazioni Kubernetes con ottimizzazione dei costi su GKE.
- Trova suggerimenti e best practice di progettazione per ottimizzare il costo dei carichi di lavoro Google Cloud in Framework dell'architettura Google Cloud: ottimizzazione dei costi.
- Per maggiori dettagli su come ridurre i costi per le applicazioni batch, consulta Ottimizzazione dell'utilizzo delle risorse in un cluster GKE multi-tenant utilizzando il provisioning automatico dei nodi.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.