Questo insieme di tutorial è rivolto agli amministratori IT e agli operatori che vogliono per eseguire il deployment, eseguire e gestire ambienti applicativi moderni in esecuzione Google Kubernetes Engine (GKE). Man mano che procedi in questa serie di tutorial, imparerai a configurare monitoraggio e avvisi, scalare i carichi di lavoro e simulare in errore, il tutto utilizzando l'applicazione di microservizi di esempio di 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 per consumatori come Cymbal Bank ha spesso un numero variabile di utenti in momenti diversi. Idealmente, il tuo sito web è in grado di gestire gli aumenti di traffico senza rallentamenti o altri problemi, senza che l'organizzazione debba spendere soldi per risorse Cloud di cui non ha effettivamente bisogno. Una soluzione Google Cloud fornisce a questo scopo la scalabilità automatica.
In questo tutorial imparerai a configurare cluster e carichi di lavoro in un per la scalabilità di un cluster GKE mediante le metriche Kubernetes integrate. e metriche personalizzate di Cloud Monitoring e Cloud Trace. Imparerai a: completa le seguenti attività:
- Abilita le metriche personalizzate in Cloud Monitoring per Trace.
- Le metriche personalizzate ti consentono di eseguire il ridimensionamento utilizzando dati di monitoraggio aggiuntivi o input esterni non noti al cluster Kubernetes, come il traffico di rete o i codici di risposta HTTP.
- Configurare Horizontal Pod Autoscaler, una funzionalità di GKE che consente aumenta o diminuisce automaticamente il numero di pod per un carico di lavoro, in base a metriche specificate.
- Simula il carico dell'applicazione e visualizza la risposta del gestore della scalabilità automatica del cluster e di Horizontal Pod Autoscaler.
Costi
È in corso l'abilitazione di GKE e il deployment dell'applicazione di esempio di Cymbal Bank per Questa serie di tutorial prevede l'addebito di costi per cluster GKE su Google Cloud come elencato Pagina dei prezzi fino a quando non disabiliterai GKE o eliminerai il progetto.
Sei inoltre responsabile di altri costi di Google Cloud sostenuti durante l'esecuzione del Applicazione di esempio di Cymbal Bank, ad esempio addebiti per VM di Compute Engine e Trace.
Prima di iniziare
Per scoprire come scalare i deployment, devi completare il primo tutorial per creare un cluster GKE che utilizza Autopilot ed eseguire il deployment dell'applicazione di esempio basata su microservizi Cymbal Bank.
Ti consigliamo di completare questa serie di tutorial per le app scalabili in ordine. Man mano che avanzi nella serie di tutorial, acquisisci nuove competenze e utilizzi altri prodotti e servizi Google Cloud.
Devi inoltre creare un account di servizio IAM e concedere delle autorizzazioni necessarie affinché Horizontal Pod Autoscaler funzioni correttamente:
Creare un account di servizio IAM. Questo account di servizio viene utilizzato nel tutorial per concedere l'accesso alle metriche personalizzate che consentono al gestore della scalabilità automatica orizzontale dei pod di determinare quando eseguire l'aumento o la riduzione della scalabilità:
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]"
Al service account IAM viene 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
: consenti a un account di servizio Kubernetes di utilizzare la federazione delle identità per i carichi di lavoro per GKE per agire come account di servizio IAM.
Configura l'account di servizio Kubernetes
default
nello spazio dei nomidefault
in modo che agisca come l'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 il servizio Kubernetes
default
nello spazio dei nomidefault
per accedere allo stesso account Google Cloud come l'account di servizio IAM.
Configurare la raccolta di metriche personalizzate
Puoi configurare Horizontal Pod Autoscaler in modo che utilizzi Kubernetes integrato di base
Metriche di CPU e memoria oppure puoi usare metriche personalizzate di Cloud Monitoring
come le richieste HTTP al secondo o la quantità di istruzioni SELECT
. Personalizzate
possono funzionare senza modifiche all'applicazione e fornire al tuo cluster più insight
sulle prestazioni e sulle esigenze
complessive dell'applicazione. In questo tutorial imparerai a utilizzare sia le metriche integrate sia quelle personalizzate.
Consentire a Horizontal Pod Autoscaler di leggere le metriche personalizzate Monitoring, devi installare Metriche personalizzate - Adattatore Stackdriver nel tuo cluster.
Esegui il deployment dell'adattatore Stackdriver delle metriche personalizzate nel tuo cluster:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter.yaml
Per consentire all'adattatore Stackdriver di ottenere le metriche personalizzate dal tuo cluster, utilizza la federazione delle identità per i carichi di lavoro per GKE. Questo approccio utilizza un account di servizio IAM con autorizzazioni per leggere le metriche di monitoraggio.
Concedi all'account di servizio IAM il
roles/monitoring.viewer
ruolo: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 utilizzare la federazione delle identità per i carichi di lavoro per GKE e Account di servizio IAM che dispone delle autorizzazioni per leggere 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 un 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 all'esterno dei tuoi cluster Google Kubernetes Engine, Monitoring utilizzi la federazione delle identità per i carichi di lavoro per GKE. Questo approccio configura l'account di servizio Kubernetes per l'utilizzo per GKE.
Aggiungi un'annotazione all'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ò essere scalato in diversi modi. In questo tutorial, scoprirai come il tuo cluster può essere scalato utilizzando i seguenti metodi:
- Gestore della scalabilità automatica dei pod orizzontali: scala il numero di pod per un carico di lavoro.
- Scalabilità automatica dei cluster: scala le risorse dei nodi disponibili nel cluster.
Questi due metodi possono interagire in modo che, come il numero di pod per modifiche delle applicazioni, cambiano anche le risorse dei nodi per supportare questi pod.
Sono disponibili altre implementazioni per scalare i pod basati su Horizontal Pod Autoscaler e puoi anche 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
userservice
Deployment mediante metriche integrate e per frontend
Deployment tramite metriche personalizzate.
Per le tue applicazioni, collabora con i tuoi sviluppatori di applicazioni e Platform engineer per comprendere le loro esigenze e configurare il piano orizzontale regole del gestore della scalabilità automatica dei pod.
Scala il deployment userservice
Quando il numero di utenti dell'applicazione di esempio Cymbal Bank aumenta, il servizio userservice
consuma più risorse della CPU. Utilizzi un oggetto
HorizontalPodAutoscaler
per controllare la modalità di risposta dell'applicazione al caricamento. Nel manifest YAML per HorizontalPodAutoscaler
,
definire quale deployment far scalare da Horizontal Pod Autoscaler,
metriche da monitorare e il numero minimo e massimo di repliche da monitorare
vengono eseguiti tutti i test delle unità.
Esamina il file manifest di esempio
HorizontalPodAutoscaler
peruserservice
Deployment:Questo manifest esegue le seguenti operazioni:
- Imposta il numero massimo di repliche durante un ridimensionamento su
50
. - Imposta il numero minimo di durante una riduzione a
5
. - Utilizza una metrica Kubernetes integrata per prendere decisioni di scalabilità. In questo esempio, la metrica è l'utilizzo della CPU e l'utilizzo target è intorno al 60%, il che evita sia il sovrautilizzo sia il sottoutilizzo.
- Imposta il numero massimo di repliche durante un ridimensionamento su
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 nel deployment userservice
in base alle metriche di Kubernetes integrate per l'utilizzo della CPU. Per il deployment frontend
, ti consigliamo di scalare
in base al numero di richieste HTTP in entrata. Questo approccio utilizza
Adattatore Stackdriver per leggere le metriche personalizzate da Monitoring per
dell'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, ovvero25
in questo campione.spec.metrics.*
: la metrica da utilizzare. In questo esempio, si tratta del numero di richieste HTTP al secondo, che è una metrica personalizzata del monitoraggio fornita dall'adattatore di cui è stato eseguito il deployment.spec.metrics.external.metric.selector.matchLabels
: lo specifico dell'etichetta della risorsa da filtrare durante la scalabilità.
Trova il nome della regola di inoltro dal bilanciatore del carico
frontend
in entrata: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 il carico
In questa sezione viene utilizzato un generatore di carico per simulare picchi di traffico e osserva lo scale up del numero di repliche e del numero di nodi per adeguarsi all'aumento nel tempo. Puoi quindi interrompere la generazione di traffico e osservare la riduzione del numero di repliche e nodi in risposta.
Prima di iniziare, controlla lo stato di Horizontal Pod Autoscaler e il numero di repliche in uso.
Ottieni lo stato delle tue risorse
HorizontalPodAutoscaler
:kubectl get hpa
L'output è simile al seguente e mostra che c'è 1
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 Cymbal Bank include un servizio
loadgenerator
. Questo Il servizio invia continuamente richieste che imitano gli utenti al frontend e crea periodicamente nuovi account e simula le transazioni tra di loro.Esponi l'interfaccia web di
loadgenerator
localmente. Utilizza questa interfaccia per simulare il carico sull'applicazione di esempio 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, Fai clic su Anteprima sulla porta 8080.
Nell'interfaccia web del generatore di carico, se il valore Errori è
100%
, completa i seguenti passaggi per aggiornare le impostazioni del 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 con l'indirizzo IP dell'ingresso di Cymbal Bank.
- Fai clic su Inizia a creare sciamucchi.
Nell'interfaccia web del generatore di carico, fai clic sulla scheda Grafici per osservare le prestazioni nel tempo. Esamina il numero di richieste e l'utilizzo delle risorse.
Apri una nuova finestra del terminale e osserva il numero di repliche del tuo
frontend
euserservice
pod:kubectl get hpa -w
Il numero di repliche aumenta con l'aumento del carico. Azioni di scaleUp potrebbero essere necessari circa dieci minuti, poiché il cluster riconosce che le metriche configurate raggiungono la soglia definita e utilizzano il pod orizzontale Gestore della scalabilità automatica per lo scale up del numero di pod.
L'output di esempio seguente mostra che il numero di repliche è aumentato quando funziona il 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 eseguita dal cluster in.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 è necessario configurare nulla per questa scalabilità dei nodi.
Apri l'interfaccia del generatore di carico e fai clic su Interrompi per terminare il test.
Controlla di nuovo il conteggio delle repliche e il conteggio dei nodi e osserva come i numeri si riducono con il carico ridotto. Lo fare lo scale down potrebbe richiedere del tempo la finestra di stabilizzazione predefinita per le repliche in Kubernetes
HorizontalPodAutoscaler
risorsa dura cinque minuti.
In un ambiente reale, sia il numero di nodi che i pod nel tuo ambiente fa automaticamente lo scale up e lo scale down come in questa caricamento. L'applicazione di esempio di Cymbal Bank è progettata per soddisfare questo tipo di e la scalabilità delle applicazioni. Rivolgiti ai tuoi operatori di app e al Site Reliability Engineering (SRE) agli sviluppatori di applicazioni per vedere se i loro carichi di lavoro possono trarre vantaggio da questi le funzionalità di scalabilità.
Esegui la pulizia
L'insieme di tutorial per Cymbal Bank è pensato per essere completato uno dopo il e l'altro. Man mano che procedi nella serie di tutorial, acquisisci nuove competenze e per utilizzare altri prodotti e servizi Google Cloud.
Se vuoi fare una pausa prima di passare al tutorial successivo ed evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che hai creato.
- 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 come simulano un errore in GKE nel prossimo tutorial.