Percorso di apprendimento: applicazioni scalabili - Scalabilità

Autopilot

Questo insieme di tutorial è rivolto a operatori e amministratori IT che vogliono eseguire il deployment, eseguire e gestire ambienti di applicazioni moderne che vengono eseguiti su Google Kubernetes Engine (GKE). Man mano che procedi con questo insieme di tutorial, imparerai a configurare il monitoraggio e gli avvisi, a scalare i workload e a simulare un errore, il tutto utilizzando l'applicazione di microservizi di esempio Cymbal Bank:

1. Crea un cluster ed esegui il deployment di un'applicazione di esempio
2. Monitora con Google Cloud Managed Service per Prometheus
3. Scala i workload (questo tutorial)
4. Simula un errore
5. Centralizza la gestione dei cambiamenti

Panoramica e obiettivi

Un'applicazione consumer come Cymbal Bank spesso ha un numero variabile di utenti in momenti diversi. Idealmente, il tuo sito web è in grado di gestire i picchi di traffico senza rallentare o avere altri problemi, ma senza che l'organizzazione debba spendere soldi per le risorse cloud di cui non ha effettivamente bisogno. Una soluzione che Google Cloud prevede questo è la scalabilità automatica.

In questo tutorial imparerai a configurare i cluster e i workload in un cluster GKE per la scalabilità utilizzando sia le metriche Kubernetes integrate sia 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 oltre la consapevolezza del cluster Kubernetes, come il traffico di rete o i codici di risposta HTTP.
• Configura Horizontal Pod Autoscaler, una funzionalità di GKE che può aumentare o diminuire automaticamente il numero di pod per un workload a seconda delle metriche specificate.
• Simula il carico dell'applicazione e visualizza la risposta del gestore della scalabilità automatica del cluster e di Horizontal Pod Autoscaler.

Costi

L'abilitazione di GKE e il deployment dell'applicazione di esempio Cymbal Bank per questa serie di tutorial comportano addebiti per cluster per GKE on Google Cloud as elencati nella nostra pagina dei prezzi fino a quando non disabiliti GKE o elimini il progetto.

Sei anche responsabile degli altri Google Cloud costi sostenuti durante l'esecuzione dell' applicazione di esempio Cymbal Bank, come gli addebiti per le 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 utilizzi 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 procedi con la serie di tutorial, imparerai nuove competenze e utilizzerai prodotti e servizi Google Cloud aggiuntivi.

Devi anche creare un account di servizio IAM e concedere alcune autorizzazioni per il corretto funzionamento di Horizontal Pod Autoscaler:

1. Crea un account di servizio IAM. Questo account di servizio viene utilizzato nel tutorial per concedere l'accesso alle metriche personalizzate che consentono a Horizontal Pod Autoscaler di determinare quando eseguire lo scale up o lo scale down:

   gcloud iam service-accounts create scalable-apps
   

2. Concedi al account di servizio IAM l'accesso 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 account di servizio IAM vengono concessi i seguenti accessi:

   • roles/cloudtrace.agent: scrivi i dati di traccia, come le informazioni sulla latenza, in Trace.
   • roles/monitoring.metricWriter: scrivi le metriche in Cloud Monitoring.
   • roles/iam.workloadIdentityUser: consenti a un account di servizio Kubernetes di utilizzare Workload Identity Federation for GKE per fungere da service account IAM.

3. Configura il account di servizio Kubernetes default nello spazio dei nomi default in modo che funga da 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 default service account Kubernetes nello spazio dei nomi default di accedere alle stesse Google Cloud risorse del account di servizio IAM.

Configura la raccolta di metriche personalizzate

Puoi configurare Horizontal Pod Autoscaler in modo che utilizzi le metriche di CPU e memoria di 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 forniscono al cluster maggiori informazioni sul rendimento e sulle esigenze complessive dell'applicazione. In questo tutorial imparerai a utilizzare sia le metriche integrate sia quelle personalizzate.

1. Per consentire a Horizontal Pod Autoscaler di leggere le metriche personalizzate da Monitoring, devi installare l' adattatore delle metriche personalizzate - Stackdriver nel cluster.

   Esegui il deployment dell'adattatore Stackdriver delle metriche personalizzate nel cluster:

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter.yaml
   

2. Per consentire all'adattatore Stackdriver di ottenere metriche personalizzate dal cluster, utilizza Workload Identity Federation for GKE. Questo approccio utilizza un account di servizio IAM con le autorizzazioni per leggere le metriche di monitoraggio.

   Concedi al 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
   

3. Configura l'adattatore Stackdriver in modo che utilizzi Workload Identity Federation for GKE e il account di servizio IAM con le autorizzazioni per 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]"
   

4. Kubernetes include un proprio sistema per i service account per l'accesso all'interno di un cluster. Per consentire alle tue applicazioni di autenticarsi a servizi e risorse esterni ai cluster Google Kubernetes Engine, come Monitoring, utilizza Workload Identity Federation for GKE. Questo approccio configura il account di servizio Kubernetes in modo che utilizzi il account di servizio IAM per GKE.

   Aggiungi un'annotazione al 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
   

5. Riavvia il deployment dell'adattatore Stackdriver per applicare le modifiche:

   kubectl rollout restart deployment custom-metrics-stackdriver-adapter \
       --namespace=custom-metrics
   

Obiettivo: congratulazioni! Ora hai un adattatore Stackdriver nel tuo cluster GKE configurato per leggere le metriche personalizzate da Monitoring.

Configura Horizontal Pod Autoscaler

GKE Autopilot può fare lo scale in in diversi modi. In questo tutorial vedrai come il tuo cluster può scalare utilizzando i seguenti metodi:

• Horizontal Pod Autoscaler: scala il numero di pod per un workload.
• Gestore della scalabilità automatica del cluster: scala le risorse dei nodi disponibili nel cluster.

Questi due metodi possono funzionare insieme in modo che, man mano che il numero di pod per le applicazioni cambia, cambino anche le risorse dei nodi a supporto di 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 il deployment userservice utilizzando le metriche integrate e per il deployment frontend utilizzando le metriche personalizzate.

Per le tue applicazioni, collabora con gli sviluppatori di applicazioni e gli ingegneri della piattaforma per comprendere le loro esigenze e configurare le regole di 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 CPU. Utilizza un oggetto HorizontalPodAutoscaler per controllare il modo in cui vuoi che la tua applicazione risponda al carico. Nel manifest YAML per HorizontalPodAutoscaler, definisci il deployment da scalare per Horizontal Pod Autoscaler, le metriche da monitorare e il numero minimo e massimo di repliche che vuoi eseguire.

1. Esamina il manifest di esempio HorizontalPodAutoscaler per il deployment userservice:

   # Copyright 2022 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #      http://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   ---
   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: userservice
   spec:
     behavior:
       scaleUp:
         stabilizationWindowSeconds: 0
         policies:
           - type: Percent
             value: 100
             periodSeconds: 5
         selectPolicy: Max
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: userservice
     minReplicas: 5
     maxReplicas: 50
     metrics:
       - type: Resource
         resource:
           name: cpu
           target:
             type: Utilization
             averageUtilization: 60
   

   Questo manifest esegue le seguenti operazioni:

   • Imposta il numero massimo di repliche durante uno scale up su 50.
   • Imposta il numero minimo durante uno scale down su 5.
   • Utilizza una metrica Kubernetes integrata per prendere decisioni di scalabilità. In questo esempio, la metrica è l'utilizzo della CPU e l'utilizzo target è del 60%, il che evita sia l'utilizzo eccessivo sia quello insufficiente.

2. 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, potresti invece voler 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).

1. Esamina il manifest HorizontalPodAutoscaler per il deployment frontend:

   # Copyright 2022 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #      http://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   ---
   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: frontend
   spec:
     behavior:
       scaleUp:
         stabilizationWindowSeconds: 0
         policies:
           - type: Percent
             value: 100
             periodSeconds: 5
         selectPolicy: Max
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: frontend
     minReplicas: 5
     maxReplicas: 25
     metrics:
       - type: External
         external:
           metric:
             name: loadbalancing.googleapis.com|https|request_count
             selector:
               matchLabels:
                 resource.labels.forwarding_rule_name: FORWARDING_RULE_NAME
           target:
             type: AverageValue
             averageValue: "5"
   

   Questo manifest utilizza i seguenti campi:

   • spec.scaleTargetRef: la risorsa Kubernetes da scalare.
   • spec.minReplicas: il numero minimo di repliche, che in questo esempio è 5.
   • spec.maxReplicas: il numero massimo di repliche, che in questo esempio è 25.
   • spec.metrics.*: la metrica da utilizzare. In questo esempio, si tratta del 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 della risorsa specifica da filtrare durante la scalabilità.

2. 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
   

3. 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.

4. Applica il manifest al cluster:

   kubectl apply -f extras/postgres-hpa/hpa/frontend.yaml
   

Obiettivo: congratulazioni! Ora hai configurato le regole di Horizontal Pod Autoscaler per i deployment nel tuo cluster GKE utilizzando le metriche integrate di Kubernetes e le metriche personalizzate di Monitoring.

Simula il carico

In questa sezione utilizzerai un generatore di carico per simulare i picchi di traffico e osservare l'aumento del numero di repliche e di nodi per fare lo scale up e gestire l'aumento del carico nel tempo. Dopodiché, puoi interrompere la generazione di traffico e osservare il fare lo scale down del numero di repliche e di nodi in risposta.

1. Prima di iniziare, controlla lo stato di Horizontal Pod Autoscaler e il numero di repliche in uso.

   Ottieni lo stato delle risorse HorizontalPodAutoscaler:

   kubectl get hpa
   

   L'output è simile al seguente, che mostra che sono presenti 1 replica frontend e 5 repliche userservice:

   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
   

2. L'applicazione di esempio Cymbal Bank include un servizio loadgenerator. Questo servizio invia continuamente richieste che imitano gli utenti al frontend e crea periodicamente nuovi account e simula le transazioni tra loro.

   Espone localmente l'interfaccia web loadgenerator. Utilizza questa interfaccia per simulare il carico sull'applicazione di esempio Cymbal Bank:

   kubectl port-forward svc/loadgenerator 8080
   

   Se visualizzi un messaggio di errore, riprova quando il pod è in esecuzione.

3. 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 e poi fai clic su Anteprima sulla porta 8080.

4. Nell'interfaccia web del generatore di carico, se il valore Errori mostra 100%, completa i seguenti passaggi per aggiornare le impostazioni di test:

   1. Fai clic sul pulsante Arresta accanto al contatore della frequenza di errore.
   2. In Stato, fai clic sull'opzione Nuovo test.
   3. Aggiorna il valore Host all'indirizzo IP dell'ingresso di Cymbal Bank.
   4. Fai clic su Avvia swarm.

5. Nell'interfaccia web del generatore di carico, fai clic sulla scheda Grafici per osservare il rendimento nel tempo. Esamina il numero di richieste e l'utilizzo delle risorse.

6. Apri una nuova finestra del terminale e osserva il numero di repliche dei pod frontend e userservice:

   kubectl get hpa -w
   

   Il numero di repliche aumenta con l'aumentare del carico. Le azioni di scale up potrebbero richiedere circa dieci minuti, poiché il cluster riconosce che le metriche configurate raggiungono la soglia definita e utilizza Horizontal Pod Autoscaler per aumentare il 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
   

7. 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)' \
       --location="CONTROL_PLANE_LOCATION"
   

   Sostituisci CONTROL_PLANE_LOCATION con la località di Compute Engine del piano di controllo del cluster. Fornisci una regione per i cluster regionali o una zona per i cluster a livello di zona.

   Anche il numero di nodi è aumentato rispetto alla quantità iniziale per ospitare le nuove repliche. Questo aumento del numero di nodi è gestito da GKE Autopilot. Non devi configurare nulla per questa scalabilità dei nodi.

8. Apri l'interfaccia del generatore di carico e fai clic su Arresta per terminare il test.

9. Controlla di nuovo il numero di repliche e di nodi e osserva la riduzione dei numeri con il carico ridotto. La fare lo scale down potrebbe richiedere un po' di tempo, perché la finestra di stabilizzazione predefinita per le repliche nella risorsa HorizontalPodAutoscaler di Kubernetes è di cinque minuti.

In un ambiente reale, sia il numero di nodi sia quello di pod nel tuo ambiente aumenterebbero e diminuirebbero automaticamente nello stesso modo del carico simulato. L'applicazione di esempio Cymbal Bank è progettata per gestire questo tipo di scalabilità. Verifica con gli operatori delle app e gli ingegneri di affidabilità del sito (SRE) o gli sviluppatori di applicazioni se i loro workload possono trarre vantaggio da queste funzionalità di scalabilità.

Obiettivo: congratulazioni! Ora puoi configurare GKE in modo che esegua la scalabilità in base al carico, incluso l'utilizzo di metriche personalizzate di Monitoring.

Libera spazio

La serie di tutorial per Cymbal Bank è progettata per essere completata una dopo l'altra. Man mano che procedi con la serie di tutorial, imparerai nuove competenze e utilizzerai prodotti e servizi aggiuntivi. Google Cloud

Se vuoi fare una pausa prima di passare al tutorial successivo ed evitare che al tuo Google Cloud account vengano addebitati costi per le risorse utilizzate in questo tutorial, elimina il progetto che hai creato.

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

• L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per, le attività descritte in questo documento, eliminerai anche tutto il lavoro che hai svolto nel progetto.
• Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

1. Nella Google Cloud console, vai alla pagina Gestisci risorse.

   Vai a Gestisci risorse

2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
3. Nella finestra di dialogo, digita l'ID progetto e fai clic su Chiudi per eliminare il progetto.

Passaggi successivi

Nel tutorial successivo imparerai a simulare un errore in GKE.