Sélectionner une page


Tétrate sponsorisé ce post.

Nick Nellis

Nick est développeur de logiciels chez Tetrate, la société de maillage de services d’entreprise. Il est un expert DevOps pour Istio, l’architecture de cloud public et l’automatisation des infrastructures.

Vous avez peut-être entendu parler de l’ajout de la fonctionnalité DNS dans Istio 1.8, mais vous n’avez peut-être pas pensé à son impact. Il résout certains problèmes importants qui existent dans Istio et vous permet d’ajouter plusieurs clusters et machines virtuelles à votre architecture réseau. Vous pouvez trouver une excellente explication des fonctions sur le Site Internet d’Istio. En bref, il permet une intégration transparente entre plusieurs clusters et machines virtuelles. Dans cet article, nous allons tester les nouvelles fonctionnalités et, espérons-le, expliquer plus en détail ce qui se passe sous le capot.

Si vous êtes nouveau sur Istio ou vous vous demandez pourquoi le proxy DNS Istio est si important, jetez un œil Quoi de neuf dans Istio 1.8 (proxy DNS).

Activer le proxy DNS Istio

Cette fonction est actuellement en Alpha, mais peut être activée dans la configuration IstioOperator.

Requêtes DNS

Maintenant que les enregistrements DNS peuvent être mis en cache dans le side-car Istio, la charge sur kube-dns a été réduite. Mais les améliorations ne s’arrêtent pas là. Les paramètres par défaut réduisent également le nombre de requêtes effectuées pour chaque recherche. Cela conduit à des temps de dissolution améliorés. Voyons ce qui se passe lorsque j’ajoute un ServiceEntry pour istio.io.

Vous pouvez supposer que votre pod résout istio.io en ses adresses IP accessibles au public. Au lieu de cela, le side-car Istio renvoie une adresse IP virtuelle attribuée automatiquement 240.240.0.1 publié par Istiod.

Si vous êtes comme moi, vous avez peut-être vérifié qu’Istio avait changé le fichier /etc/resolv.conf pour le rediriger vers un autre emplacement, mais à ma grande surprise, il pointait toujours vers kube-dns.

En effet, Istio détourne les requêtes adressées à kube-dns à l’aide de tables IP et les transmet à la place à l’agent Istio s’exécutant dans le pod.

Enfin, nous devons nous rappeler que lorsque votre module d’application résout istio.io en VIP et fait une demande, le VIP sera échangé dans Envoy contre l’adresse IP publique réelle. Si nous regardons la configuration d’Envoy, nous pouvons voir comment cela est fait.

Jetons d’abord un coup d’œil au public de l’ambassadeur. Nous devrions voir un écouteur pour istio.io ServiceEntry sous la forme {VIP} _ {PORT}. La pièce importante dans l’auditeur est l’endroit où elle est représentée. Pour ce faire, nous recherchons le cluster Envoy dans « envoy.filters.network.tcp_proxy ». Ensuite, nous examinerons comment le cluster détermine l’adresse IP publique réelle pour istio.io.

istioctl proxy-config écouteur my-pod -o json

Si nous regardons le cluster istio.io, nous voyons une entrée sortante pour istio.io avec STRICT_DNS. Cela signifie qu’Envoy résoudra de manière continue et asynchrone les cibles DNS spécifiées. C’est ainsi que nous obtenons notre adresse IP publique pour istio.io

cluster istioctl proxy-config my-pod -o json

Depuis que nous avons créé le ServiceEntry istio.io, votre pod demande au DNS Istio pour istio.io et reçoit un VIP. Cette adresse IP virtuelle est ensuite traduite en adresse IP publique lorsqu’une demande est effectuée via le side-car de l’expéditeur.

Trafic TCP externe

Istio a actuellement une limitation sur le routage du trafic TCP externe car il est incapable de différencier deux services TCP différents. Cette limitation affecte notamment l’utilisation de bases de données tierces, telles que: B. Service de base de données relationnelle AWS. Dans l’exemple suivant, nous avons deux enregistrements de service pour différentes bases de données sur AWS. Ils sont mis à disposition sur le port standard 3306, sauf indication manuelle. Pre Istio 1.8 TCP ServiceEntries créerait un écouteur sortant sur les sidecars pour 0.0.0.0: vers {port}. Vous avez peut-être remarqué que plusieurs entrées de service TCP avec le même port ont des écouteurs Envoy en conflit. En fait, nous pouvons tester cela par nous-mêmes. L’exemple suivant utilise deux entrées de service TCP avec le même port. Essayez-le par vous-même.

Si nous regardons un pod fonctionnant sur le réseau, nous attendons deux écouteurs pour les bases de données séparées. Cependant, comme ils analysent uniquement le port, un seul écouteur est créé.

La seule solution pour le moment est de changer le port par défaut de votre base de données pour qu’il fonctionne dans Istio. Ci-dessous, j’ai changé le port sur db-2 en 3307 et maintenant nous pouvons voir les deux écouteurs tcp sortants.

Désormais, avec Istio Mesh DNS, les entrées de service se voient automatiquement attribuer une adresse IP virtuelle. Cela nous donne la possibilité de faire correspondre les auditeurs à l’adresse et au port VIP, comme indiqué ci-dessous. Cela a été enregistré avec Istio 1.8 avec ISTIO_META_DNS_CAPTURE: « true »

Machines virtuelles

L’accessibilité et la découvrabilité des machines virtuelles sont désormais nettement meilleures avec le proxy DNS Istio. Bien qu’Istio soit encore en phase pré-alpha, il peut désormais ajouter automatiquement des WorkloadEntries pour chaque machine virtuelle qui rejoint le réseau. Cela signifie que nous pouvons attribuer à notre VM (ou à un ensemble de VM) une entrée DNS adressable au sein du réseau.

Activer les entrées automatiques de charge de travail VM

Exemple de WorkloadEntry créé automatiquement

Création d’une entrée de service Istio pour afficher les instances de VM avec l’application Label: myvmapi via my-vm.com

Lorsque vous passez un appel sur le réseau, nous pouvons voir que notre serveur Web VM est disponible sur my-vm.com

DNS VM via le proxy Kube

Une autre façon d’ajouter des enregistrements DNS pour les instances de VM consiste à utiliser les services Kubernetes. Vous pouvez créer un service comme indiqué ci-dessous avec les sélecteurs d’étiquettes pointant vers Istio WorkloadEntries. Cela rend également disponibles les instances de VM dans my-vm.vm.svc.cluster.local

Proxy DNS Istio sur la VM

Le proxy DNS Istio s’applique également à la VM. Nous pouvons vérifier sur la machine virtuelle que obistio.io pointe toujours vers l’adresse IP virtuelle dans les exemples précédents.

Multicluster

Le proxy DNS Istio facilite le routage multicluster interne et nécessite moins de configuration.

Par exemple, si nous voulons rendre mon API api.tetrate.io disponible sur Internet via un équilibreur de charge cloud, nous attribuons généralement un enregistrement DNS public à cet équilibreur de charge cloud (exemple api.tetrate.io:35.1.1.1). Derrière ce Cloud Load Balancer, il peut y avoir une passerelle Istio Ingress qui surveille api.tetrate.io et transmet les requêtes à une application. Si nous voulons accéder à cette application à partir d’un autre cluster, nous appelons api.tetrate.io (35.1.1.1), mais ce n’est pas idéal. Nous accéderions à l’API via l’équilibreur de charge public si nous pouvions et devions y accéder sur mon réseau interne. Voyons comment nous pourrions résoudre ce problème en utilisant le proxy DNS d’Istio.

Routage interne pour le service exposé en externe

Afin de garder le trafic de données interne, nous avons besoin d’une autre entrée DNS à travers laquelle nos applications clientes peuvent accéder à l’API. Dans l’exemple ci-dessous, nous avons créé api.tetrate.internal pour l’adresse IP interne d’Ingress Gateway de 10.50.0.1 dans notre fournisseur DNS tiers. Nous pouvons ensuite configurer nos applications clientes pour utiliser cet hôte au lieu de api.tetrate.io. Nous devons également ajouter un écouteur supplémentaire pour l’hôte api.tetrate.internal à l’intérieur de la passerelle Istio Ingress.

Cette configuration est la plus courante aujourd’hui, mais elle présente certains inconvénients que le proxy DNS d’Istio peut résoudre.

Inconvénients de ne pas utiliser le proxy DNS d’Istio (configuration ci-dessus):

  • Configure les applications clientes pour utiliser un nom d’hôte autre que celui accessible au public.
    • Routage interne: api.tetrate.internal
    • Routage externe: api.tetrate.io
  • Utilise des écouteurs pour les hôtes externes et internes sur la passerelle d’entrée Istio.
  • S’appuie sur un DNS tiers pour la résolution d’adresse IP interne.
    • De nombreuses entreprises utilisent actuellement Publicité Serveur DNS pour résoudre les services internes.

Routage multicluster avec proxy DNS

Avec le proxy DNS d’Istio, le routage multicluster interne est beaucoup plus facile. Créez simplement un ServiceEntry pour api.tetrate.io avec l’adresse IP de la passerelle Istio Ingress et maintenant vos applications clientes peuvent acheminer en interne sur le même hôte! Le side-car Istio s’occupe maintenant de résoudre le nom d’hôte avec le VIP attribué et de saisir l’adresse IP interne de la passerelle. Aucun DNS tiers n’est requis, plusieurs écouteurs d’hôte sur la passerelle Ingress et, enfin, aucune modification de vos applications clientes n’est requise pour différencier le routage externe et interne.

lecture supplémentaire

Image de vedette terminée Pixabay.





Source link

Recent Posts