Alibaba Cloud Service Mesh:Configure sidecar proxies

Description des paramètres

Ce paramètre calcule automatiquement les ressources sidecar en fonction des conteneurs d'application. L'activation de ce paramètre remplace les Paramètres de ressource pour les proxies Istio injectés. Cette fonctionnalité alloue des ressources aux sidecars en fonction de la configuration de ressources maximale des conteneurs d'application, ce qui permet d'ajuster dynamiquement les ressources sidecar pour différents Pods. Les stratégies de calcul suivantes sont prises en charge :

• Ressources maximales du conteneur : le système parcourt tous les conteneurs du Pod et utilise la valeur de ressource la plus élevée comme base de calcul.

• Nom de conteneur spécifié : le système utilise les ressources du conteneur portant le nom spécifié dans le Pod comme base de calcul. Pour utiliser cette stratégie, vous devez spécifier un conteneur comme base de calcul. Si le conteneur spécifié n'est pas trouvé dans le Pod, les ressources sidecar configurées dans Paramètres de ressource pour les proxies Istio injectés sont utilisées. De plus, si le Pod contient l'annotation scaled-resource.inject.istio.alibabacloud.com/container-ref, le conteneur défini dans l'annotation est prioritaire comme base de calcul.

Exemple de configuration

Les exemples suivants montrent les effets réels de différents pourcentages de ressources dans différents scénarios. La configuration du conteneur d'exemple est la suivante :

resources:
  requests:
    cpu: 300m
    memory: 512Mi
  limits:
    cpu: 500m
    memory: 1Gi

resources:
  limits:
    cpu: 500m
    memory: 1Gi

resources:
  requests:
    cpu: 300m
    memory: 512Mi

1. Sur la page Configure the agent parameters of the injected Sidecar, cliquez sur l'onglet correspondant au niveau de configuration du proxy sidecar cible, puis cliquez sur Resource Settings.

2. Dans la section Resource Settings, sélectionnez Configure sidecar resources by ratio.

3. Configurez Proportion of Resources, sélectionnez la Computing Policy (facultatif), puis cliquez sur Update Settings.

   Sélectionnez la stratégie de calcul Maximum Resource Capacity ou Specify a container name. selon vos besoins.

4. Redéployez la charge de travail pour appliquer la configuration du proxy sidecar.

5. Consultez les ressources du proxy Istio que vous avez configurées.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Sortie attendue :

   Configuration d'application normale

   Configuration normale Si le pourcentage de ressources est défini sur 50, ce qui signifie que le sidecar obtient 50 % des ressources configurées pour le conteneur d'application, l'allocation finale des ressources sidecar est la suivante : ... resources: requests: cpu: 150m memory: 256Mi limits: cpu: 250m memory: 512Mi

   Configuration minimale Si le pourcentage de ressources est défini sur 20, ce qui signifie que le sidecar obtient 20 % des ressources configurées pour le conteneur d'application, l'allocation finale des ressources sidecar est la suivante : ... resources: requests: cpu: 100m memory: 128Mi limits: cpu: 100m memory: 204Mi

   Aucune requests configurée

   Si le pourcentage de ressources est défini sur 50, ce qui signifie que le sidecar obtient 50 % des ressources configurées pour le conteneur d'application, l'allocation finale des ressources sidecar est la suivante :

   ...
   resources:
     requests:
       cpu: 100m
       memory: 128Mi
     limits:
       cpu: 250m
       memory: 512Mi

   Aucune limits configurée

   Si le pourcentage de ressources est défini sur 50, ce qui signifie que le sidecar obtient 50 % des ressources configurées pour le conteneur d'application, l'allocation finale des ressources sidecar est la suivante :

   ...
   resources:
     requests:
       cpu: 150m
       memory: 256Mi

Description des paramètres

Ce paramètre spécifie les ressources minimales en CPU et en mémoire dont le conteneur istio-init a besoin lors de l'exécution, ainsi que les ressources maximales en CPU et en mémoire que le conteneur peut demander dans les Pods où des proxys sidecar sont injectés. Le conteneur istio-init est un conteneur d'initialisation qui s'exécute au démarrage d'un Pod disposant d'un proxy sidecar injecté. Il configure les règles de routage pour l'interception du trafic destinées au conteneur du proxy sidecar.

Exemple de configuration

1. Sur la page Configure the agent parameters of the injected Sidecar, cliquez sur l'onglet correspondant au niveau de configuration du proxy sidecar cible, puis cliquez sur Resource Settings.

2. (Facultatif) Dans la section Resource Settings, sélectionnez Configure Resources for istio-init Container.

   Cette étape est requise dans les onglets Namespace et workload. Vous pouvez ignorer cette étape dans l'onglet global.

3. Pour Limits on Resources, définissez CPU sur 1 cœur et Memory sur 512 MiB. Pour Required Resources, définissez CPU sur 0,1 cœur et Memory sur 128 MiB. Ensuite, cliquez sur Update Settings en bas de la page.

4. Redéployez la charge de travail pour appliquer la configuration du proxy sidecar.

5. Consultez les ressources du conteneur d'initialisation istio-init que vous avez configurées.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Résultat attendu :

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
   ...
         name: istio-init
         resources:
           limits:
             cpu: '1'
             memory: 512Mi
           requests:
             cpu: 100m
             memory: 128Mi
   ...

   Si le champ resources du conteneur d'initialisation nommé istio-init dans le Pod est défini sur les valeurs de ressources cibles, la configuration Configure Resources for istio-init Container a pris effet.

Description des paramètres

Ce paramètre spécifie les ressources ACK à survente dynamique allouées au proxy Istio injecté et au conteneur d'initialisation istio-init. Pour plus d'informations sur les ressources à survente dynamique, consultez la rubrique Activer la surallocation dynamique des ressources.

Ce paramètre se configure de la même manière que les Paramètres de ressources pour les proxys Istio injectés et les Paramètres de ressources pour le conteneur d'initialisation istio-init. Après la configuration, si un Pod possède le libellé ACK de survente dynamique des ressources label koordinator.sh/qosClass, des ressources ACK à survente dynamique sont allouées au proxy Istio et au conteneur d'initialisation istio-init dans le Pod, au lieu des ressources CPU et mémoire Kubernetes standard.

Exemple de configuration

1. Sur la page Configure the agent parameters of the injected Sidecar, cliquez sur l'onglet correspondant au niveau de configuration du proxy sidecar cible, cliquez sur Resource Settings, sélectionnez Set ACK Resources That Can Be Dynamically Overcommitted for Sidecar Proxy, configurez les paramètres associés, puis cliquez sur Update Settings en bas de la page.

   Paramètre	Sous-paramètre	Description
   Configure Resources for Injected Sidecar Proxy (ACK Dynamically Overcommitted Resources)	Limits on Resources	Définissez CPU sur 2000 millicœurs et Memory sur 2048 MiB.
   	Required Resources	Définissez CPU sur 200 millicœurs et Memory sur 256 MiB.
   istio-init container resource (ACK dynamic oversold resource)	Limits on Resources	Définissez CPU sur 1000 millicœurs et Memory sur 1024 MiB.
   	Required Resources	Définissez CPU sur 100 millicœurs et Memory sur 128 MiB.

2. Redéployez la charge de travail pour appliquer la configuration du proxy sidecar.

3. Exécutez la commande suivante pour consulter les ressources du conteneur d'initialisation istio-init que vous avez configurées.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Résultat attendu :

   apiVersion: v1
   kind: Pod
   metadata:
   ...
     labels:
       koordinator.sh/qosClass: BE
   spec:
     containers:
       - args:
   ...
         name: istio-proxy
   ...
         resources:
           limits:
             kubernetes.io/batch-cpu: 2k
             kubernetes.io/batch-memory: 2Gi
           requests:
             kubernetes.io/batch-cpu: '200'
             kubernetes.io/batch-memory: 256Mi
   ...
     initContainers:
       - args:
   ...
         name: istio-init
         resources:
           limits:
             kubernetes.io/batch-cpu: 1k
             kubernetes.io/batch-memory: 1Gi
           requests:
             kubernetes.io/batch-cpu: '100'
             kubernetes.io/batch-memory: 128Mi
   ...

   Le conteneur istio-proxy (conteneur du proxy Istio) et le conteneur d'initialisation istio-init dans le Pod contiennent tous deux le champ resources défini sur les valeurs de ressources cibles. Cela indique que la configuration Set ACK Resources That Can Be Dynamically Overcommitted for Sidecar Proxy a pris effet.

Description du paramètre

Ce paramètre spécifie le nombre de threads de travail du conteneur proxy sidecar. Vous devez indiquer un entier non négatif pour définir ce nombre. Si vous définissez ce paramètre sur 0, le nombre de threads de travail est déterminé automatiquement en fonction des ressources CPU demandées ou de la limite de ressources CPU configurée pour le proxy sidecar. La limite de ressources est prioritaire sur les ressources demandées.

Exemple de configuration

1. Sur la page Configure the agent parameters of the injected Sidecar, cliquez sur l'onglet correspondant au niveau de configuration du proxy sidecar cible, puis cliquez sur Resource Settings.

2. (Facultatif) Dans la section Resource Settings, sélectionnez Number of Sidecar Proxy Threads.

   Cette étape est requise dans les onglets Namespace et workload. Vous pouvez ignorer cette étape dans l'onglet global.

3. Définissez Number of Sidecar Proxy Threads sur 3, puis cliquez sur Update Settings en bas de la page.

   Cette configuration indique que le conteneur proxy sidecar exécute trois threads de travail au moment de l'exécution.

4. Redéployez la charge de travail pour appliquer la configuration du proxy sidecar.

5. Exécutez la commande suivante pour consulter la concurrence Istio-Proxy que vous avez configurée.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Résultat attendu :

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
       - args:
           - proxy
           - sidecar
           - '--domain'
           - $(POD_NAMESPACE).svc.cluster.local
           - '--proxyLogLevel=warning'
           - '--proxyComponentLogLevel=misc:error'
           - '--log_output_level=default:info'
           - '--concurrency'
           - '3'
   ...
         name: istio-proxy
   ...

   Le paramètre concurrency du conteneur istio-proxy est défini sur 3. Cela indique que la configuration Number of Sidecar Proxy Threads a pris effet.

Description du paramètre

Vous devez spécifier une liste de plages d'adresses IP séparées par des virgules (,). Chaque plage d'adresses IP doit être au format CIDR. Lorsqu'une charge de travail avec un proxy sidecar injecté accède à d'autres services, seul le trafic dont les adresses IP de destination se trouvent dans les plages configurées est intercepté par le conteneur proxy sidecar. Les autres requêtes sont envoyées directement vers leurs destinations sans passer par le proxy sidecar. Par défaut, ce paramètre est défini sur *, ce qui signifie que le conteneur proxy sidecar intercepte tout le trafic sortant de la charge de travail.

Exemple de configuration

1. Sur la page Configure the agent parameters of the injected Sidecar, cliquez sur l'onglet correspondant au niveau de configuration du proxy sidecar cible, puis cliquez sur Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Facultatif) Dans la section Enable/Disable Sidecar Proxy by Ports or IP Addresses, sélectionnez Addresses to Which External Access Is Redirected to Sidecar Proxy.

   Cette étape est requise dans les onglets Namespace et workload. Vous pouvez ignorer cette étape dans l'onglet global.

3. Définissez Addresses to Which External Access Is Redirected to Sidecar Proxy sur 192.168.0.0/16,10.1.0.0/24, puis cliquez sur Update Settings en bas de la page.

   Cette configuration indique que le conteneur proxy sidecar intercepte les requêtes dont les adresses IP de destination se trouvent dans les deux blocs CIDR 192.168.0.0/16 et 10.1.0.0/24.

4. Redéployez la charge de travail pour appliquer la configuration du proxy sidecar.

5. Exécutez la commande suivante pour consulter les plages d'adresses configurées pour l'interception du trafic sortant.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Résultat attendu :

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '192.168.0.0/16,10.1.0.0/24'
           - '-x'
           - 192.168.0.1/32
           - '-b'
           - '*'
           - '-d'
           - '15090,15021,15081,9191,15020'
           - '--log_output_level=default:info'
   ...
         name: istio-init
   ...

   Les paramètres d'exécution du conteneur istio-init incluent -i 192.168.0.0/16,10.1.0.0/24. Cela indique que la configuration Addresses to Which External Access Is Redirected to Sidecar Proxy a pris effet.

Description du paramètre

Exemple de configuration

1. Sur la page Configure the agent parameters of the injected Sidecar, cliquez sur l'onglet correspondant au niveau de configuration du proxy sidecar cible, puis cliquez sur Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Facultatif) Dans la section Enable/Disable Sidecar Proxy by Ports or IP Addresses, sélectionnez Addresses to Which External Access Is Not Redirected to Sidecar Proxy.

   Cette étape est requise dans les onglets Namespace et workload. Vous pouvez ignorer cette étape dans l'onglet global.

3. Définissez Addresses to Which External Access Is Not Redirected to Sidecar Proxy sur 10.1.0.0/24, puis cliquez sur Update Settings en bas de la page.

   Cette configuration indique que le conteneur proxy sidecar n'intercepte pas les requêtes dont les adresses IP de destination se trouvent dans le bloc CIDR 10.1.0.0/24.

4. Redéployez la charge de travail pour appliquer la configuration du proxy sidecar.

5. Exécutez la commande suivante pour consulter les plages d'adresses exclues de l'interception du trafic sortant que vous avez configurées.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Résultat attendu :

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '*'
           - '-x'
           - '192.168.0.1/32,10.1.0.0/24'
           - '-b'
           - '*'
           - '-d'
           - '15090,15021,15081,9191,15020'
           - '--log_output_level=default:info'
   ...
         name: istio-init
   ...

   Les paramètres d'exécution du conteneur istio-init incluent -x 192.168.0.1/32,10.1.0.0/24. 192.168.0.1/32 correspond au bloc CIDR de l'adresse hôte par défaut. 10.1.0.0/24 correspond à la plage d'adresses IP configurée pour le proxy sidecar. Cela indique que la configuration Addresses to Which External Access Is Not Redirected to Sidecar Proxy a pris effet.

Description du paramètre

Spécifiez une liste de ports séparés par des virgules (,). Le trafic destiné aux ports figurant dans cette liste est intercepté par le conteneur du proxy sidecar. Par défaut, ce paramètre est défini sur *, ce qui signifie que le conteneur du proxy sidecar intercepte tout le trafic entrant de la charge de travail.

Exemple de configuration

1. Sur la page Configure the agent parameters of the injected Sidecar, cliquez sur l'onglet correspondant au niveau de configuration du proxy sidecar cible, puis cliquez sur Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Facultatif) Dans la section Enable/Disable Sidecar Proxy by Ports or IP Addresses, sélectionnez Ports on Which Inbound Traffic Redirected to Sidecar Proxy.

   Cette étape est requise dans les onglets Namespace et workload. Vous pouvez ignorer cette étape dans l'onglet global.

3. Définissez Ports on Which Inbound Traffic Redirected to Sidecar Proxy sur 80 443, puis cliquez sur Update Settings.

   Cette configuration indique que le conteneur du proxy sidecar n'intercepte que les requêtes envoyées aux ports 80 et 443 de la charge de travail.

4. Redéployez la charge de travail pour appliquer la configuration du proxy sidecar.

5. Exécutez la commande suivante pour consulter les ports d'interception du trafic entrant que vous avez configurés.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Résultat attendu :

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '*'
           - '-x'
           - 192.168.0.1/32
           - '-b'
           - '80,443'
           - '-d'
           - '15090,15021,15081,9191,15020'
           - '--log_output_level=default:info'
   ...
         name: istio-init
   ...
                               

   Les paramètres d'exécution du conteneur istio-init incluent -b 80,443, ce qui correspond aux ports entrants configurés pour le proxy sidecar. Cela confirme que la configuration Ports on Which Inbound Traffic Redirected to Sidecar Proxy a bien été prise en compte.

Description du paramètre

Exemple de configuration

1. Sur la page Configure the agent parameters of the injected Sidecar, cliquez sur l'onglet correspondant au niveau de configuration du proxy sidecar cible, puis cliquez sur Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Facultatif) Dans la section Enable/Disable Sidecar Proxy by Ports or IP Addresses, sélectionnez Ports on Which Outbound Traffic Redirected to Sidecar Proxy.

   Cette étape est requise dans les onglets Namespace et workload. Vous pouvez ignorer cette étape dans l'onglet global.

3. Définissez Ports on Which Outbound Traffic Redirected to Sidecar Proxy sur 80 443, puis cliquez sur Update Settings en bas de la page.

   Cette configuration indique que le conteneur du proxy sidecar intercepte les requêtes envoyées aux services sur les ports 80 et 443.

4. Redéployez la charge de travail pour appliquer la configuration du proxy sidecar.

5. Exécutez la commande suivante pour consulter les ports d'interception du trafic sortant que vous avez configurés.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Résultat attendu :

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '*'
           - '-x'
           - 192.168.0.1/32
           - '-b'
           - '*'
           - '-d'
           - '15090,15021,15081,9191,15020'
           - '--log_output_level=default:info'
           - '-q'
           - '80,443'
           - '--log_output_level=default:info'
   ...
         name: istio-init
   ...
                               

   Les paramètres d'exécution du conteneur istio-init incluent -q 80,443, ce qui correspond aux ports sortants configurés pour le proxy sidecar. Cela confirme que la configuration Ports on Which Outbound Traffic Redirected to Sidecar Proxy a bien été prise en compte.

Description du paramètre

Exemple de configuration

1. Sur la page Configure the agent parameters of the injected Sidecar, cliquez sur l'onglet correspondant au niveau de configuration du proxy sidecar cible, puis cliquez sur Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Facultatif) Dans la section Enable/Disable Sidecar Proxy by Ports or IP Addresses, sélectionnez Ports on Which Inbound Traffic Not Redirected to Sidecar Proxy.

   Cette étape est requise dans les onglets Namespace et workload. Vous pouvez ignorer cette étape dans l'onglet global.

3. Définissez Ports on Which Inbound Traffic Not Redirected to Sidecar Proxy sur 8000, puis cliquez sur Update Settings en bas de la page.

   Cette configuration indique que le conteneur du proxy sidecar n'intercepte plus les requêtes envoyées au port 8000 de la charge de travail.

4. Redéployez la charge de travail pour appliquer la configuration du proxy sidecar.

5. Exécutez la commande suivante pour consulter les ports de contournement du trafic entrant que vous avez configurés.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Résultat attendu :

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '*'
           - '-x'
           - 192.168.0.1/32
           - '-b'
           - '*'
           - '-d'
           - '15090,15021,15081,9191,15020,8000'
           - '--log_output_level=default:info'
   ...
         name: istio-init
   ...
                               

   Les paramètres d'exécution du conteneur istio-init incluent -d 15090,15021,15081,9191,8000. Les ports 15090,15021,15081,9191 correspondent aux ports applicatifs du proxy sidecar et sont exclus de l'interception par défaut. Le port 8000 correspond aux ports entrants configurés pour le proxy sidecar. Cela confirme que la configuration Ports on Which Inbound Traffic Not Redirected to Sidecar Proxy a bien été prise en compte.

Description du paramètre

Vous devez spécifier une liste de ports séparés par des virgules (,), qui représente les ports de service de destination de tout le trafic sortant. Les requêtes dont les ports de service de destination figurent dans cette liste ne sont pas interceptées par le conteneur du proxy sidecar, que l'adresse IP de destination se trouve ou non dans les plages d'adresses sortantes interceptées ou que le port de destination figure ou non dans la liste des ports sortants interceptés.

Exemple de configuration

1. Sur la page Configure the agent parameters of the injected Sidecar, cliquez sur l'onglet correspondant au niveau de configuration du proxy sidecar cible, puis cliquez sur Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Facultatif) Dans la section Enable/Disable Sidecar Proxy by Ports or IP Addresses, sélectionnez Ports on Which Outbound Traffic Not Redirected to Sidecar Proxy.

   Cette étape est requise sur les onglets Namespace et workload. Vous pouvez ignorer cette étape sur l'onglet global.

3. Définissez Ports on Which Outbound Traffic Not Redirected to Sidecar Proxy sur 8000, puis cliquez sur Update Configurations en bas de la page.

   Cette configuration indique que le conteneur du proxy sidecar n'intercepte plus les requêtes envoyées aux services sur le port 8000.

4. Redéployez le workload pour appliquer la configuration du proxy sidecar.

5. Exécutez la commande suivante pour afficher les ports de contournement du trafic sortant que vous avez configurés.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Résultat attendu :

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '*'
           - '-x'
           - 192.168.0.1/32
           - '-b'
           - '*'
           - '-d'
           - '15090,15021,15081,9191,15020'
           - '--log_output_level=default:info'
           - '-o'
           - '8000'
   ...
         name: istio-init
   ...
                               

   Les paramètres d'exécution du conteneur istio-init incluent -o 8000, ce qui correspond aux ports sortants configurés pour le proxy sidecar. Cela indique que la configuration Ports on Which Outbound Traffic Not Redirected to Sidecar Proxy a pris effet.

Description du paramètre

Vous pouvez activer ou désactiver la fonctionnalité de proxy DNS pour les conteneurs de proxy sidecar. Une fois la fonctionnalité de proxy DNS activée, les conteneurs de proxy sidecar interceptent les requêtes DNS des workloads afin d'améliorer les performances et la disponibilité du Service Mesh. Toutes les requêtes provenant des workloads sont redirigées vers le conteneur du proxy sidecar. Étant donné que les conteneurs de proxy sidecar stockent localement les mappages entre les adresses IP et les noms de domaine locaux, ils peuvent renvoyer directement les réponses DNS aux workloads sans envoyer de requêtes aux services DNS distants. Si une requête DNS ne peut pas être traitée par le conteneur du proxy sidecar, le sidecar transfère directement la requête DNS. Pour plus d'informations, consultez la rubrique Utiliser le proxy DNS dans ASM.

Exemple de configuration

1. Sur la page Configure the agent parameters of the injected Sidecar, cliquez sur l'onglet correspondant au niveau de configuration du proxy sidecar cible, puis cliquez sur DNS Proxy.

2. (Facultatif) Dans la section DNS Proxy, sélectionnez Enable DNS Proxy, activez l'interrupteur à droite, puis cliquez sur Update Settings.

   Cette étape est requise sur les onglets Namespace et workload. Vous pouvez ignorer cette étape sur l'onglet global. L'activation de l'interrupteur permet d'activer la fonctionnalité de proxy DNS pour le proxy sidecar.

3. Redéployez le workload pour appliquer la configuration du proxy sidecar.

4. Exécutez la commande suivante pour afficher la fonctionnalité de proxy DNS que vous avez configurée.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Résultat attendu :

   apiVersion: v1
   kind: Pod
   spec:
     containers:
       - args:
           - proxy
           - sidecar
           - '--domain'
           - $(POD_NAMESPACE).svc.cluster.local
           - '--proxyLogLevel=warning'
           - '--proxyComponentLogLevel=misc:error'
           - '--log_output_level=default:info'
           - '--concurrency'
           - '3'
         env:
   ...
           - name: ISTIO_META_DNS_AUTO_ALLOCATE
             value: 'true'
           - name: ISTIO_META_DNS_CAPTURE
             value: 'true'
   ...
         name: istio-proxy
                               

   Les variables d'environnement ISTIO_META_DNS_AUTO_ALLOCATE et ISTIO_META_DNS_CAPTURE du conteneur istio-proxy sont définies sur true. Cela indique que la configuration DNS Proxy a pris effet.

Description du paramètre

Ce paramètre spécifie des variables d'environnement supplémentaires ajoutées aux conteneurs de proxy sidecar. Vous pouvez configurer les deux types suivants de variables d'environnement de proxy sidecar.

Exemple de configuration

1. Sur la page Configure the agent parameters of the injected Sidecar, cliquez sur l'onglet correspondant au niveau de configuration du proxy sidecar cible, puis cliquez sur Manage Environment Variables for Sidecar Proxy.

2. (Facultatif) Dans la section Manage Environment Variables for Sidecar Proxy, sélectionnez Sidecar Graceful Shutdown (EXIT_ON_ZERO_ACTIVE_CONNECTIONS).

   Cette étape est requise sur les onglets Namespace et workload. Vous pouvez ignorer cette étape sur l'onglet global.

3. Activez l'interrupteur à droite de Sidecar Graceful Shutdown (EXIT_ON_ZERO_ACTIVE_CONNECTIONS), puis cliquez sur Update Configurations.

4. Redéployez le workload pour appliquer la configuration du proxy sidecar.

5. Exécutez la commande suivante pour afficher les variables d'environnement du proxy sidecar que vous avez configurées.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Sortie attendue :

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
   ...
         env:
           - name: EXIT_ON_ZERO_ACTIVE_CONNECTIONS
             value: 'true'
         name: istio-proxy
   ...

   La variable d'environnement EXIT_ON_ZERO_ACTIVE_CONNECTIONS est ajoutée aux variables d'environnement du sidecar dans le conteneur istio-proxy du Pod. Cela indique que la configuration Manage Environment Variables for Sidecar Proxy a bien été prise en compte.

Description du paramètre

HoldApplicationUntilProxyStarts est un paramètre de gestion du cycle de vie des proxys sidecar. Cette option est activée par défaut, ce qui signifie que pour un Pod dans lequel un proxy sidecar a été injecté, le conteneur du proxy sidecar doit démarrer avec succès avant les conteneurs d'application du Pod. Cela garantit qu'aucun trafic envoyé aux conteneurs d'application n'est perdu en raison du fait que le proxy sidecar n'a pas terminé son démarrage.

Si ce paramètre est désactivé, le conteneur du proxy sidecar et les conteneurs d'application du Pod démarrent simultanément. Lorsqu'un grand nombre de Pods sont déployés dans un cluster, les conteneurs de proxy sidecar peuvent démarrer lentement en raison de la charge élevée sur l'APIServer. Vous pouvez désactiver HoldApplicationUntilProxyStarts pour accélérer le déploiement.

Exemple de configuration

L'exemple suivant montre comment désactiver HoldApplicationUntilProxyStarts dans l'onglet global.

1. Sur la page Configure the agent parameters of the injected Sidecar, cliquez sur l'onglet global, puis cliquez sur Lifecycle Management.

2. Désactivez l'interrupteur situé à droite de l'option Sidecar Graceful Startup (HoldApplicationUntilProxyStarts), puis cliquez sur Update Settings.

   Cette configuration indique que la fonctionnalité HoldApplicationUntilProxyStarts est désactivée.

3. Redéployez la charge de travail pour appliquer la configuration du proxy sidecar.

4. Exécutez la commande suivante pour consulter le paramètre HoldApplicationUntilProxyStarts.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Sortie attendue :

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - command:
   ...
         name: sleep
   ...
         env:
           - name: PROXY_CONFIG
             value: >-
               {..."holdApplicationUntilProxyStarts":false,...}
   ...
         name: istio-proxy
   ...

   Une fois la fonctionnalité holdApplicationUntilProxyStarts désactivée, le conteneur istio-proxy n'est plus déclaré de force avant les conteneurs d'application, et le champ lifecycle par défaut n'est plus déclaré. Dans ce cas, Service Mesh ne garantit plus que le conteneur du proxy sidecar démarre avec succès avant les conteneurs d'application.

Description du paramètre

La durée de vidage lors de l'arrêt du proxy sidecar est un paramètre de gestion du cycle de vie des proxys sidecar. Après l'injection d'un proxy sidecar dans un Pod, le trafic du Pod d'application est intercepté par le conteneur du proxy sidecar.

Lorsqu'un Pod commence à s'arrêter, le Service correspondant ne transfère plus le trafic vers ce Pod. Après avoir reçu le signal d'arrêt, le conteneur du proxy sidecar attend pendant une certaine période. Durant cette période, le conteneur cesse d'accepter le nouveau trafic entrant, mais continue de traiter le trafic entrant existant. Le trafic sortant n'est pas affecté et peut toujours être envoyé normalement. Cette période est appelée durée de vidage lors de l'arrêt du proxy sidecar. La durée de vidage par défaut des conteneurs de proxy sidecar est de 5s. Vous pouvez configurer une durée en s, par exemple 10s.

Si les appels d'interface fournis par le service en cours d'arrêt prennent beaucoup de temps et dépassent la durée de vidage du conteneur du proxy sidecar, les connexions entrantes et sortantes existantes sont interrompues même si elles n'ont pas été entièrement traitées, ce qui peut entraîner la perte de certaines requêtes. Dans ce cas, vous pouvez utiliser ce paramètre pour prolonger la durée de vidage lors de l'arrêt du proxy sidecar afin que le trafic entrant et sortant puisse être entièrement traité.

La durée de vidage lors de l'arrêt du proxy sidecar doit être spécifiée en secondes avec l'unité s, par exemple 10s.

Exemple de configuration

1. Sur la page Configure the agent parameters of the injected Sidecar, cliquez sur l'onglet correspondant au niveau de configuration du proxy sidecar cible, puis cliquez sur Lifecycle Management.

2. (Facultatif) Dans la section Lifecycle Management, sélectionnez Sidecar Proxy Drain Duration at Pod Termination.

   Cette étape est requise dans les onglets Namespace et workload. Vous pouvez ignorer cette étape dans l'onglet global.

3. Définissez Sidecar Proxy Drain Duration at Pod Termination sur 10s, puis cliquez sur Update Settings.

   Cette configuration indique que le proxy sidecar attend 10 secondes pour traiter les connexions existantes lors de l'arrêt.

4. Redéployez la charge de travail pour appliquer la configuration du proxy sidecar.

5. Exécutez la commande suivante pour consulter la durée de vidage lors de l'arrêt du proxy sidecar que vous avez configurée.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Sortie attendue :

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
   ...
         env:
           - name: TERMINATION_DRAIN_DURATION_SECONDS
             value: '10'
   ...
           - name: PROXY_CONFIG
             value: >-
               {..."terminationDrainDuration":"10s"}
   ...
         name: istio-proxy
   ...

   Le conteneur istio-proxy du Pod est configuré avec la variable d'environnement TERMINATION_DRAIN_DURATION_SECONDS définie sur 10, et la variable d'environnement PROXY_CONFIG enregistre terminationDrainDuration comme 10s. Cela indique que la configuration Sidecar Proxy Drain Duration at Pod Termination a bien été prise en compte.

Description du paramètre

Le paramètre de cycle de vie du proxy sidecar vous permet de personnaliser entièrement les hooks de cycle de vie des conteneurs des proxys sidecar. Pour ce paramètre, vous devez saisir un champ de hook de cycle de vie de conteneur (lifecycle) déclaré au format JSON. Ce champ remplace le champ de hook de cycle de vie par défaut du conteneur du proxy sidecar. Pour plus d'informations, consultez la documentation Hooks de cycle de vie des conteneurs.

Exemple de configuration

1. Sur la page Configure the agent parameters of the injected Sidecar, cliquez sur l'onglet correspondant au niveau de configuration du proxy sidecar cible, puis cliquez sur Lifecycle Management.

2. (Facultatif) Dans la section Lifecycle Management, sélectionnez Lifecycle of Sidecar Proxy.

   Cette étape est requise dans les onglets Namespace et workload. Vous pouvez ignorer cette étape dans l'onglet global.

3. Sous Lifecycle of Sidecar Proxy, saisissez le contenu YAML suivant, puis cliquez sur Update Settings.

   Ce contenu YAML configure les paramètres de hook postStart et preStop.

   • postStart : attend le démarrage de pilot-agent après le démarrage du conteneur sidecar.

   • preStop : met en veille pendant 13 secondes avant l'arrêt du conteneur sidecar.

   {
     "postStart": {
       "exec": {
         "command": [
           "pilot-agent",
           "wait"
         ]
       }
     },
     "preStop": {
       "exec": {
         "command": [
           "/bin/sh",
           "-c",
           "sleep 13"
         ]
       }
     }
   }

4. Redéployez la charge de travail pour appliquer la configuration du proxy sidecar.

5. Exécutez la commande suivante pour consulter le cycle de vie du proxy sidecar que vous avez configuré.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Sortie attendue :

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
   ...
   ...
           lifecycle:
           postStart:
             exec:
               command:
               - pilot-agent
               - wait
           preStop:
             exec:
               command:
               - /bin/sh
               - -c
               - sleep 13
         name: istio-proxy
   ...

   Le champ de hook du cycle de vie du conteneur (lifecycle) du conteneur istio-proxy dans le Pod est modifié pour correspondre à la configuration cible. Cela indique que la configuration Lifecycle of Sidecar Proxy a pris effet.

Description du paramètre

Ce paramètre définit la politique d'accès des conteneurs proxy sidecar aux services externes. Les services externes sont des services situés en dehors du maillage qui ne sont pas enregistrés auprès de Service Mesh. Par défaut, tous les services présents dans les clusters Kubernetes gérés par Service Mesh sont considérés comme des services enregistrés. Vous pouvez enregistrer manuellement des services auprès de Service Mesh en déclarant des ressources ServiceEntry. Les services non enregistrés sont considérés comme des services externes.

Exemple de configuration

1. Dans l'onglet global de la page Configure the agent parameters of the injected Sidecar, cliquez sur Outbound Traffic Policy, sélectionnez REGISTRY_ONLY à droite de Outbound Traffic Policy, puis cliquez sur Update Settings.

   Cette configuration restreint l'accès des services du maillage aux services externes.

2. Redéployez la charge de travail pour appliquer la configuration du proxy sidecar.

3. Créez le fichier sleep.yaml avec le contenu suivant.

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: sleep
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: sleep
     labels:
       app: sleep
       service: sleep
   spec:
     ports:
     - port: 80
       name: http
     selector:
       app: sleep
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: sleep
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: sleep
     template:
       metadata:
         labels:
           app: sleep
       spec:
         terminationGracePeriodSeconds: 0
         serviceAccountName: sleep
         containers:
         - name: sleep
           image: curlimages/curl
           command: ["/bin/sleep", "3650d"]
           imagePullPolicy: IfNotPresent
           volumeMounts:
           - mountPath: /etc/sleep/tls
             name: secret-volume
         volumes:
         - name: secret-volume
           secret:
             secretName: sleep-secret
             optional: true
   ---

4. Exécutez la commande suivante pour déployer l'application sleep.

   kubectl apply -f sleep.yaml -n default

5. Exécutez la commande suivante pour utiliser l'application sleep afin d'accéder à un service externe.

   kubectl exec -it {sleep-pod-name} -c sleep -- curl www.aliyun.com -v

   Sortie attendue :

   *   Trying *********...
   * Connected to www.aliyun.com (********) port 80 (#0)
   > GET / HTTP/1.1
   > Host: www.aliyun.com
   > User-Agent: curl/7.87.0-DEV
   > Accept: */*
   >
   * Mark bundle as not supporting multiuse
   < HTTP/1.1 502 Bad Gateway
   < date: Mon,********* 03:25:00 GMT
   < server: envoy
   < content-length: 0
   <
   * Connection #0 to host www.aliyun.com left intact

   La réponse 502 indique que l'application sleep, dotée d'un proxy sidecar injecté, ne peut pas accéder au service externe www.aliyun.com. Cela confirme que la configuration Outbound Traffic Policy a pris effet.

Description du paramètre

Ce paramètre définit la politique d'interception des proxies sidecar pour le trafic entrant. Par défaut, les conteneurs proxy sidecar utilisent la politique de redirection iptables REDIRECT pour intercepter le trafic entrant destiné aux charges de travail applicatives. Après interception par redirection, l'application ne voit que l'adresse IP du conteneur proxy sidecar comme adresse IP source des requêtes et ne peut pas voir l'adresse IP originale du client.

Si vous modifiez la politique d'interception du trafic entrant pour utiliser le mode proxy transparent (TPROXY), Service Mesh permet aux conteneurs proxy sidecar d'intercepter le trafic entrant via le mode proxy transparent iptables. Une fois ce paramètre configuré, l'application peut voir l'adresse IP originale du client. Pour plus d'informations, consultez la rubrique Obtenir l'adresse IP source du client dans Service Mesh.

Exemple de configuration

1. Sur la page Configure the agent parameters of the injected Sidecar, cliquez sur l'onglet correspondant au niveau de configuration du proxy sidecar ciblé, puis cliquez sur Sidecar Traffic Interception Mode.

2. (Facultatif) Dans la section Sidecar Traffic Interception Mode, sélectionnez Sidecar Traffic Interception Mode.

   Cette étape est requise dans les onglets Namespace et workload. Vous pouvez ignorer cette étape dans l'onglet global.

3. À droite de Sidecar Traffic Interception Mode, sélectionnez TPROXY, puis cliquez sur Update Settings.

4. Redéployez la charge de travail pour appliquer la configuration du proxy sidecar.

5. Exécutez la commande suivante pour afficher la politique d'interception du trafic entrant du sidecar que vous avez configurée.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Sortie attendue :

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
   ...
           - name: PROXY_CONFIG
             value: >-
               {..."interceptionMode":"TPROXY",...}
           - name: ISTIO_META_POD_PORTS
             value: |-
               [
               ]
   ...
         name: istio-proxy
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - TPROXY
   ...
         name: istio-init
   ...

   Les variables d'environnement du sidecar du conteneur istio-proxy dans le Pod indiquent "interceptionMode":"TPROXY", et le conteneur istio-init exécute également la commande d'initialisation avec le paramètre TPROXY. Cela confirme que la configuration Sidecar Traffic Interception Mode a pris effet.

Description du paramètre

Ce paramètre définit le niveau de journalisation des conteneurs proxy sidecar. Par défaut, les proxies sidecar utilisent le niveau de journalisation info. Vous pouvez modifier le niveau de journalisation des proxies sidecar vers l'un des sept niveaux suivants : info, debug, trace, warning, error, critical et off, afin d'obtenir plus ou moins d'informations de journalisation provenant des proxies sidecar.

Exemple de configuration

1. Sur la page Configure the agent parameters of the injected Sidecar, cliquez sur l'onglet correspondant au niveau de configuration du proxy sidecar ciblé, puis cliquez sur Monitoring Statistics.

2. (Facultatif) Dans la section Monitoring Statistics, sélectionnez Log Level.

   Cette étape est requise dans les onglets Namespace et workload. Vous pouvez ignorer cette étape dans l'onglet global.

3. À droite de Log Level, sélectionnez error, puis cliquez sur Update Settings.

   Cette configuration indique que le proxy sidecar génère des journaux au niveau error ; seuls les journaux de niveau error ou supérieur sont affichés.

4. Redéployez la charge de travail pour appliquer la configuration du proxy sidecar.

5. Exécutez la commande suivante pour afficher le niveau de journalisation du proxy sidecar que vous avez configuré.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Résultat attendu :

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
           - proxy
           - sidecar
           - '--domain'
           - $(POD_NAMESPACE).svc.cluster.local
           - '--proxyLogLevel=error'
   ...
         name: istio-proxy
   ...

   Les paramètres d'exécution du conteneur istio-proxy sont définis sur --proxyLogLevel=error. Cela confirme que la configuration du Log Level a bien été prise en compte.

Description du paramètre

Ce paramètre définit les statistiques Envoy personnalisées rapportées par les proxies sidecar. Envoy constitue l'implémentation technique des proxies sidecar et peut collecter et rapporter une série de métriques. Toutefois, Service Mesh n'active par défaut la collecte et l'exposition que de certaines métriques afin de réduire la surcharge de performance sur les proxies sidecar. Utilisez ce paramètre pour spécifier les métriques supplémentaires que les proxies sidecar doivent collecter et rapporter, en utilisant la correspondance par préfixe, par suffixe ou par expression régulière.

Exemple de configuration

1. Sur la page Configure the agent parameters of the injected Sidecar, cliquez sur l'onglet correspondant au niveau de configuration du proxy sidecar cible, puis cliquez sur Monitoring Statistics.

2. Dans la section Monitoring Statistics, sélectionnez proxyStatsMatcher, choisissez Regular Expression Match, puis définissez la valeur sur .outlier_detection..

   Cette configuration ajoute la collecte des métriques de disjoncteur (circuit breaking) pour le proxy sidecar.

3. Redéployez la charge de travail pour appliquer la configuration du proxy sidecar.

4. Exécutez la commande suivante pour consulter les statistiques personnalisées du proxy sidecar que vous avez configuré.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Résultat attendu :

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
    ...
           - name: PROXY_CONFIG
             value: >-
               {..."proxyStatsMatcher":{"inclusionRegexps":[".*outlier_detection.*"]},...}
   ...

   Les statistiques personnalisées dans les variables d'environnement du sidecar du conteneur istio-proxy du Pod ont été mises à jour. Cela indique que la configuration proxyStatsMatcher a bien été prise en compte.

Description du paramètre

Ce paramètre spécifie les paramètres d'exécution du processus Envoy dans les conteneurs de proxy sidecar. Vous pouvez configurer le paramètre d'exécution suivant.

Exemple de configuration

1. Sur la page Configure the agent parameters of the injected Sidecar, cliquez sur l'onglet correspondant au niveau de configuration du proxy sidecar cible, puis cliquez sur Manage Environment Variables for Sidecar Proxy.

2. (Facultatif) Dans la section Envoy Runtime Parameters, saisissez 5000 dans le champ de saisie à droite de Limits on Downstream Connections, puis cliquez sur Update Configurations.

3. Redéployez la charge de travail pour appliquer la configuration du proxy sidecar.

4. Exécutez la commande suivante pour consulter les variables d'environnement du proxy sidecar que vous avez configuré.

kubectl get pod -n <namespace> <pod-name> -o yaml

Résultat attendu :

apiVersion: v1
kind: Pod
...
spec:
  containers:
    - args:
...
      env:
        - name: PROXY_CONFIG
          value: >-
            {"concurrency":2,"configPath":"/etc/istio/proxy","discoveryAddress":"istiod-1-22-6.istio-system.svc:15012","holdApplicationUntilProxyStarts":true,"interceptionMode":"REDIRECT","proxyMetadata":{"BOOTSTRAP_XDS_AGENT":"false","DNS_AGENT":"","EXIT_ON_ZERO_ACTIVE_CONNECTIONS":"true"},"runtimeValues":{"overload.global_downstream_max_connections":"5000"},"terminationDrainDuration":"5s","tracing":{"zipkin":{"address":"zipkin.istio-system:9411"}}}
      name: istio-proxy
...

Le champ "runtimeValues":{"overload.global_downstream_max_connections":"5000"} a été ajouté à la variable d'environnement PROXY_CONFIG dans la configuration du sidecar du conteneur istio-proxy du Pod. Cela indique que la configuration des paramètres d'exécution Envoy a bien été prise en compte.