Percorso di apprendimento: applicazioni scalabili - Scalabilità

Configurare la raccolta di metriche personalizzate

Puoi configurare Horizontal Pod Autoscaler in modo da utilizzare le metriche di CPU e memoria di Kubernetes integrate di base oppure puoi utilizzare le 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 fornire al cluster informazioni più dettagliate 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 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
   

2. 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 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 la federazione delle identità per i carichi di lavoro per GKE e il account di servizio IAM che dispone delle 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 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 tuoi cluster Google Kubernetes Engine, come il monitoraggio, utilizza la federazione delle identità per i carichi di lavoro per GKE. Questo approccio configura l'account di servizio Kubernetes in modo da utilizzare l'account di servizio IAM 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
   

5. 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ò fare lo scale in diversi modi. In questo tutorial, scoprirai come il tuo cluster può essere scalato utilizzando 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 essere utilizzati insieme in modo che, quando cambia il numero di pod per le tue applicazioni, cambino anche le risorse del nodo 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, configuri 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 del gestore della scalabilità automatica dei pod orizzontali.

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

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

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 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 l'adattatore Stackdriver per leggere le metriche personalizzate da Monitoraggio 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, ovvero 5 in questo esempio.
   • 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à.

2. Trova il nome della regola di forwarding dal bilanciatore del carico frontend Ingress:

   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
   

Simula il carico

In questa sezione, utilizzi un generatore di carico per simulare picchi di traffico e osservare l'aumento del numero di repliche e nodi per far fronte all'aumento del carico nel tempo. Puoi quindi interrompere la generazione di traffico e osservare la fare lo scale down del numero di repliche e nodi in risposta.

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

   Visualizza 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 simulano gli utenti al frontend e periodicamente crea 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 viene visualizzato 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 preview Anteprima web e poi su Anteprima sulla porta 8080.

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

   1. Fai clic sul pulsante Interrompi accanto al contatore del tasso di errore.
   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.

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 controlla il numero di repliche dei pod frontend e userservice:

   kubectl get hpa -w
   

   Il numero di repliche aumenta con l'aumento del carico. Le azioni di scaleUp possono richiedere circa dieci minuti quando il cluster riconosce che le metriche configurate raggiungono la soglia definita e utilizza Horizontal Pod Autoscaler per aumentare il numero di pod.

   L'esempio di output seguente mostra che il numero di repliche è aumentato con 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)' \
       --region="REGION"
   

   Sostituisci REGION con la regione in cui è in esecuzione il cluster.

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

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

9. 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, perché la finestra di stabilizzazione predefinita per le repliche nella risorsa KubernetesHorizontalPodAutoscaler è di cinque minuti.

In un ambiente reale, sia il numero di nodi sia quello di pod nel tuo ambiente subiranno automaticamente uno scale up e uno scale down nello stesso modo in cui avviene con questo carico simulato. L'applicazione di esempio Cymbal Bank è progettata per supportare questo tipo di scalabilità. 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à.