Questa pagina è stata tradotta dall'API Cloud Translation.

Percorso di apprendimento: Applicazioni scalabili - Scalabilità

Questo insieme di tutorial è rivolto ad amministratori IT e operatori che vogliono eseguire il deployment, l'esecuzione e la gestione di ambienti di applicazioni moderni che funzionano su Google Kubernetes Engine (GKE) Enterprise. Man mano che avanzi in questo insieme di tutorial, imparerai come configurare il monitoraggio e gli avvisi, scalare i carichi di lavoro e simulare i guasti, il tutto utilizzando l'applicazione di microservizi di esempio Cymbal Bank:

Creare un cluster ed eseguire il deployment di un'applicazione di esempio
Monitoraggio con Google Cloud Managed Service per Prometheus
Scalare i carichi di lavoro (questo tutorial)
Simulare un errore
Centralizza la gestione dei cambiamenti

Panoramica e obiettivi

Un'applicazione consumer come Cymbal Bank ha spesso un numero di utenti variabile su in momenti diversi. Idealmente il tuo sito web è in grado di far fronte ai picchi di traffico senza rallentamenti o altri problemi, ma senza che l'organizzazione abbia a spendere in risorse Cloud di cui non hanno effettivamente bisogno. Una soluzione Google Cloud fornisce a questo scopo la scalabilità automatica.

In questo tutorial imparerai a configurare i cluster e i carichi di lavoro in un cluster GKE per la scalabilità utilizzando sia le metriche di Kubernetes integrate sia le 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 scalare usando dati di monitoraggio aggiuntivi o di input esterni che vanno oltre la consapevolezza del cluster Kubernetes, come traffico di rete o 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 alle metriche specificate.
Simula il carico dell'applicazione e visualizza la risposta del gestore della scalabilità automatica del cluster e di Horizontal Pod Autoscaler.

Costi

Se attivi GKE Enterprise e esegui il deployment dell'applicazione di esempio Cymbal Bank per questa serie di tutorial, dovrai sostenere costi per GKE Enterprise su Google Cloud per ogni cluster, come indicato nella nostra pagina dei prezzi, finché non disattivi GKE Enterprise o non elimini 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 imparare a scalare i deployment, devi completare la primo tutorial per creare un cluster GKE che utilizzi Autopilot ed eseguire il deployment l'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 avanzi nella serie di tutorial, acquisisci nuove competenze e utilizzi altri prodotti e servizi Google Cloud.

Devi anche creare un account di servizio IAM e concedere alcune autorizzazioni affinché Horizontal Pod Autoscaler funzioni correttamente:

Crea 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 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 i dati di traccia, ad esempio 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 utilizza la federazione delle identità per i carichi di lavoro per GKE come servizio IAM .

Configura l'account di servizio Kubernetes default nello spazio dei nomi default 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 l'account di servizio Kubernetes default nello spazio dei nomi default di accedere alle stesse risorse Google Cloud dell'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 utilizzare metriche personalizzate di Cloud Monitoring come HTTP richieste al secondo o la quantità di istruzioni SELECT. Le metriche personalizzate possono lavorare senza modifiche all'applicazione e fornire al tuo cluster più insight le prestazioni e le esigenze generali dell'applicazione. In questo tutorial imparerai a come usare le metriche integrate e personalizzate.

Per consentire a Horizontal Pod Autoscaler di leggere le metriche personalizzate da Monitoring, devi installare l'adattatore 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 modello IAM con un account di servizio autorizzato a 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 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 alle tue applicazioni di autenticarsi in servizi e risorse al di fuori dei cluster Google Kubernetes Engine (GKE) Enterprise, come il monitoraggio, utilizza la federazione delle identità per i carichi di lavoro per GKE. Questo approccio configura l'account di servizio Kubernetes per l'utilizzo 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

Configurare Horizontal Pod Autoscaler

GKE Autopilot può essere scalato in diversi modi. In questo il tutorial mostra come può scalare il tuo cluster con i seguenti metodi:

Horizontal Pod Autoscaler: 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 che si basano su Horizontal Pod Autoscaler, ma puoi anche utilizzare Vertical Pod Autoscaler 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 HorizontalPodAutoscaler per controllare il modo in cui vuoi che l'applicazione al carico. Nel file manifest YAML per HorizontalPodAutoscaler, definisci il deployment di cui deve essere eseguito lo scaling da parte di Horizontal Pod Autoscaler, le metriche da monitorare e il numero minimo e massimo di repliche da eseguire.

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

Il file 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.

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 di frontend, ti consigliamo di eseguire lo scaling 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 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, pari a 5 in questo valore campione.
spec.maxReplicas: il numero massimo di repliche, ovvero 25 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: l'etichetta della risorsa specifica 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 replica fare lo scale down del conteggio dei nodi in risposta.

Prima di iniziare, controlla lo stato di Horizontal Pod Autoscaler e esamina 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 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

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 a livello locale l'interfaccia web di loadgenerator. 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 su 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:
1. Fai clic sul pulsante Interrompi accanto al contatore del tasso di errori.
2. In Stato, fai clic sull'opzione Nuovo test.
3. Aggiorna il valore Host con l'indirizzo IP dell'ingresso di Cymbal Bank.
4. Fai clic su Avvia swarming.
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.
Apri una nuova finestra del terminale e controlla il numero di repliche dei pod frontend e userservice:
```
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, dalla quantità iniziale a che ospita 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 Arresta per terminare il test.
Controlla di nuovo il numero di repliche e il numero di nodi e osserva i numeri si riducono con il carico ridotto. Lo scale down potrebbe richiedere del tempo, perché la finestra di stabilizzazione predefinita per le repliche nella risorsa KubernetesHorizontalPodAutoscaler è di 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 agli operatori di app e agli SRE (Site Reliability Engineering) o agli sviluppatori di applicazioni per verificare se i loro carichi di lavoro possono trarre vantaggio da queste 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.

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, quando lo elimini elimini anche tutto il lavoro 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 appspot.com URL, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, il riuso dei progetti può aiutarti a non superare i limiti di quota.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
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 simulare un errore in GKE Enterprise nel prossimo tutorial.