How sidecar recommendation optimizes configuration push - Alibaba Cloud Service Mesh

Une ressource Sidecar limite la configuration que le plan de contrôle Alibaba Cloud Service Mesh (ASM) pousse vers chaque Sidecar du plan de données. La fonctionnalité de recommandation de ressources Sidecar minimise cette configuration. Un test réalisé sur un cluster comptant 420 pods analyse l'efficacité du push de configuration avant et après l'application d'une ressource Sidecar recommandée.

Prérequis

Le cluster est ajouté à l'instance ASM.
Vous êtes connecté à un cluster ACK via kubectl. Pour plus d'informations, consultez la rubrique Obtenir le fichier KubeConfig d'un cluster et utiliser kubectl pour se connecter au cluster.
Vous utilisez Log Service pour collecter les journaux d'accès depuis le plan de données. Pour plus d'informations, consultez la rubrique Utiliser Log Service pour collecter les journaux d'accès des clusters du plan de données.
La collecte des journaux du plan de contrôle est activée pour l'instance ASM. Le test mesure l'efficacité du push de configuration du plan de contrôle en analysant le contenu des journaux du plan de contrôle. Pour plus d'informations, consultez la rubrique Activer la collecte des journaux du plan de contrôle et les alertes basées sur les journaux.

Environnement de test

Le test déploie plusieurs applications sleep et httpbin dans un namespace géré par l'instance ASM. Un Sidecar est injecté dans chaque pod de test, et le cluster contient un grand nombre de services avec peu de dépendances d'appel entre eux. Cette rubrique utilise le namespace default, auquel font référence les manifests d'exemple, les commandes et les journaux du plan de contrôle. Pour plus d'informations sur les namespaces dans une instance ASM, consultez la rubrique Gérer les namespaces globaux.

Applications httpbin — Une fois démarrée, l'application httpbin expose un service HTTP sur le port 8000. L'application simule le grand nombre de services appelés au sein du cluster. Le test génère 200 déploiements d'applications httpbin et déploie 400 pods d'applications httpbin dans le cluster.
Applications sleep — L'application sleep contient un conteneur curl. Modifiez le champ command du déploiement de l'application afin que l'application sleep appelle les services fournis par plusieurs conteneurs httpbin avant de passer en veille. L'application simule un service du cluster qui dépend d'autres services. Le test attribue à chaque application sleep une dépendance envers 10 applications httpbin. Par conséquent, 20 déploiements d'applications sleep et 20 pods sleep sont déployés au total.
Échelle du cluster — Un total de 420 pods s'exécute dans le cluster de test.

Déployer les applications de test dans le cluster

Déployez plusieurs applications httpbin dans le cluster.

Utilisez le contenu YAML suivant pour créer un fichier YAML nommé httpbin-{i}.yaml.

Remarque

Dans httpbin-{i}, remplacez {i} par un numéro spécifique pour générer plusieurs services httpbin numérotés. Utilisez ce modèle pour générer n'importe quel nombre d'applications httpbin. Le nombre maximal d'applications dépend de la taille de votre cluster.

Le contenu YAML suivant définit le ServiceAccount, le Service et le Deployment d'une application httpbin numérotée :

apiVersion: v1
kind: ServiceAccount
metadata:
  name: httpbin
  namespace: default
---
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: httpbin-{i}
    service: httpbin-{i}
  name: httpbin-{i}
  namespace: default
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 80
  selector:
    app: httpbin-{i}
---
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: httpbin-{i}
  name: httpbin-{i}
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: httpbin-{i}
      version: v1
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: httpbin-{i}
        version: v1
    spec:
      containers:
      - image: docker.io/kennethreitz/httpbin
        imagePullPolicy: IfNotPresent
        name: httpbin
        ports:
        - containerPort: 80
      serviceAccountName: httpbin

Exécutez la commande suivante pour créer l'application httpbin-{i}.
```
kubectl apply -f httpbin-{i}.yaml -n default
```
Résultat attendu :
```
deployment.apps/httpbin-{i} created
```

Déployez des applications sleep dans le cluster.

Utilisez le contenu YAML suivant pour créer un fichier YAML nommé sleep-{i}.yaml.

Remarque

Dans sleep-{i}, remplacez {i} par un numéro spécifique pour générer plusieurs services sleep numérotés. Dans ce modèle, vous ajoutez le paramètre de commande curl httpbin-{i*10}:8000 au champ args du déploiement de l'application sleep pour simuler des appels vers différentes applications httpbin. Le numéro du service httpbin que vous appelez ne doit pas dépasser le nombre de services httpbin que vous avez déployés précédemment. Sinon, l'appel sera invalide.

Le contenu YAML suivant définit le ServiceAccount, le Service et le Deployment d'une application sleep numérotée :

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sleep
  namespace: default
---
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: sleep-{i}
    service: sleep-{i}
  name: sleep-{i}
  namespace: default
spec:
  ports:
  - name: http
    port: 80
    targetPort: 0
  selector:
    app: sleep-{i}
---
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: sleep-{i}
  name: sleep-{i}
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep-{i}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: sleep-{i}
    spec:
      containers:
      - args:
        - curl httpbin-{i*10}:8000; curl httpbin-{i*10+1}:8000; curl httpbin-{i*10+2}:8000; curl httpbin-{i*10+3}:8000;
          curl httpbin-{i*10+4}:8000; curl httpbin-{i*10+5}:8000; curl httpbin-{i*10+6}:8000; curl httpbin-{i*10+7}:8000;
          curl httpbin-{i*10+8}:8000; curl httpbin-{i*10+9}:8000; sleep 3650d
        command:
        - /bin/sh
        - -c
        image: curlimages/curl
        imagePullPolicy: IfNotPresent
        name: sleep
        volumeMounts:
        - mountPath: /etc/sleep/tls
          name: secret-volume
      serviceAccountName: sleep
      terminationGracePeriodSeconds: 0
      volumes:
      - name: secret-volume
        secret:
          optional: true
          secretName: sleep-secret

Exécutez la commande suivante pour créer l'application sleep-{i}.
```
kubectl apply -f sleep-{i}.yaml -n default
```
Résultat attendu :
```
deployment.apps/sleep-{i} created
```

Tester le push de configuration du plan de contrôle avant l'application d'une ressource Sidecar

Avant d'appliquer une ressource Sidecar, mesurez deux valeurs de référence dans le cluster de test : la taille de la configuration Sidecar dans un seul pod, et le temps nécessaire au plan de contrôle ASM pour effectuer un push de configuration complet.

Taille de la configuration Sidecar avant l'application d'une ressource Sidecar

Exécutez la commande suivante pour identifier le nom du pod de l'application httpbin-0.

kubectl get pod -n default | grep httpbin-0

Résultat attendu :

NAME                         READY   STATUS    RESTARTS   AGE
httpbin-0-756995d867-jljgp   2/2     Running   0          9m15s
httpbin-0-756995d867-whstr   2/2     Running   0          9m15s

Exécutez la commande suivante pour télécharger la configuration Sidecar du pod exécutant l'application httpbin-0 sur votre machine locale. Remplacez httpbin-0-756995d867-jljgp par un nom de pod renvoyé à l'étape précédente.
```
kubectl exec -it httpbin-0-756995d867-jljgp -c istio-proxy -n default -- curl -s localhost:15000/config_dump > config_dump.json
```
Exécutez la commande suivante pour afficher la taille du fichier de configuration Sidecar.
```
du -sh config_dump.json
```
Résultat attendu :
```
1.2M    config_dump.json
```

Le résultat attendu indique que la configuration Sidecar est d'environ 1,2 Mo dans le scénario de test où 420 pods sont déployés dans le cluster. Si un Sidecar est déployé pour chaque pod du cluster, le volume important de configurations Sidecar augmente la charge de push sur le plan de contrôle.

Efficacité du push du plan de contrôle avant l'application d'une ressource Sidecar

Appliquez une nouvelle règle de service virtuel au service httpbin-0 dans ASM pour déclencher un push de configuration du plan de contrôle vers les Sidecars du plan de données. Le contenu des journaux du plan de contrôle montre l'efficacité avec laquelle le plan de contrôle effectue un push unique. La collecte des journaux du plan de contrôle doit déjà être activée, comme décrit dans la section Prérequis.

Utilisez le contenu YAML suivant pour créer un service virtuel dans ASM qui applique une gestion du délai d'expiration au service httpbin-0. Pour plus d'informations sur la création d'un service virtuel, consultez la rubrique Gérer les services virtuels.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-0-timeout
  namespace: default
spec:
  hosts:
    - httpbin-0.default.svc.cluster.local
  http:
    - route:
        - destination:
            host: httpbin-0.default.svc.cluster.local
      timeout: 5s

Consultez les journaux générés par le plan de contrôle. Le chemin de navigation dans la console dépend de la version de votre instance ASM.

Version 1.17.2.35 ou ultérieure de l'instance ASM

Connectez-vous à la console ASM. Dans le volet de navigation de gauche, choisissez Service Mesh > Mesh Management.
Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, choisissez Observability Management Center > Log Center.
Sur la page Log Center, cliquez sur l'onglet Control-Plane Logs pour consulter les journaux.

Version antérieure à 1.17.2.35 de l'instance ASM

Connectez-vous à la console ASM.
Dans le volet de navigation de gauche, choisissez Service Mesh > Mesh Management.
Sur la page Mesh Management, cliquez sur le nom de l'instance cible.
Sur la page des détails du maillage, choisissez Instance Information > Base Information.
Sur la page Basic Information, cliquez sur View log à droite de Control-plane log collection.

L'extrait de code suivant présente des exemples de journaux :

2021-12-01T10:20:09.708673Z info  ads CDS: PUSH for node:httpbin-27-7dd8578b46-nkmvg.default resources:227 size:169.3kB
2021-12-01T10:20:09.710469Z info  ads CDS: PUSH for node:httpbin-184-65d97797db-njst5.default resources:227 size:169.3kB
2021-12-01T10:20:09.713567Z info  ads CDS: PUSH for node:httpbin-86-5b64586bbf-jv92w.default resources:227 size:169.3kB
2021-12-01T10:20:09.714514Z info  ads LDS: PUSH for node:httpbin-86-5b64586bbf-jv92w.default resources:16 size:70.7kB
2021-12-01T10:20:09.792732Z info  ads LDS: PUSH for node:httpbin-27-7dd8578b46-nkmvg.default resources:16 size:70.7kB
2021-12-01T10:20:09.792982Z info  ads LDS: PUSH for node:httpbin-184-65d97797db-njst5.default resources:16 size:70.7kB
2021-12-01T10:20:09.796430Z info  ads RDS: PUSH for node:httpbin-86-5b64586bbf-jv92w.default resources:8 size:137.4kB
...
2021-12-01T10:20:13.405850Z info  ads RDS: PUSH for node:httpbin-156-68b85b4f79-2znmp.default resources:8 size:137.4kB
2021-12-01T10:20:13.406154Z info  ads RDS: PUSH for node:httpbin-121-7c4cff97b9-sn5g4.default resources:8 size:137.4kB
2021-12-01T10:20:13.406420Z info  ads CDS: PUSH for node:httpbin-161-7bc74c5fb5-ldgn4.default resources:227 size:169.3kB
2021-12-01T10:20:13.407230Z info  ads LDS: PUSH for node:httpbin-161-7bc74c5fb5-ldgn4.default resources:16 size:70.7kB
2021-12-01T10:20:13.410147Z info  ads RDS: PUSH for node:httpbin-161-7bc74c5fb5-ldgn4.default resources:8 size:137.4kB
2021-12-01T10:20:13.494840Z info  ads RDS: PUSH for node:httpbin-57-69b756f779-db7vv.default resources:8 size:137.4kB

Dans un environnement de test où 420 pods sont déployés, l'ajout d'un seul service virtuel entraîne le push de cette modification par le plan de contrôle vers chaque Sidecar du plan de données. Cette opération génère un grand nombre de journaux de push et transfère une quantité importante de données à chaque push. L'application d'une règle de service virtuel dans ASM nécessite environ 4 secondes de push par le plan de contrôle, ce qui indique une faible efficacité du push au niveau du plan de contrôle.

Tester le push de configuration du plan de contrôle après l'application d'une ressource Sidecar

Appliquez une ressource Sidecar recommandée dans le même cluster de test, puis répétez les deux mesures afin de comparer les résultats aux valeurs de référence.

Appliquer la ressource Sidecar recommandée

Utilisez la fonctionnalité de recommandation automatique des ressources Sidecar basée sur l'analyse des journaux d'accès pour recommander et appliquer une ressource Sidecar pour chaque charge de travail du cluster de test. Pour plus d'informations, consultez la rubrique Utiliser des ressources Sidecar recommandées automatiquement en fonction de l'analyse des journaux d'accès Optimiser la configuration du proxy sidecar grâce à l'analyse des journaux d'accès.

Taille de la configuration Sidecar après l'application d'une ressource Sidecar

Exécutez la commande suivante pour télécharger la configuration Sidecar du pod exécutant l'application httpbin-0 sur votre machine locale. Remplacez httpbin-0-756995d867-jljgp par le nom d'un pod exécutant actuellement l'application httpbin-0.
```
kubectl exec -it httpbin-0-756995d867-jljgp -c istio-proxy -n default -- curl -s localhost:15000/config_dump > config_dump.json
```
Exécutez la commande suivante pour afficher la taille du fichier de configuration Sidecar.
```
du -sh config_dump.json
```
Sortie attendue :
```
105k    config_dump.json
```

La sortie attendue montre que, dans un scénario où 420 pods sont déployés dans le cluster, la fonctionnalité de recommandation automatique des ressources Sidecar basée sur l'analyse des journaux d'accès réduit la configuration Sidecar de plus de 10 fois, soit à 105 Ko. Cela améliore considérablement l'efficacité des pushes de configuration du plan de contrôle vers les Sidecars du plan de données.

Efficacité du push du plan de contrôle après l'application d'une ressource Sidecar

Appliquez à nouveau une nouvelle règle de service virtuel au service httpbin-0 dans ASM pour déclencher un push de configuration du plan de contrôle vers les Sidecars du plan de données.

Supprimez le service virtuel httpbin-0-timeout que vous avez créé dans ASM avant l'optimisation. Créez ensuite à nouveau le service virtuel en utilisant le même contenu YAML que dans la section Efficacité du push du plan de contrôle avant l'application d'une ressource Sidecar Efficacité du push du plan de contrôle avant l'application d'une ressource Sidecar, afin que le plan de contrôle effectue un push de configuration supplémentaire pour le service httpbin-0. Pour plus d'informations sur la création d'un service virtuel, consultez la rubrique Gérer les services virtuels Gérer les services virtuels.
Consultez les journaux générés par le plan de contrôle. Le chemin de navigation dans la console dépend de la version de votre instance ASM.
Version 1.17.2.35 ou ultérieure de l'instance ASM
1. Connectez-vous à la console ASM. Dans le volet de navigation de gauche, choisissez Service Mesh > Mesh Management.
2. Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, choisissez Observability Management Center > Log Center.
3. Sur la page Log Center, cliquez sur l'onglet Control-Plane Logs pour consulter les journaux.
Version antérieure à 1.17.2.35 de l'instance ASM
1. Connectez-vous à la console ASM.
2. Dans le volet de navigation de gauche, choisissez Service Mesh > Mesh Management.
3. Sur la page Mesh Management, cliquez sur le nom de l'instance cible.
4. Sur la page des détails du maillage, choisissez Instance Information > Base Information.
5. Sur la page Basic Information, cliquez sur View log à droite de Control-plane log collection.
L'extrait de code suivant présente des exemples de journaux :
```
2021-12-01T12:12:43.498048Z info  ads Push debounce stable[750] 1: 100.03379ms since last change, 100.033692ms since last push, full=true
2021-12-01T12:12:43.504270Z info  ads XDS: Pushing:2021-12-01T12:12:43Z/493 Services:230 ConnectedEndpoints:421  Version:2021-12-01T12:12:43Z/493
2021-12-01T12:12:43.507451Z info  ads CDS: PUSH for node:sleep-0-b68c8c5d9-5kww5.default resources:14 size:7.8kB
2021-12-01T12:12:43.507739Z info  ads LDS: PUSH for node:sleep-0-b68c8c5d9-5kww5.default resources:3 size:15.5kB
2021-12-01T12:12:43.508029Z info  ads RDS: PUSH for node:sleep-0-b68c8c5d9-5kww5.default resources:1 size:6.3kB
```

Après l'application de la ressource Sidecar recommandée par ASM, chaque charge de travail du plan de données ne reçoit plus les modifications liées aux services dont elle ne dépend pas. Lorsqu'une règle de service virtuel est appliquée au service httpbin-0, le plan de contrôle pousse la modification de configuration uniquement vers le Sidecar du pod de l'application sleep-0, car seule l'application sleep-0 dépend du service httpbin-0. Le push de configuration déclenché par la règle de service virtuel ne dure qu'environ 0,01 seconde, soit environ 400 fois plus rapide qu'avant l'optimisation. Le volume de données de la modification est également réduit d'un facteur d'environ 10. Cela améliore considérablement l'efficacité des pushes de configuration du plan de contrôle vers le plan de données.

Résumé de la comparaison

Le tableau suivant compare les valeurs mesurées dans cet environnement de test avant et après l'application d'une ressource Sidecar recommandée.

Métrique

Sans optimisation de la ressource Sidecar

Avec optimisation de la ressource Sidecar

Taille de la configuration Sidecar

1,2 Mo

105 Ko

Pushes vers les services sans dépendances

Oui

Non

Durée du push de configuration du plan de contrôle

Environ 4 secondes

Environ 0,01 seconde