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
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" }Créez un ConfigMap avec le nom
istio-shared-configmap-<asm-revision>dans l’espace de nomsaks-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: trueLes valeurs sous
defaultConfigsont des paramètres de maillage appliqués pour le proxy sidecar Envoy.
Attention
Un ConfigMap par défaut (par exemple, istio-asm-1-18 pour la révision asm-1-18) est créé dans l’espace de noms aks-istio-system sur le cluster quand le module complémentaire Istio est activé. Toutefois, ce ConfigMap par défaut est rapproché par le module complémentaire Istio managé, donc les utilisateurs NE doivent PAS modifier directement ce ConfigMap. À la place, les utilisateurs doivent créer un ConfigMap partagé Istio propre à la révision (par exemple, istio-shared-configmap-asm-1-18 pour la révision asm-1-18) dans l’espace de noms aks-istio-system, puis le plan de contrôle Istio fusionne ce ConfigMap avec le ConfigMap par défaut, les paramètres par défaut étant prioritaires.
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é.
| Champ | Pris en charge/autorisé | Notes |
|---|---|---|
| proxyListenPort | Autorisé | - |
| proxyInboundListenPort | Autorisé | - |
| proxyHttpPort | Autorisé | - |
| connectTimeout | Autorisé | Configurable dans DestinationRule |
| tcpKeepAlive | Autorisé | Configurable dans DestinationRule |
| defaultConfig | Pris en charge | Utilisé pour configurer ProxyConfig |
| outboundTrafficPolicy | Pris en charge | Également configurable dans Sidecar CR |
| extensionProviders | Autorisé | - |
| defaultProviders | Autorisé | - |
| accessLogFile | Pris en charge | Ce champ concerne la génération des journaux d’accès. Pour une expérience managée sur la collection et l’interrogation des journaux d’activité, reportez-vous à Azure Monitor Container Insights sur AKS. Il est recommandé de configurer la journalisation des accès via l’API Télémétrie. |
| accessLogFormat | Pris en charge | Ce champ concerne la génération des journaux d’accès. Pour une expérience managée sur la collecte et l’interrogation des journaux, reportez-vous à Azure Monitor Container Insights sur AKS |
| accessLogEncoding | Pris en charge | Ce champ concerne la génération des journaux d’accès. Pour une expérience managée sur la collecte et l’interrogation des journaux, reportez-vous à Azure Monitor Container Insights sur AKS |
| enableTracing | Autorisé | Il est recommandé de configurer le suivi via l’API Télémétrie. |
| enableEnvoyAccessLogService | Pris en charge | Ce champ concerne la génération des journaux d’accès. Pour une expérience managée sur la collecte et l’interrogation des journaux, reportez-vous à Azure Monitor Container Insights sur AKS |
| disableEnvoyListenerLog | Pris en charge | Ce champ concerne la génération des journaux d’accès. Pour une expérience managée sur la collecte et l’interrogation des journaux, reportez-vous à Azure Monitor Container Insights sur AKS |
| trustDomain | Autorisé | - |
| trustDomainAliases | Autorisé | - |
| caCertificates | Autorisé | Configurable dans DestinationRule |
| defaultServiceExportTo | Autorisé | Configurable dans ServiceEntry |
| defaultVirtualServiceExportTo | Autorisé | Configurable dans VirtualService |
| defaultDestinationRuleExportTo | Autorisé | Configurable dans DestinationRule |
| localityLbSetting | Autorisé | Configurable dans DestinationRule |
| dnsRefreshRate | Autorisé | - |
| h2UpgradePolicy | Autorisé | Configurable dans DestinationRule |
| enablePrometheusMerge | Autorisé | - |
| discoverySelectors | Pris en charge | - |
| pathNormalization | Autorisé | - |
| defaultHttpRetryPolicy | Autorisé | Configurable dans VirtualService |
| serviceSettings | Autorisé | - |
| meshMTLS | Autorisé | - |
| tlsDefaults | Autorisé | - |
| ingressService | Autorisé | Nom du service Kubernetes utilisé pour le contrôleur d’entrée istio. |
| ingressSelector | Autorisé | Définit le déploiement de passerelle à utiliser comme contrôleur d’entrée. Ce champ correspond au champ Gateway.selector et est défini avec l’étiquette istio: INGRESS_SELECTOR. |
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.
| Champ | Pris en charge/autorisé | Notes |
|---|---|---|
| tracingServiceName | Autorisé | Il est recommandé de configurer le suivi via l’API Télémétrie. |
| drainDuration | Pris en charge | - |
| statsUdpAddress | Autorisé | - |
| proxyAdminPort | Autorisé | - |
| tracing | Autorisé | Il est recommandé de configurer le suivi via l’API Télémétrie. |
| concurrency | Pris en charge | - |
| envoyAccessLogService | Autorisé | Il est recommandé de configurer le suivi via l’API Télémétrie. |
| envoyMetricsService | Autorisé | Il est recommandé de configurer la sélection des métriques via l’API Télémétrie. |
| proxyMetadata | Autorisé | - |
| statusPort | Autorisé | - |
| extraStatTags | Autorisé | - |
| proxyStatsMatcher | Autorisé | - |
| terminationDrainDuration | Pris en charge | - |
| meshId | Autorisé | - |
| holdApplicationUntilProxyStarts | Pris en charge | - |
| caCertificatesPem | Autorisé | - |
| privateKeyProvider | Autorisé | - |
Attention
Étendue de prise en charge des configurations : la configuration de maillage permet aux fournisseurs d’extension, comme les instances auto-managées de Zipkin ou Apache Skywalking, d’être configurés avec le module complémentaire Istio. Toutefois, ces fournisseurs d’extension ne sont pas dans l’étendue de prise en charge du module complémentaire Istio. Tous les problèmes associés aux outils d’extension sont en dehors de la limite de prise en charge du module complémentaire Istio.
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 nomsaks-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
MeshConfigcomme 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 champdiscoverySelectorsdans MeshConfig pour alléger la consommation de mémoire pour Istiod et Envoy. - Si le champ
concurrencydans 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
holdApplicationUntilProxyStartsdans MeshConfig.
Azure Kubernetes Service