Dans le dernier
article, nous avons examiné les composants de base de Service Mesh Istio, pris connaissance du système et répondu aux questions de base qui se posent généralement au début de la collaboration avec Istio. Dans cette partie, nous verrons comment organiser la collecte d'informations de traçage sur le réseau.
La première chose que de nombreux développeurs et administrateurs système rencontrent lorsqu'ils entendent les mots Service Mesh. En effet, nous ajoutons un serveur proxy spécial à chaque nœud du réseau par lequel passe tout le trafic TCP. Il semble que vous pouvez désormais envoyer facilement des informations sur toutes les interactions réseau sur le réseau. Malheureusement, en réalité, de nombreuses nuances doivent être prises en compte. Regardons-les.
Idée fausse numéro un: nous pouvons obtenir gratuitement des données sur les trajets sur le réseau
En fait, relativement gratuit, nous ne pouvons que connecter les nœuds de notre système par des flèches et le débit de données qui passe entre les services (en fait, seulement le nombre d'octets par unité de temps). Cependant, dans la plupart des cas, nos services communiquent à l'aide d'une sorte de protocole au niveau de l'application, comme HTTP, gRPC, Redis, etc. Et, bien sûr, nous voulons voir les informations de traçage précisément selon ces protocoles, nous voulons voir le taux de demandes, et non le taux de données. Nous voulons comprendre la latence des demandes par notre protocole. Enfin, nous voulons voir le chemin complet parcouru par la demande entre notre système et la réception d'une réponse de l'utilisateur. Ce problème n'est pas si facilement résolu.
Pour commencer, regardons à quoi ressemble l'envoi de plages de traçage du point de vue de l'architecture dans Istio. Comme nous nous en souvenons de la première partie, Istio a un composant séparé pour collecter la télémétrie, qui est appelé Mixer. Cependant, dans la version actuelle 1.0. * L'envoi se fait directement à partir de serveurs proxy, à savoir avec le proxy envoyé. Envoy proxy prend en charge l'envoi de travées de traçage via le protocole zipkin hors de la boîte. D'autres protocoles peuvent être connectés, mais uniquement via le plugin. Avec Istio, nous obtenons immédiatement le proxy envoyé assemblé et configuré, qui ne prend en charge que le protocole zipkin. Si nous voulons utiliser, par exemple, le protocole Jaeger et envoyer des plages de traçage via UDP, nous devrons assembler notre image istio-proxy. Il existe un support pour les plugins personnalisés pour istio-proxy, mais il est toujours dans la version alpha. Par conséquent, si nous voulons nous passer de nombreux paramètres personnalisés, la gamme de technologies utilisées pour stocker et recevoir des plages de suivi est réduite. En fait, des principaux systèmes, vous pouvez maintenant utiliser Zipkin lui-même, ou Jaeger, mais envoyer tout là-bas en utilisant un protocole compatible Zipkin (qui est beaucoup moins efficace). Le protocole zipkin lui-même implique l'envoi de toutes les informations de traçage aux collecteurs à l'aide du protocole HTTP, ce qui est assez cher.
Comme je l'ai dit, nous voulons suivre les protocoles au niveau de l'application. Et cela signifie que les serveurs proxy situés à côté de chaque service doivent comprendre quel type d'interaction se produit actuellement. Par défaut, Istio définit le type de tous les ports TCP ordinaires, ce qui signifie qu'aucune trace ne sera envoyée. Pour que des traces soient envoyées, vous devez d'abord activer cette option dans la configuration de maillage principale et, très important, renommer tous les ports des entités de service kubernetes conformément au protocole utilisé dans le service. C'est, par exemple, comme ceci:
apiVersion: v1 kind: Service metadata: name: nginx spec: ports: - port: 80 targetPort: 80 name: http selector: app: nginx
Vous pouvez également utiliser des noms composés, tels que http-magic (Istio voit http et reconnaît ce port comme point de terminaison http). Le format est: proto-extra.
Afin de ne pas patcher un grand nombre de configurations pour définir un protocole, vous pouvez utiliser une solution de contournement sale: patcher un composant Pilot à un moment où il
exécute simplement
la logique de définition de protocole . À la fin, bien sûr, vous devrez changer cette logique en standard et passer à la convention de dénomination pour tous les ports.
Afin de comprendre si le protocole est vraiment défini correctement, vous devez aller dans l'un des conteneurs sidecar avec proxy d'envoi et faire une demande au port d'administration de l'interface d'envoyé avec location / config_dump. Dans la configuration résultante, vous devez examiner l'opération de champ de service souhaitée. Il est utilisé dans Istio comme identifiant de la destination de la demande. Afin de personnaliser la valeur de ce paramètre dans Istio (nous le verrons ensuite dans notre système de suivi), vous devez spécifier l'indicateur serviceCluster au stade du lancement du conteneur sidecar. Par exemple, il peut être calculé comme ceci à partir de variables obtenues à partir des kubernetes de l'API descendante:
--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')Un bon exemple pour comprendre comment fonctionne le traçage dans l'envoyé est
ici .
Le point de terminaison lui-même pour l'envoi des plages de suivi doit également être spécifié dans les indicateurs de démarrage du proxy envoyé, par exemple:
--zipkinAddress tracing-collector.tracing:9411Idée fausse numéro deux: nous pouvons obtenir à moindre coût les pistes complètes du passage des demandes pour le système hors de la boîte
Ce n'est malheureusement pas le cas. La complexité de la mise en œuvre dépend de la façon dont vous avez déjà mis en œuvre l'interaction des services. Pourquoi
Le fait est que pour que istio-proxy comprenne la correspondance des demandes entrantes avec un service avec celles provenant du même service, il ne suffit pas d'intercepter tout le trafic. Vous devez avoir une sorte d'identifiant de lien. Envoy proxy HTTP utilise des en-têtes spéciaux, par lesquels envoyé comprend quelle demande de service particulière génère des demandes spécifiques à d'autres services. Liste de ces en-têtes:
- x-request-id,
- x-b3-traceid,
- x-b3-spanid,
- x-b3-parentspanid,
- échantillonné x-b3,
- drapeaux x-b3,
- x-ot-span-context.
Si vous avez un seul point, par exemple, un client de base où vous pouvez ajouter une telle logique, alors tout va bien, il vous suffit d'attendre que tous les clients mettent à jour cette bibliothèque. Mais si vous avez un système très hétérogène et qu'il n'y a pas d'unification dans la campagne des services aux services sur le réseau, alors ce sera très probablement un gros problème. Sans l'ajout d'une telle logique, toutes les informations de traçage ne seront que "frère". Autrement dit, nous obtenons toutes les interactions interservices, mais elles ne seront pas collées dans une seule chaîne de passage à travers le réseau.
Conclusion
Istio fournit un outil pratique pour collecter des informations de traçage sur le réseau, cependant, vous devez comprendre que pour la mise en œuvre, vous devrez adapter votre système et prendre en compte les caractéristiques de la mise en œuvre d'Istio. Par conséquent, vous devez résoudre deux points principaux: déterminer le protocole de couche application (qui devrait être pris en charge par le proxy envoyé) et configurer la transmission d'informations sur la connectivité des demandes au service à partir des demandes du service (en utilisant des en-têtes, dans le cas du protocole HTTP). Lorsque ces problèmes sont résolus, nous obtenons un outil puissant qui vous permet de collecter de manière transparente des informations sur le réseau, même dans des systèmes très hétérogènes écrits dans de nombreux langages et cadres différents.
Dans le prochain article sur Service Mesh, nous examinerons l'un des plus gros problèmes d'Istio - une consommation élevée de mémoire par chaque conteneur proxy sidecar et discuterons de la manière de le gérer.