Configurer le module complémentaire de maillage de service basé sur Istio pour Azure Kubernetes Service

Istio open source utilise MeshConfig pour définir les paramètres de maillage du service Istio. Le module complémentaire de maillage de service basé sur Istio pour AKS s’appuie sur MeshConfig, et classifie différentes propriétés selon qu’elles sont prises en charge, autorisées ou bloquées.

Cet article explique comment configurer le module complémentaire de maillage de service basé sur Istio pour Azure Kubernetes Service et la stratégie de prise en charge applicable à cette configuration.

Prérequis

Ce guide suppose que vous avez suivi la documentation pour activer le module complémentaire Istio sur un cluster AKS.

Définir la configuration sur un cluster

1. Découvrez la révision d’Istio qui est déployée sur le cluster :

   az aks show --name $CLUSTER --resource-group $RESOURCE_GROUP --query 'serviceMeshProfile'
   

   Sortie :

   {
     "istio": {
         "certificateAuthority": null,
         "components": {
         "egressGateways": null,
         "ingressGateways": null
         },
         "revisions": [
         "asm-1-18"
         ]
     },
     "mode": "Istio"
   }
   

2. Créez un ConfigMap avec le nom istio-shared-configmap-<asm-revision> dans l’espace de noms aks-istio-system. Par exemple, si votre cluster exécute la révision asm-1-18 du maillage, le ConfigMap doit être nommé istio-shared-configmap-asm-1-18. La configuration du maillage doit être fournie dans la section des données sous le maillage.

   Exemple :

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: istio-shared-configmap-asm-1-18
     namespace: aks-istio-system
   data:
     mesh: |-
       accessLogFile: /dev/stdout
       defaultConfig:
         holdApplicationUntilProxyStarts: true
   

   Les valeurs sous defaultConfig sont des paramètres de maillage appliqués pour le proxy sidecar Envoy.

Configuration et mises à niveau du maillage

Lorsque vous effectuez une mise à niveau de contrôle de validité pour Istio, vous devez créer un ConfigMap distinct pour la nouvelle révision dans l’espace de noms aks-istio-system avant de lancer la mise à niveau de contrôle de validité. De cette façon, la configuration est disponible quand le plan de contrôle de la nouvelle révision est déployé sur le cluster. Par exemple, si vous mettez à niveau le maillage d’asm-1-18 vers asm-1-19, vous devez copier les changements par rapport à istio-shared-configmap-asm-1-18 dans un nouveau ConfigMap appelé istio-shared-configmap-asm-1-19 dans l’espace de noms aks-istio-system.

Une fois la mise à niveau effectuée ou restaurée, vous pouvez supprimer le ConfigMap de la révision que vous avez supprimée du cluster.

Valeurs MeshConfig autorisées, prises en charge et bloquées

Les champs dans MeshConfig sont classés comme allowed, supported ou blocked. Pour en savoir plus à propos de ces catégories, consultez la stratégie de prise en charge des fonctionnalités et des options de configuration des modules complémentaires Istio.

La configuration de maillage et la liste des champs autorisés/pris en charge sont propres à la révision pour tenir compte des champs ajoutés/supprimés entre les révisions. La liste complète des champs autorisés et des champs pris en charge/non pris en charge dans la liste autorisée est fournie dans le tableau ci-dessous. Quand une nouvelle révision de maillage est disponible, tous les changements des catégories Autorisé et Pris en charge des champs sont notés dans ce tableau.

MeshConfig

Les champs présents dans la documentation de référence de MeshConfig open source qui ne sont pas couverts dans le tableau suivant sont bloqués. Par exemple, configSources est bloqué.

ProxyConfig (meshConfig.defaultConfig)

Les champs présents dans la documentation de référence de MeshConfig open source qui ne sont pas couverts dans le tableau suivant sont bloqués.

Erreurs courantes et conseils de résolution des problèmes

• Vérifiez que MeshConfig est mis en retrait avec des espaces et non des tabulations.
• Vérifiez que vous modifiez uniquement le ConfigMap partagé propre à la révision (par exemple, istio-shared-configmap-asm-1-18) et que vous n’essayez pas de modifier le ConfigMap par défaut (par exemple, istio-asm-1-18).
• ConfigMap doit avoir un nom de type istio-shared-configmap-<asm-revision> et se trouver dans l’espace de noms aks-istio-system.
• Vérifiez que tous les champs MeshConfig sont correctement orthographiés. S’ils ne sont pas reconnus ou qu’ils ne font pas partie de la liste autorisée, le contrôle d’admission refuse ces configurations.
• Quand vous effectuez des mises à niveau de contrôle de validité, consultez vos ConfigMap propres à la révision pour vérifier que les configurations existent pour les révisions déployées sur votre cluster.
• Certaines options MeshConfig comme accessLogging peuvent augmenter la consommation de ressources d’Envoy, et la désactivation de certains de ces paramètres peut atténuer l’utilisation des ressources du plan de données Istio. Nous vous conseillons également d’utiliser le champ discoverySelectors dans MeshConfig pour alléger la consommation de mémoire pour Istiod et Envoy.
• Si le champ concurrency dans MeshConfig est mal configuré et défini sur zéro, Envoy utilise tous les cœurs du processeur. En revanche, si ce champ n’est pas défini, le nombre de threads de travail à exécuter est automatiquement déterminé en fonction des demandes/limites du processeur.
• Conditions de concurrence des pods et du sidecar dans lesquelles l’application démarre avant qu’Envoy puisse être atténué en utilisant le champ holdApplicationUntilProxyStarts dans MeshConfig.