Utiliser la fonctionnalité de préchauffage ASM - Alibaba Cloud Service Mesh

Utilisez la fonctionnalité de préchauffage ASM lors de la mise à l'échelle horizontale (scale-out) de votre application, du déploiement d'une nouvelle version ou lorsque vous anticipez un pic de trafic. Cette fonctionnalité augmente progressivement le trafic des requêtes vers les nouvelles instances sur une période personnalisée. Ce processus garantit une transition fluide et réduit les risques d'interruptions de service, de délais d'attente des requêtes et de perte de données dus à des pics de trafic soudains. Elle permet de maintenir des performances stables et une haute disponibilité lors de la mise à l'échelle et des mises à jour des applications.

Prérequis

Vous avez créé une instance ASM Enterprise Edition ou ASM Ultimate Edition de version 1.14.3 ou ultérieure. Pour plus d'informations, consultez Créer une instance ASM.
Le cluster est ajouté à l'instance ASM.
Vous êtes connecté à un cluster Container Service for Kubernetes (ACK) via kubectl. Pour plus d'informations, consultez Obtenir le fichier kubeconfig d'un cluster et utiliser kubectl pour se connecter au cluster.
Vous avez créé une passerelle d'entrée ASM. Pour plus d'informations, consultez Créer un service de passerelle d'entrée.
Vous avez déployé l'exemple d'application Bookinfo. Cette rubrique utilise le service Reviews comme exemple. Pour plus d'informations, consultez Déployer une application dans un cluster associé à une instance ASM.

Contexte

Sans la fonctionnalité de préchauffage, les nouveaux pods reçoivent immédiatement leur part complète de trafic, sans augmentation progressive. Cela peut poser problème pour les services nécessitant une période de préchauffage pour fonctionner de manière optimale, tels que les applications basées sur JVM qui doivent effectuer une compilation Just-In-Time (JIT) ou remplir de grands caches. Cette charge soudaine peut entraîner des délais d'attente des requêtes, une perte de données et une dégradation de l'expérience utilisateur. La fonctionnalité de préchauffage résout ce problème en introduisant progressivement le trafic vers les nouvelles instances, leur permettant ainsi de se préparer à traiter les requêtes à pleine capacité.

Fonctionnalité de préchauffage

La fonctionnalité de préchauffage, également appelée démarrage progressif ou augmentation progressive du trafic, vous permet de configurer une période pour un service. Lorsqu'une instance de service démarre, le client envoie une fraction de la charge de requêtes à cette instance et augmente progressivement le taux de requêtes sur la durée configurée. Une fois la période de préchauffage terminée, l'instance commence à recevoir sa part complète de trafic.

En mode démarrage progressif, les nouveaux pods sont protégés contre une saturation soudaine par un afflux massif de requêtes. Cela permet aux nouvelles instances de se préchauffer pendant une période de montée en charge avant de recevoir leur part complète de trafic.

La fonctionnalité de préchauffage est utile pour les applications qui s'appuient sur la mise en cache et nécessitent une période de préchauffage pour répondre aux requêtes avec des performances optimales. Dans ASM, il vous suffit de configurer la section trafficPolicy/loadBalancer de la DestinationRule correspondante pour le service. Tenez compte des paramètres suivants :

loadBalancer : spécifie les paramètres de l'équilibreur de charge. Cette fonctionnalité prend uniquement en charge les équilibreurs de charge ROUND_ROBIN et LEAST_REQUEST.
warmupDurationSecs : spécifie la durée de préchauffage pour le service. Si ce paramètre est défini, un point de terminaison de service nouvellement créé reste en mode préchauffage pendant cette durée, à compter de son heure de création. Durant cette fenêtre, Istio augmente progressivement le trafic vers le point de terminaison au lieu d'envoyer immédiatement une part proportionnelle du trafic.

Remarque

La fonctionnalité de préchauffage nécessite que le nombre de réplicas d'application dans la zone de disponibilité actuelle ne soit pas nul. Par exemple :

Si le cluster du plan de données ne possède qu'une seule zone de disponibilité, la Zone A, et qu'il y a actuellement un seul réplica dans cette zone, la fonctionnalité de préchauffage prend effet lorsqu'un deuxième réplica est démarré.
Si le cluster du plan de données dispose de deux zones de disponibilité, la Zone A et la Zone B, et que le seul réplica existant se trouve dans la Zone A, le démarrage d'un deuxième réplica dans la Zone B ne déclenchera pas la fonctionnalité de préchauffage. Cela peut se produire car certains planificateurs distribuent les réplicas entre les zones de disponibilité par défaut. Dans ce scénario, la fonctionnalité de préchauffage prendra effet lorsqu'un troisième réplica sera démarré.

Voici un exemple de DestinationRule au format YAML :

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: mocka
spec:
  host: mocka
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
      warmupDurationSecs: 100s

Étape 1 : Configurer le routage et accéder à la passerelle

Pour illustrer cela, réduisez à 0 le nombre de réplicas du déploiement reviews-v3.

Définissez les ressources d'entrée.

Créez un fichier nommé bookinfo-gateway.yaml avec le contenu suivant.

bookinfo-gateway.yaml

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: bookinfo
spec:
  gateways:
    - bookinfo-gateway
  hosts:
    - '*'
  http:
    - match:
      - uri:
          exact: /productpage
      - uri:
          prefix: /static
      - uri:
          exact: /login
      - uri:
          exact: /logout
      - uri:
          prefix: /api/v1/products
      route:
        - destination:
            host: productpage
            port:
              number: 9080
    - match:
      - uri:
          prefix: /reviews
      route:
        - destination:
            host: reviews
            port:
              number: 9080

Exécutez la commande suivante pour déployer la passerelle et le service virtuel.
```
kubectl apply -f bookinfo-gateway.yaml
```

Créez la DestinationRule pour le service Reviews.

Créez un fichier nommé reviews.yaml avec le contenu suivant.

reviews.yaml

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN

Exécutez la commande suivante pour déployer la DestinationRule.
```
kubectl apply -f reviews.yaml
```

Activez la topologie du maillage et accédez continuellement à l'adresse de la passerelle d'entrée.

Cette rubrique utilise la commande hey pour envoyer des requêtes de test de charge pendant 10 secondes. Pour savoir comment télécharger et installer hey, consultez hey. Pour plus d'informations sur l'activation et l'affichage de la topologie du maillage, consultez Afficher la topologie du maillage d'une application.
```
hey -z 10s -q 100 -c 4 http://${INGRESS_GATEWAY_ADDRESS}/reviews/0
```
La figure suivante illustre un exemple de topologie d'appel :

Étape 2 : Observer le démarrage des pods

Connectez-vous à la console ASM.
Dans le volet de navigation de gauche, sélectionnez Service Mesh > Mesh Management.
Sur la page Mesh Management, recherchez l'instance ASM que vous souhaitez configurer. Cliquez sur le nom de l'instance ASM ou sur Manage dans la colonne Actions.
Dans le volet de navigation de gauche, sélectionnez Observability Management Center > Monitoring metrics.
- Pour les instances ASM antérieures à la version 1.17.2.35 : Sur la page Monitoring metrics, cliquez sur l'onglet Monitoring instrument, puis sur l'onglet Cloud ASM Istio Service et sélectionnez le service Reviews.
- Pour les instances ASM de version 1.17.2.35 et ultérieures : Sur la page Monitoring metrics, cliquez sur l'onglet Cloud ASM Istio Work load, sélectionnez la charge de travail reviews-v3 et définissez Reporter sur source.
Envoyez des requêtes de test de charge et observez les données de surveillance.
1. Avec la fonctionnalité de préchauffage désactivée, augmentez le nombre de réplicas du déploiement reviews-v3 de 0 à 1.
2. Exécutez la commande suivante pour envoyer des requêtes de test de charge à la passerelle d'entrée.
  
  Cet exemple envoie des requêtes de test de charge pendant 120 secondes.
```
hey -z 120s -q 100 -c 4 http://${INGRESS_GATEWAY_ADDRESS}/reviews/0
```
3. Observez les données sur le tableau de bord de surveillance Prometheus.
  
  Il faut environ 45 secondes pour que le pod reviews-v3 reçoive une part équilibrée des requêtes. Le temps réel peut varier selon votre environnement de test de charge.
Réduisez à nouveau à 0 le nombre de réplicas du déploiement reviews-v3.

Étape 3 : Activer la fonctionnalité de préchauffage

Mettez à jour le fichier reviews.yaml avec le contenu suivant.

Ajoutez le champ warmupDurationSecs et définissez-le sur 120s, ce qui définit la durée de préchauffage à 120 secondes.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
      warmupDurationSecs: 120s

Exécutez la commande suivante pour appliquer la mise à jour.
```
kubectl apply -f reviews.yaml
```

Étape 4 : Vérifier l'effet du préchauffage

Après avoir activé la fonctionnalité de préchauffage, augmentez le nombre de réplicas du déploiement reviews-v3 de 0 à 1.
Exécutez la commande suivante pour envoyer des requêtes de test de charge à la passerelle d'entrée.

Cet exemple envoie des requêtes de test de charge pendant 150 secondes.
```
hey -z 150s -q 100 -c 4 http://${INGRESS_GATEWAY_ADDRESS}/reviews/0
```
Sur l'onglet Cloud ASM Istio Service, observez les données sur le tableau de bord de surveillance Prometheus.

Il faut environ 120 secondes pour que le pod reviews-v3 reçoive une part équilibrée des requêtes. Le temps réel peut varier selon votre environnement de test de charge. La courbe peut apparaître en escalier car les métriques sont collectées à intervalles réguliers. En réalité, le trafic vers le pod reviews-v3 augmente de manière fluide. Si vous activez la collecte des journaux sidecar, vous pouvez rechercher les journaux de ce sidecar dans Simple Log Service (SLS) pour afficher le volume de journaux sur les 5 dernières minutes. Comme prévu avec la fonctionnalité de préchauffage, une nouvelle instance reçoit initialement une fraction du trafic, qui augmente ensuite progressivement sur la durée configurée jusqu'à recevoir sa part complète.

Après l'activation de la fonctionnalité de préchauffage, il faut environ 2 minutes et 30 secondes pour que le trafic soit réparti uniformément entre les versions v1, v2 et v3. Dans la vue Service Graph de Kiali, istio-ingressgateway répartit le trafic presque uniformément entre les versions v1, v2 et v3 du service Reviews, soit respectivement 33,3 %, 33,3 % et 33,4 %. Les versions v2 et v3 appellent ensuite le service ratings v1, ce qui indique que le trafic est équilibré une fois le préchauffage terminé.

Documentation connexe

Vous pouvez configurer une limitation locale ou globale pour maintenir le trafic dans un seuil gérable, garantissant ainsi la disponibilité du service et des performances stables. Pour plus d'informations, consultez Configurer la limitation locale dans le centre de gestion du trafic et Utiliser ASMGlobalRateLimiter pour configurer la limitation globale du trafic d'entrée d'une application.
ASMAdaptiveConcurrency fournit un contrôle adaptatif de la concurrence en ajustant dynamiquement le nombre autorisé de requêtes simultanées en fonction des données d'échantillonnage des requêtes. Lorsque le nombre de requêtes simultanées dépasse la capacité du service, les requêtes sont rejetées pour protéger le service. Pour plus d'informations, consultez Utiliser ASMAdaptiveConcurrency pour le contrôle adaptatif de la concurrence.
Vous pouvez configurer un pool de connexions pour mettre en œuvre un disjoncteur, protégeant ainsi votre système contre d'autres dommages en cas de panne ou de surcharge. Pour plus d'informations, consultez Configurer un pool de connexions pour le disjoncteur.