Questo insieme di tutorial è rivolto agli amministratori IT e agli operatori che vogliono eseguire il deployment, eseguire e gestire ambienti applicativi moderni eseguiti sulla versione Google Kubernetes Engine (GKE) Enterprise. Man mano che procedi in questo insieme di tutorial, imparerai a configurare monitoraggio e avvisi, scalare i carichi di lavoro e simulare errori, il tutto utilizzando l'applicazione di microservizi di esempio Cymbal Bank:
- Crea un cluster ed esegui il deployment di un'applicazione di esempio
- Monitoraggio con Google Cloud Managed Service per Prometheus
- Scala i carichi di lavoro (questo tutorial)
- Simula un errore
Panoramica e obiettivi
Un'applicazione consumer come Cymbal Bank ha spesso un numero di utenti variabile in momenti diversi. Idealmente, il tuo sito web è in grado di far fronte ai picchi di traffico senza rallentare o avere altri problemi, ma senza che l'organizzazione debba spendere denaro in risorse Cloud di cui non ha effettivamente bisogno. Una soluzione offerta da Google Cloud è la scalabilità automatica.
In questo tutorial imparerai a configurare cluster e carichi di lavoro in un cluster GKE per la scalabilità utilizzando sia le metriche Kubernetes integrate che le metriche personalizzate di Cloud Monitoring e Cloud Trace. Imparerai a completare le seguenti attività:
- Abilita le metriche personalizzate in Cloud Monitoring per Trace.
- Le metriche personalizzate ti consentono di scalare utilizzando dati di monitoraggio aggiuntivi o input esterni che vanno oltre l'identificazione del cluster Kubernetes, come il traffico di rete o i codici di risposta HTTP.
- Configurare Horizontal Pod Autoscaler, una funzionalità di GKE che può aumentare o diminuire automaticamente il numero di pod per un carico di lavoro in base alle metriche specificate.
- Simula il carico dell'applicazione e visualizza la risposta del gestore della scalabilità automatica dei cluster e Horizontal Pod Autoscaler.
Costi
L'abilitazione di GKE Enterprise e il deployment dell'applicazione di esempio Cymbal Bank per questa serie di tutorial comportano l'addebito di addebiti per cluster per GKE Enterprise su Google Cloud, come indicato nella nostra pagina Prezzi, fino a quando non disattivi GKE Enterprise o elimini il progetto.
Sei inoltre responsabile di altri costi di Google Cloud sostenuti durante l'esecuzione dell'applicazione di esempio Cymbal Bank, ad esempio gli addebiti per le VM di Compute Engine e Trace.
Prima di iniziare
Per scoprire come scalare i tuoi deployment, devi completare il primo tutorial per creare un cluster GKE che utilizzi Autopilot ed eseguire il deployment dell'applicazione di esempio basata su microservizi di Cymbal Bank.
Ti consigliamo di completare questo insieme di tutorial per Cymbal Bank in ordine. Man mano che procedi nella serie di tutorial, acquisisci nuove competenze e utilizzi prodotti e servizi Google Cloud aggiuntivi.
Devi inoltre creare un account di servizio IAM e concedere alcune autorizzazioni affinché Horizontal Pod Autoscaler funzioni correttamente:
Creare un account di servizio IAM. Questo account di servizio viene utilizzato nel tutorial per concedere l'accesso a metriche personalizzate che consentano al gestore della scalabilità automatica dei pod di determinare quando fare lo scale up o lo scale down:
gcloud iam service-accounts create scalable-apps
Concedi l'accesso all'account di servizio IAM per eseguire le azioni di scalabilità richieste:
gcloud projects add-iam-policy-binding PROJECT_ID \ --role roles/cloudtrace.agent \ --member "serviceAccount:scalable-apps@PROJECT_ID.iam.gserviceaccount.com" gcloud projects add-iam-policy-binding PROJECT_ID \ --role roles/monitoring.metricWriter \ --member "serviceAccount:scalable-apps@PROJECT_ID.iam.gserviceaccount.com" gcloud iam service-accounts add-iam-policy-binding "scalable-apps@PROJECT_ID.iam.gserviceaccount.com" \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[default/default]"
All'account di servizio IAM è stato concesso il seguente accesso:
roles/cloudtrace.agent
: scrivi dati di traccia come le informazioni sulla latenza in Trace.roles/monitoring.metricWriter
: scrivi metriche in Cloud Monitoring.roles/iam.workloadIdentityUser
: consentire a un account di servizio Kubernetes di utilizzare Workload Identity come account di servizio IAM.
Configura l'account di servizio Kubernetes
default
nello spazio dei nomidefault
in modo che agisca come account di servizio IAM che hai creato:kubectl annotate serviceaccount default \ iam.gke.io/gcp-service-account=scalable-apps@PROJECT_ID.iam.gserviceaccount.com
Questa configurazione consente ai pod che utilizzano l'account di servizio Kubernetes
default
nello spazio dei nomidefault
di accedere alle stesse risorse Google Cloud dell'account di servizio IAM.
Configura la raccolta di metriche personalizzate
Puoi configurare Horizontal Pod Autoscaler in modo da utilizzare metriche di memoria e CPU Kubernetes integrate di base oppure puoi utilizzare metriche personalizzate di Cloud Monitoring, come le richieste HTTP al secondo o la quantità di istruzioni SELECT
. Le metriche personalizzate possono funzionare senza modifiche all'applicazione e offrono al tuo cluster più insight sulle prestazioni e sulle esigenze complessive dell'applicazione. In questo tutorial imparerai
a usare le metriche integrate e personalizzate.
Per consentire a Horizontal Pod Autoscaler di leggere le metriche personalizzate da Monitoring, devi installare l'adattatore Custom Metrics - Stackdriver Adapter nel cluster.
Esegui il deployment dell'adattatore di metriche personalizzate Stackdriver sul tuo cluster:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter.yaml
Utilizza Workload Identity per consentire all'adattatore Stackdriver di ottenere metriche personalizzate dal cluster. Questo approccio utilizza un account di servizio IAM che dispone delle autorizzazioni per leggere le metriche di monitoraggio.
Concedi all'account di servizio IAM il ruolo
roles/monitoring.viewer
:gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:scalable-apps@PROJECT_ID.iam.gserviceaccount.com" \ --role roles/monitoring.viewer
Configura l'adattatore Stackdriver per l'utilizzo di Workload Identity e l'account di servizio IAM autorizzato a leggere le metriche di monitoraggio:
gcloud iam service-accounts add-iam-policy-binding scalable-apps@PROJECT_ID.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[custom-metrics/custom-metrics-stackdriver-adapter]"
Kubernetes include il proprio sistema per gli account di servizio per l'accesso all'interno di un cluster. Per consentire l'autenticazione delle applicazioni in servizi e risorse al di fuori dei cluster della versione Google Kubernetes Engine (GKE) Enterprise, ad esempio Monitoring, utilizza Workload Identity. Questo approccio configura l'account di servizio Kubernetes in modo da utilizzare l'account di servizio IAM per GKE.
Annota l'account di servizio Kubernetes utilizzato dall'adattatore:
kubectl annotate serviceaccount custom-metrics-stackdriver-adapter \ --namespace=custom-metrics \ iam.gke.io/gcp-service-account=scalable-apps@PROJECT_ID.iam.gserviceaccount.com
Riavvia il deployment dell'adattatore Stackdriver per applicare le modifiche:
kubectl rollout restart deployment custom-metrics-stackdriver-adapter \ --namespace=custom-metrics
Configura Horizontal Pod Autoscaler
GKE Autopilot può fare lo scale in diversi modi. In questo tutorial vedrai come può scalare il tuo cluster utilizzando i seguenti metodi:
- Horizontal Pod Autoscaler: scala il numero di pod per un carico di lavoro.
- Gestore della scalabilità automatica dei cluster: scala le risorse dei nodi disponibili nel cluster.
Questi due metodi possono interagire in modo che, se cambia il numero di pod per le tue applicazioni, cambiano anche le risorse dei nodi per supportare quei pod.
Sono disponibili altre implementazioni per la scalabilità dei pod che si basano su Horizontal Pod Autoscaler e puoi utilizzare Vertical Pod Autoscaler per regolare le richieste di CPU e memoria di un pod anziché il numero di pod.
In questo tutorial configurerai Horizontal Pod Autoscaler per il deployment userservice
utilizzando metriche integrate e per il deployment frontend
utilizzando metriche personalizzate.
Per le tue applicazioni, collabora con gli sviluppatori di applicazioni e i tecnici di piattaforma per comprendere le loro esigenze e configurare le regole Horizontal Pod Autoscaler.
Scala il deployment userservice
Quando il numero di utenti dell'applicazione di esempio Cymbal Bank aumenta, il servizio userservice
consuma più risorse della CPU. Puoi utilizzare un oggetto HorizontalPodAutoscaler
per controllare il modo in cui vuoi che l'applicazione risponda al caricamento. Nel manifest YAML per HorizontalPodAutoscaler
, definisci il deployment per il gestore della Horizontal Pod Autoscaler, le metriche da monitorare e il numero minimo e massimo di repliche che vuoi eseguire.
Esamina il manifest di esempio
HorizontalPodAutoscaler
per il deploymentuserservice
:Questo file manifest esegue le seguenti operazioni:
- Imposta il numero massimo di repliche durante uno scale up a
50
. - Imposta il numero minimo di durante uno scale down a
5
. - Utilizza una metrica Kubernetes integrata per prendere decisioni sulla scalabilità. In questo esempio, la metrica è l'utilizzo della CPU e l'utilizzo target è 60%, per evitare un utilizzo eccessivo e insufficiente.
- Imposta il numero massimo di repliche durante uno scale up a
Applica il manifest al cluster:
kubectl apply -f extras/postgres-hpa/hpa/userservice.yaml
Scala il deployment frontend
Nella sezione precedente hai configurato Horizontal Pod Autoscaler sul deployment userservice
in base alle metriche Kubernetes integrate per l'utilizzo della CPU. Per il deployment frontend
, ti conviene scalare in base al numero di richieste HTTP in entrata. Questo approccio utilizza
l'adattatore Stackdriver per leggere le metriche personalizzate da Monitoring per
l'oggetto Ingress del bilanciatore del carico HTTP(S).
Esamina il manifest
HorizontalPodAutoscaler
per il deploymentfrontend
:Questo manifest utilizza i seguenti campi:
spec.scaleTargetRef
: la risorsa Kubernetes da scalare.spec.minReplicas
: il numero minimo di repliche, ovvero5
in questo esempio.spec.maxReplicas
: il numero massimo di repliche, che in questo esempio è25
.spec.metrics.*
: la metrica da utilizzare. In questo esempio, questo è il numero di richieste HTTP al secondo, che è una metrica personalizzata di Monitoring fornita dall'adattatore di cui hai eseguito il deployment.spec.metrics.external.metric.selector.matchLabels
: l'etichetta specifica della risorsa da filtrare durante la scalabilità.
Trova il nome della regola di forwarding dal bilanciatore del carico Ingress
frontend
:export FW_RULE=$(kubectl get ingress frontend -o=jsonpath='{.metadata.annotations.ingress\.kubernetes\.io/forwarding-rule}') echo $FW_RULE
L'output è simile al seguente:
k8s2-fr-j76hrtv4-default-frontend-wvvf7381
Aggiungi la regola di forwarding al manifest:
sed -i "s/FORWARDING_RULE_NAME/$FW_RULE/g" "extras/postgres-hpa/hpa/frontend.yaml"
Questo comando sostituisce
FORWARDING_RULE_NAME
con la regola di forwarding salvata.Applica il manifest al cluster:
kubectl apply -f extras/postgres-hpa/hpa/frontend.yaml
Simula caricamento
In questa sezione viene utilizzato un generatore di carico per simulare picchi di traffico e osservare il numero di repliche e lo scale up del numero di nodi per adeguarsi all'aumento del carico nel tempo. Puoi quindi interrompere la generazione di traffico e osservare lo fare lo scale down della replica e del conteggio dei nodi in risposta.
Prima di iniziare, controlla lo stato di Horizontal Pod Autoscaler e osserva il numero di repliche in uso.
Ottieni lo stato delle tue risorse
HorizontalPodAutoscaler
:kubectl get hpa
L'output è simile al seguente, che mostra la presenza di 1 replica
frontend
e 5 replicheuserservice
:NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE frontend Deployment/frontend <unknown>/5 (avg) 5 25 1 34s userservice Deployment/userservice 0%/60% 5 50 5 4m56s
L'applicazione di esempio di Cymbal Bank include un servizio
loadgenerator
. Questo servizio invia continuamente richieste che imitano gli utenti al frontend, crea periodicamente nuovi account e simula le transazioni tra di loro.Esponi a livello locale l'interfaccia web di
loadgenerator
. Utilizzerai questa interfaccia per simulare il carico sull'applicazione di esempio di Cymbal Bank:kubectl port-forward svc/loadgenerator 8080
Se vedi un messaggio di errore, riprova mentre il pod è in esecuzione.
In un browser sul computer, apri l'interfaccia web del generatore di carico:
- Se utilizzi una shell locale, apri un browser e vai all'indirizzo http://127.0.0.1:8080.
- Se utilizzi Cloud Shell, fai clic su Anteprima web, quindi fai clic su Anteprima sulla porta 8080.
Nell'interfaccia web del generatore di carico, se il valore Failures (Errori) mostra
100%
, completa questi passaggi per aggiornare le impostazioni di test:- Fai clic sul pulsante Interrompi accanto al contatore del tasso di errori.
- In Stato, fai clic sull'opzione Nuovo test.
- Aggiorna il valore Host in base all'indirizzo IP del traffico in entrata di Cymbal Bank.
- Fai clic su Inizia a creare sciamucchi.
Nell'interfaccia web del generatore di carico, fai clic sulla scheda Grafici per osservare il rendimento nel tempo. Osserva il numero di richieste e l'utilizzo delle risorse.
Apri una nuova finestra del terminale e osserva il numero di repliche dei pod
frontend
euserservice
:kubectl get hpa -w
Il numero di repliche aumenta con l'aumento del carico. Le azioni di scaleUp potrebbero richiedere circa dieci minuti quando il cluster riconosce che le metriche configurate raggiungono la soglia definita e utilizzano Horizontal Pod Autoscaler per lo scale up del numero di pod.
L'output di esempio seguente mostra che il numero di repliche è aumentato durante l'esecuzione del generatore di carico:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS frontend Deployment/frontend 5200m/5 (avg) 5 25 13 userservice Deployment/userservice 71%/60% 5 50 17
Apri un'altra finestra del terminale e controlla il numero di nodi nel cluster:
gcloud container clusters list \ --filter='name=scalable-apps' \ --format='table(name, currentMasterVersion, currentNodeVersion, currentNodeCount)' \ --region="REGION"
Sostituisci
REGION
con la regione in cui viene eseguito il cluster.Anche il numero di nodi è aumentato rispetto alla quantità iniziale per ospitare le nuove repliche. Questo aumento del numero di nodi è basato su GKE Autopilot. Non c'è nulla da configurare per la scalabilità dei nodi.
Apri l'interfaccia del generatore di carico e fai clic su Arresta per terminare il test.
Controlla di nuovo il numero di repliche e di nodi e osserva come i numeri si riducono con il carico ridotto. Lo fare lo scale down potrebbe richiedere del tempo, perché la finestra di stabilizzazione predefinita per le repliche nella risorsa
HorizontalPodAutoscaler
Kubernetes è di cinque minuti.
In un ambiente reale, sia il numero di nodi che di pod nel tuo ambiente dà automaticamente lo scale up e lo scale down come con questo caricamento simulato. L'applicazione di esempio Cymbal Bank è progettata per supportare questo tipo di scalabilità. Rivolgiti ai tuoi operatori di app e agli sviluppatori di applicazioni (SRE) o Site Reliability Engineering (SRE) per capire se i loro carichi di lavoro possono trarre vantaggio da queste funzionalità di scalabilità.
Esegui la pulizia
La serie di tutorial per Cymbal Bank è progettata per essere completata uno dopo l'altro. Proseguendo con la serie di tutorial, acquisisci nuove competenze e utilizzi prodotti e servizi Google Cloud aggiuntivi.
Se vuoi fare una pausa prima di passare al tutorial successivo ed evitare che al tuo account Google Cloud vengano addebitati costi per le risorse utilizzate in questo tutorial, elimina il progetto che hai creato.
- 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 come simulare un errore in GKE Enterprise nel prossimo tutorial.