Parcours de formation : Applications évolutives - Scaling

Autopilot

Cet ensemble de tutoriels est destiné aux administrateurs et aux opérateurs informatiques qui souhaitent déployer, exécuter et gérer des environnements d'applications modernes exécutés sur Google Kubernetes Engine (GKE). Au fur et à mesure que vous progresserez dans cette série de tutoriels, vous allez apprendre à configurer la surveillance et les alertes, à effectuer le scaling des charges de travail et à simuler des défaillances, le tout en utilisant l'exemple d'application de microservices Cymbal Bank :

Créer un cluster et déployer un exemple d'application
Surveiller avec Google Cloud Managed Service pour Prometheus
Scaling des charges de travail (ce tutoriel)
Simuler une défaillance

Présentation et objectifs

Une application grand public comme Cymbal Bank compte souvent un nombre d'utilisateurs variable à différents moments. Idéalement, votre site Web doit pouvoir faire face aux pics de trafic sans ralentir ni rencontrer d'autres problèmes, et sans que l'organisation ait à investir dans les ressources cloud dont elle n'a pas besoin. L'autoscaling est une solution fournie par Google Cloud à cet effet.

Dans ce tutoriel, vous allez apprendre à configurer des clusters et des charges de travail dans un cluster GKE pour les faire évoluer à l'aide de métriques Kubernetes intégrées et des métriques personnalisées de Cloud Monitoring et Cloud Trace. Vous allez apprendre à effectuer les tâches suivantes :

Activer les métriques personnalisées dans Cloud Monitoring pour Trace.
- Les métriques personnalisées vous permettent d'ajuster les ressources de votre cluster Kubernetes à l'aide de données de surveillance supplémentaires ou d'entrées externes, comme le trafic réseau ou les codes de réponse HTTP, au-delà des connaissances du cluster Kubernetes.
Configurer l'autoscaler horizontal des pods, une fonctionnalité GKE qui peut augmenter ou diminuer automatiquement le nombre de pods pour une charge de travail en fonction des métriques spécifiées.
Simuler la charge d'une application et observer la réponse de l'autoscaler de cluster et de l'autoscaler horizontal des pods.

Coûts

L'activation de GKE et le déploiement de l'exemple d'application Cymbal Bank pour cette série de tutoriels entraînent des frais par cluster pour GKE sur Google Cloud, comme indiqué sur notre Page des tarifs, jusqu'à ce que vous désactiviez GKE ou que vous supprimiez le projet.

Vous êtes également responsable des autres coûts Google Cloud engendrés par l'exécution de l'exemple d'application Cymbal Bank, tels que les frais pour les VM Compute Engine et Trace.

Avant de commencer

Pour apprendre à effectuer le scaling de vos déploiements, vous devez suivre le premier tutoriel pour créer un cluster GKE qui utilise Autopilot et déployer l'exemple d'application basée sur des microservices Cymbal Bank.

Nous vous recommandons de suivre cette série de tutoriels pour les applications évolutives dans l'ordre. Au fil de votre progression dans les tutoriels, vous apprendrez de nouvelles compétences et utilisez d'autres produits et services Google Cloud.

Vous devez également créer un compte de service IAM et accorder certaines autorisations pour que l'autoscaler horizontal des pods fonctionne correctement :

Créer un compte de service IAM Ce compte de service est utilisé dans le tutoriel pour accorder l'accès aux métriques personnalisées qui permettent à l'autoscaler horizontal des pods de déterminer quand effectuer un scaling à la hausse ou à la baisse :
```
gcloud iam service-accounts create scalable-apps
```

Accordez un accès au compte de service IAM pour effectuer les actions de scaling requises :

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]"

L'accès suivant est accordé au compte de service IAM :

roles/cloudtrace.agent : écrit des données de trace, telles que des informations de latence, dans Trace.
roles/monitoring.metricWriter : écrit des métriques dans Cloud Monitoring.
roles/iam.workloadIdentityUser : autorise un compte de service Kubernetes à utiliser la fédération d'identité de charge de travail pour GKE pour agir en tant que compte de service IAM.

Configurez le compte de service Kubernetes default dans l'espace de noms default pour qu'il agisse en tant que compte de service IAM que vous avez créé :
```
kubectl annotate serviceaccount default \
    iam.gke.io/gcp-service-account=scalable-apps@PROJECT_ID.iam.gserviceaccount.com
```
Cette configuration permet aux pods qui utilisent le compte de service Kubernetes default dans l'espace de noms default d'accéder aux mêmes ressources Google Cloud que le compte de service IAM.

Configurer la collecte de métriques personnalisées

Vous pouvez configurer l'autoscaler horizontal des pods pour qu'il utilise des métriques Kubernetes intégrées de base pour le processeur et la mémoire, ou vous pouvez utiliser des métriques personnalisées de Cloud Monitoring, telles que le nombre de requêtes HTTP par seconde ou la quantité d'instructions SELECT. Les métriques personnalisées peuvent fonctionner sans modification de l'application et fournir à votre cluster plus d'informations sur les performances globales et les besoins de l'application. Dans ce tutoriel, vous allez apprendre à utiliser les métriques intégrées et personnalisées.

Pour autoriser l'autoscaler horizontal des pods à lire des métriques personnalisées à partir de Monitoring, vous devez installer l'adaptateur Métriques personnalisées - Adaptateur Stackdriver dans votre cluster.

Déployez l'adaptateur de métriques personnalisées Stackdriver sur votre cluster :
```
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter.yaml
```
Pour autoriser l'adaptateur Stackdriver à obtenir des métriques personnalisées à partir de votre cluster, vous devez utiliser la fédération d'identité de charge de travail pour GKE. Cette approche utilise un compte de service IAM autorisé à lire les métriques de surveillance.

Attribuez au compte de service IAM le rôle roles/monitoring.viewer :
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:scalable-apps@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/monitoring.viewer
```

Configurez l'adaptateur Stackdriver pour utiliser la fédération d'identité de charge de travail pour GKE et le compte de service IAM autorisé à lire les métriques de surveillance :

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 inclut son propre système de comptes de service pour l'accès au sein d'un cluster. Pour permettre à vos applications de s'authentifier auprès de services et de ressources en dehors de vos clusters Google Kubernetes Engine, tels que Monitoring, vous devez utiliser la fédération d'identité de charge de travail pour GKE. Cette approche configure le compte de service Kubernetes pour qu'il utilise le compte de service IAM pour GKE.

Annotez le compte de service Kubernetes utilisé par l'adaptateur :
```
kubectl annotate serviceaccount custom-metrics-stackdriver-adapter \
    --namespace=custom-metrics \
    iam.gke.io/gcp-service-account=scalable-apps@PROJECT_ID.iam.gserviceaccount.com
```

Redémarrez le déploiement de l'adaptateur Stackdriver pour appliquer les modifications :

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

Configurer l'autoscaler horizontal des pods

Le scaling de GKE Autopilot peut être réalisé de plusieurs manières. Dans ce tutoriel, vous allez voir comment votre cluster peut évoluer à l'aide des méthodes suivantes :

Autoscaler horizontal des pods : ajuste le nombre de pods pour une charge de travail.
Autoscaler de cluster : ajuste les ressources de nœuds disponibles dans le cluster.

Ces deux méthodes peuvent fonctionner ensemble, de sorte que lorsque le nombre de pods de vos applications change, les ressources de nœuds nécessaires à leur prise en charge changent également.

D'autres implémentations sont disponibles pour procéder au scaling des pods en s'appuyant sur l'autoscaler horizontal de pods. Vous pouvez également utiliser l'autoscaler vertical des pods pour ajuster les demandes de ressources de processeur et de mémoire au lieu du nombre de pods.

Dans ce tutoriel, vous allez configurer l'autoscaler horizontal des pods à l'aide de métriques intégrées pour le déploiement userservice et à l'aide de métriques personnalisées pour le déploiement frontend.

Pour vos propres applications, collaborez avec vos développeurs d'applications et vos ingénieurs de plate-forme pour comprendre leurs besoins et configurer les règles de l'autoscaler horizontal des pods.

Scaling du déploiement `userservice`

Lorsque le nombre d'utilisateurs de l'exemple d'application Cymbal Bank augmente, le service userservice consomme davantage de ressources de processeur. L'objet HorizontalPodAutoscaler permet de contrôler la manière dont votre application doit répondre à la charge. Dans le fichier manifeste YAML de HorizontalPodAutoscaler, vous définissez le déploiement auquel l'autoscaler horizontal des pods doit s'adapter, les métriques à surveiller, et le nombre minimal et maximal d'instances répliquées que vous souhaitez exécuter.

Examinez l'exemple de fichier manifeste HorizontalPodAutoscaler pour le déploiement 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

Ce fichier manifeste effectue les opérations suivantes :

Définit le nombre maximal d'instances répliquées pendant un scaling à la hausse sur 50.
Définit le nombre minimal d'instances dupliquées pendant un scaling à la baisse sur 5.
Utilise une métrique Kubernetes intégrée pour prendre des décisions de scaling. Dans cet exemple, la métrique correspond à l'utilisation du processeur, et l'utilisation cible est de 60%, ce qui évite une surutilisation et une sous-utilisation.

Appliquez le fichier manifeste au cluster :

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

Scaling du déploiement `frontend`

Dans la section précédente, vous avez configuré l'autoscaler horizontal des pods sur le déploiement userservice en fonction des métriques Kubernetes intégrées pour l'utilisation du processeur. Pour le déploiement frontend, vous voudrez peut-être que le scaling soit réalisé en fonction du nombre de requêtes HTTP entrantes. Cette approche utilise l'adaptateur Stackdriver afin de lire les métriques personnalisées de Monitoring pour l'objet Ingress de l'équilibreur de charge HTTP(S).

Examinez le fichier manifeste HorizontalPodAutoscaler pour le déploiement 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"

Ce fichier manifeste utilise les champs suivants :

spec.scaleTargetRef : ressource Kubernetes à mettre à l'échelle.
spec.minReplicas : nombre minimal d'instances dupliquées, soit 5 dans cet exemple.
spec.maxReplicas : nombre maximal d'instances dupliquées, soit 25 dans cet exemple.
spec.metrics.* : métrique à utiliser. Dans cet exemple, il s'agit du nombre de requêtes HTTP par seconde, qui est une métrique personnalisée de Monitoring fournie par l'adaptateur que vous avez déployé.
spec.metrics.external.metric.selector.matchLabels : libellé de ressource spécifique à filtrer lors du scaling.

Recherchez le nom de la règle de transfert de l'équilibreur de charge d'entrée frontend :

export FW_RULE=$(kubectl get ingress frontend -o=jsonpath='{.metadata.annotations.ingress\.kubernetes\.io/forwarding-rule}')
echo $FW_RULE

Le résultat ressemble à ce qui suit :

k8s2-fr-j76hrtv4-default-frontend-wvvf7381

Ajoutez votre règle de transfert au fichier manifeste :
```
sed -i "s/FORWARDING_RULE_NAME/$FW_RULE/g" "extras/postgres-hpa/hpa/frontend.yaml"
```
Cette commande remplace FORWARDING_RULE_NAME par votre règle de transfert enregistrée.

Appliquez le fichier manifeste au cluster :

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

Simuler la charge

Dans cette section, vous allez utiliser un générateur de charge pour simuler des pics de trafic et observer l'adaptation du nombre d'instances répliquées et de nœuds en réponse à l'augmentation de la charge au fil du temps. Vous pourrez ensuite arrêter de générer du trafic et observer la réduction du nombre d'instances répliquées et de nœuds en réponse à cette diminution de charge.

Avant de commencer, vérifiez l'état de l'autoscaler horizontal des pods et examinez le nombre d'instances répliquées utilisées.

Obtenez l'état de vos ressources HorizontalPodAutoscaler :

kubectl get hpa

Le résultat ressemble à ce qui suit, qui indique qu'il existe une instance répliquée frontend et cinq instances répliquées 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'exemple d'application Cymbal Bank inclut un service loadgenerator. Ce service envoie en continu des requêtes imitant des utilisateurs à l'interface, crée régulièrement de nouveaux comptes et simule des transactions entre eux.

Exposez l'interface Web loadgenerator localement. Cette interface permet de simuler la charge sur l'exemple d'application Cymbal Bank :
```
kubectl port-forward svc/loadgenerator 8080
```
Si un message d'erreur s'affiche, réessayez lorsque le pod est en cours d'exécution.
Sur votre ordinateur, ouvrez l'interface Web du générateur de charge dans un navigateur :
- Si vous utilisez un shell local, ouvrez un navigateur et accédez à l'adresse http://127.0.0.1:8080.
- Si vous utilisez Cloud Shell, cliquez sur Aperçu Web, puis sur Prévisualiser sur le port 8080.
Dans l'interface Web du générateur de charge, si la valeur d'Échecs indique 100%, procédez comme suit pour mettre à jour les paramètres de test :
1. Cliquez sur le bouton Arrêter à côté du compteur du taux d'échecs.
2. Sous État, cliquez sur l'option Nouveau test.
3. Remplacez la valeur de Hôte par l'adresse IP de votre entrée Cymbal Bank.
4. Cliquez sur Start swarming (Démarrer le travail en essaim).
Dans l'interface Web du générateur de charge, cliquez sur l'onglet Graphiques pour observer les performances au fil du temps. Examinez le nombre de requêtes et l'utilisation des ressources.
Ouvrez une nouvelle fenêtre de terminal et surveillez le nombre d'instances répliquées de vos pods frontend et userservice :
```
kubectl get hpa -w
```
Le nombre d'instances répliquées augmente à mesure que la charge augmente. Les actions du scaling à la hausse peuvent prendre environ dix minutes, le temps que le cluster reconnaisse que les métriques configurées ont atteint le seuil défini et qu'il utilise l'autoscaler horizontal des pods pour augmenter le nombre de pods.

L'exemple de résultat suivant montre que le nombre d'instances répliquées a augmenté à mesure que le générateur de charge s'exécute :
```
NAME                     REFERENCE                            TARGETS          MINPODS   MAXPODS   REPLICAS
frontend                 Deployment/frontend                  5200m/5 (avg)    5         25        13
userservice              Deployment/userservice               71%/60%          5         50        17
```
Ouvrez une autre fenêtre de terminal et vérifiez le nombre de nœuds dans le cluster :
```
gcloud container clusters list \
    --filter='name=scalable-apps' \
    --format='table(name, currentMasterVersion, currentNodeVersion, currentNodeCount)' \
    --region="REGION"
```
Remplacez REGION par la région dans laquelle votre cluster s'exécute.

Le nombre de nœuds a également augmenté par rapport au nombre initial afin de s'adapter aux nouvelles instances répliquées. Cette augmentation du nombre de nœuds est assurée par GKE Autopilot. Vous n'avez rien à configurer pour le scaling de ces nœuds.
Ouvrez l'interface du générateur de charge et cliquez sur Arrêter pour mettre fin au test.
Vérifiez à nouveau le nombre d'instances répliquées et le nombre de nœuds, et observez-les à mesure que les nombres diminuent avec la charge réduite. Le scaling à la baisse peut prendre un certain temps, car l'intervalle de stabilisation par défaut pour les instances répliquées dans la ressource HorizontalPodAutoscaler de Kubernetes est de cinq minutes.

Dans un environnement réel, le nombre de nœuds et de pods de votre environnement évolue automatiquement à la hausse ou à la baisse de la même manière qu'avec cette charge simulée. L'exemple d'application Cymbal Bank est conçu pour s'adapter à ce type de scaling. Contactez vos opérateurs d'application et vos ingénieurs en fiabilité des sites (SRE) ou vos développeurs d'applications pour savoir si leurs charges de travail peuvent tirer avantage de ces fonctionnalités de scaling.

Effectuer un nettoyage

L'ensemble de tutoriels pour Cymbal Bank est conçu pour être suivi les uns après les autres. Au fil de votre progression dans les tutoriels, vous apprendrez de nouvelles compétences et utilisez d'autres produits et services Google Cloud.

Si vous souhaitez faire une pause avant de passer au tutoriel suivant et éviter que des frais ne soient facturés sur votre compte Google Cloud pour les ressources utilisées dans ce tutoriel, supprimez le projet que vous avez créé.

Attention : La suppression d'un projet entraîne les effets décrits ci-dessous :

Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour les tâches décrites dans ce document et que vous le supprimez, vous supprimerez également tout autre travail effectué dans le projet.
Les ID de projets personnalisés sont perdus. Lorsque vous avez créé ce projet, vous avez peut-être créé un ID de projet personnalisé que vous souhaitez utiliser à l'avenir. Pour conserver les URL qui utilisent l'ID de projet, telle qu'une URL appspot.com, supprimez les ressources sélectionnées dans le projet au lieu de supprimer l'ensemble du projet.

Si vous envisagez d'explorer plusieurs architectures, tutoriels et guides de démarrage rapide, réutiliser des projets peut vous aider à ne pas dépasser les limites de quotas des projets.

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.

Étape suivante

Découvrez comment simuler une défaillance dans GKE dans le tutoriel suivant.