Tetrate a sponsorisé cet article.

Hongtao Gao

Hongtao est un ingénieur Tetrate et ancien expert du cloud Huawei. En tant que membre PMC d’Apache SkyWalking, il participe à des projets open source populaires tels qu’Apache ShardingSphere et Elastic-Job.

Souhaitez-vous observer un maillage de services qui s’étend aux machines virtuelles? Un nouvel analyseur en Apache SkyWalking – Le système APM (Application Monitoring), spécialement développé pour les microservices, les architectures cloud natives et basées sur des conteneurs. – utilise le mécanisme d’échange de métadonnées d’Envoy pour travailler dans Kubernetes, des machines virtuelles ou des environnements hybrides.

Dans une Article précédentNous avons parlé de l’observabilité du service mesh dans un environnement Kubernetes et l’avons appliqué à l’application bookinfo dans la pratique. Dans ce scénario, cependant, SkyWalking a besoin d’accéder aux métadonnées de service à partir d’un cluster Kubernetes afin de mapper les adresses IP aux services. Cela n’est pas disponible pour les services déployés dans les machines virtuelles. Dans ce tutoriel, nous montrons comment utiliser le nouvel analyseur de SkyWalking pour mieux observer un réseau avec des machines virtuelles.

Comment ça fonctionne

Ce qui distingue les VM de Kubernetes, c’est que pour les services de VM, il n’y a aucun endroit où nous pouvons extraire les métadonnées pour mapper les adresses IP aux services.

La mécanique de SkyWalking Analyzer est la même que la nôtre avant que mais l’idée principale que nous allons présenter dans cet article est de transporter les métadonnées avec les journaux d’accès d’Envoy – le mécanisme d’échange de métadonnées dans Envoy. (Le Accès au service de journalisation(ALS) est une extension Envoy qui envoie des journaux d’accès détaillés de toutes les demandes envoyées via Envoy.

Lorsque l’agent Istio Pilot démarre un proxy Envoy en tant que side-car d’un service, il collecte les métadonnées de ce service à partir de la plate-forme Kubernetes – ou un fichier sur la machine virtuelle sur laquelle ce service est déployé – et ajoute les métadonnées au bootstrap -Configuration par un envoyé. Envoy transmet ces métadonnées de manière transparente lors de l’envoi des journaux d’accès au récepteur SkyWalking.

Zhenxu Ke

Zhenxu est ingénieur Tetrate et membre PMC d’Apache SkyWalking. Il est également un committer Apache Dubbo.

Mais comment Envoy crée-t-il une partie d’un journal d’accès complet qui couvre les côtés client et serveur? Lorsqu’une requête provient d’Envoy, un plugin istio-proxy appelé metadata-exchange insère les métadonnées dans les en-têtes HTTP (avec un préfixe comme) x-envoy-downstream-) et les métadonnées sont transmises côté serveur. Le side-car Envoy côté serveur reçoit la demande, analyse les en-têtes en métadonnées, puis insère les métadonnées dans le journal d’accès – chiffrées par wasm.downstream_peer. L’Envoy côté serveur insère également ses propres métadonnées dans le journal d’accès, qui est chiffré par wasm.upstream_peer. Ceci conclut les deux côtés d’une seule demande.

Avec le mécanisme d’échange de métadonnées, nous pouvons utiliser ces métadonnées directement sans requête supplémentaire.

Exemple

Dans le didacticiel suivant, nous utiliserons une autre application de démonstration – Boutique en ligne – se compose de plus de 10 services, nous pouvons donc en déployer certains dans des VM et les laisser communiquer avec d’autres services fournis dans Kubernetes.

Topologie de la boutique en ligne

Pour couvrir le plus de cas possible, nous vous fournirons CheckoutService et PaymentService sur VM et tous les autres services sur Kubernetes; afin que nous puissions utiliser des cas comme Kubernetes → VM (par exemple FrontendCheckoutService), VM → Kubernetes (par exemple CheckoutServiceShippingService) et VM → VM (par ex. CheckoutServicePaymentService).

REMARQUE: Toutes les commandes utilisées dans ce didacticiel sont accessibles sur GitHub.

git clone https://github.com/SkyAPMTest/sw-als-vm-demo-scripts

cd sw-als-vm-demo-scripts

Assurez-vous d’avoir le gcloud SDK correctement avant de continuer.

Modifier le GCP_PROJECT dans le dossier env.sh à votre propre nom de projet. La plupart des autres variables devraient fonctionner si vous les gardez intactes. Si vous souhaitez utiliser ISTIO_VERSION > / = 1.8.0, veuillez vous assurer ce patch est inclus.

Préparer le cluster Kubernetes et les instances de VM

00-create-cluster-and-vms.sh Créez un nouveau cluster GKE et deux instances de VM qui seront utilisées tout au long du didacticiel, et configurez certaines règles de pare-feu nécessaires pour qu’ils puissent communiquer entre eux.

Installez Istio et SkyWalking

01a-install-istio.sh installe Istio Operator avec les spécifications resources/vmintegration.yaml. Dans le fichier YAML, nous activons le meshExpansion qui prend en charge VM dans le maillage. Nous activons également le service de journal d’accès Envoy et fournissons l’adresse skywalking-oap.istio-system.svc.cluster.local:11800 envoie les journaux d’accès à l’Envoy.

01b-install-skywalking.sh installe Apache SkyWalking et configure l’analyseur mx-mesh.

Créer des fichiers pour initialiser la machine virtuelle

02-create-files-to-transfer-to-vm.sh Crée les fichiers nécessaires utilisés pour initialiser les VM.

03-copy-work-files-to-vm.sh transfère en toute sécurité les fichiers générés vers les VM gcloud scp Commander.

Utilise le maintenant ./ssh.sh checkoutservice et ./ssh.sh paymentservice pour vous connecter aux deux VM, et cd au ~/work Exécuter le répertoire ./prep-checkoutservice.sh au checkoutservice Instance de VM et ./prep-paymentservice.sh au paymentservice Instance de VM. Le side-car Istio doit s’installer et démarrer correctement. Pour vérifier cela, utilisez tail -f /var/logs/istio/istio.log pour vérifier les journaux Istio. La sortie devrait ressembler à ceci:

La configuration dnsmasq address=/.svc.cluster.local/{ISTIO_SERVICE_IP_STUB} résout également les noms de domaine qui se terminent par .svc.cluster.local à l’adresse IP du service Istio afin que vous puissiez utiliser un nom de domaine complet (FQDN) tel que httpbin.default.svc.cluster.local.

Fournir une application de démonstration

Parce que nous voulons fournir CheckoutService et PaymentService manuellement sur VM, resources/google-demo.yaml supprime les deux services de le YAML original. 04a-deploy-demo-app.sh Déployez les autres services sur Kubernetes.

Connectez-vous ensuite aux 2 VM et exécutez-les ~/work/deploy-checkoutservice.sh et ~/work/deploy-paymentservice.sh pour mettre en œuvre chacun CheckoutService et PaymentService.

Enregistrer des VM avec Istio

Les services sur les VM peuvent accéder aux services sur Kubernetes à l’aide du nom de domaine complet. Cependant, ce n’est pas le cas si les services Kubernetes souhaitent communiquer avec les services VM. Le réseau n’a aucune idée de l’endroit où acheminer les demandes, par ex. checkoutservice.default.svc.cluster.local, car checkoutservice est isolé dans la VM. Par conséquent, nous devons enregistrer les services sur le réseau.

04b-register-vm-with-istio.sh enregistre les services VM sur le réseau en créant un service «factice» sans exécuter de pods, et un WorkloadEntry pour relier le service «factice» et le service VM.

Fait!

L’application de démonstration contient un générateur de charge: un service qui exécute des requêtes à plusieurs reprises. Nous devons juste attendre quelques secondes, puis ouvrir l’interface utilisateur Web de SkyWalking pour examiner les résultats.

export POD_NAME=$(kubectl get pods --namespace istio-system -l "app=skywalking,release=skywalking,component=ui" -o jsonpath="{.items[0].metadata.name}")

echo "Visit http://127.0.0.1:8080 to use your application"

kubectl port-forward $POD_NAME 8080:8080 --namespace istio-system

Accédez à dans le navigateur http: // localhost: 8080. Les métriques et la topologie doivent être en place.

topologie

Mesures globales

Mesures de CheckoutService.

Métriques de PaymentService

Dépannage

Si vous rencontrez des problèmes en suivant les étapes, voici quelques problèmes courants et les solutions possibles:

Le service VM ne peut pas accéder aux services Kubernetes?

Il est probable que le DNS sur la machine virtuelle ne résout pas correctement les noms de domaine complets. Essayez de vérifier cela avec nslookup istiod.istio-system.svc.cluster.local. Si Kubernetes ne peut pas résoudre l’adresse CIDR, vérifiez à nouveau l’étape prep-checkoutservice.sh et prep-paymentservice.sh.

Si le DNS fonctionne correctement, essayez de vérifier que l’Envoy a pu obtenir les clusters en amont à partir du plan de contrôle curl http: // localhost: 15000 / cluster. Si le service cible n’est pas inclus, vérifiez à nouveau prep-checkoutservice.sh.

Les services sont normaux mais rien sur SkyWalking WebUI?

Vérifiez les journaux de SkyWalking OAP kubectl -n istio-system logs -f $(kubectl get pod -A -l "app=skywalking,release=skywalking,component=oap" -o name) et protocoles WebUI sur kubectl -n istio-system logs -f $(kubectl get pod -A -l "app=skywalking,release=skywalking,component=ui" -o name) pour voir s’il existe des journaux d’erreurs. Assurez-vous également que le fuseau horaire est défini dans le coin inférieur droit du navigateur UTC +0.

Ressources supplémentaires

Observez un réseau de service avec l’envoyé ALS.

Prends en un e-book gratuit sur SkyWalking de Tetrate; En savoir plus sur SkyWalking sur le leur Blog et Connexion pour en savoir plus sur l’observabilité.

Vous pouvez trouver plus de mises à jour SkyWalking sur le site officiel et plus Twitter.

Les questions et commentaires peuvent être adressés à [email protected].

Image de vedette terminée Pixabay.





Source link

Recent Posts