Si vous êtes comme la plupart des gens, vous utilisez probablement des ressources exécutées en dehors de votre cluster. Peut-être utilisez-vous l'API Taleo pour envoyer des messages texte ou analyser des images à l'aide de l'API Google Cloud Vision.
Si vous utilisez le même point de terminaison de requête côté serveur dans tous vos environnements et que vous ne prévoyez pas de migrer vos serveurs vers Kubernetes, il est tout à fait possible d'avoir un point de terminaison de service directement dans votre code. Cependant, il existe de nombreux autres scénarios d'évolution des événements. Dans cette série de bonnes pratiques Kubernetes, vous apprendrez à utiliser les mécanismes intégrés de Kubernetes pour découvrir des services à la fois à l'intérieur et à l'extérieur du cluster.
Un exemple de service externe commun est une base de données exécutée en dehors d’un cluster Kubernetes. Contrairement aux bases de données cloud telles que Google Cloud Data Store ou Google Cloud Spanner, qui utilisent un seul point de terminaison pour tous les accès, la plupart des bases de données ont des points de terminaison distincts pour différentes circonstances.
Les meilleures pratiques d'utilisation de bases de données traditionnelles telles que MySQL et MongoDB signifient généralement que vous vous connectez à différents composants pour différents environnements. Vous pouvez disposer d’une grande machine pour les données de production et d’une machine plus petite pour l’environnement de test. Chacun d'eux aura sa propre adresse IP ou nom de domaine, mais vous ne souhaiterez probablement pas changer votre code lorsque vous passerez d'un environnement à un autre. Ainsi, au lieu de coder en dur ces adresses, vous pouvez utiliser la découverte de services externes basée sur DNS intégrée de Kubernetes de la même manière que les services Kubernetes natifs.
Supposons que vous exécutiez une base de données MongoDB sur Google Compute Engine. Vous serez coincé dans ce monde hybride jusqu'à ce que vous parveniez à le transférer vers le cluster.
Heureusement, vous pouvez utiliser les services Kubernetes statiques pour vous simplifier la vie. Dans cet exemple, j'ai créé un serveur MongoDB à l'aide de Google Cloud Launcher. Puisqu'il est créé sur le même réseau (ou VPC de cluster Kubernetes), on y accède à l'aide d'une adresse IP interne performante.
Il s'agit du paramètre par défaut sur Google Cloud, vous n'avez donc rien à configurer. Maintenant que vous disposez d’une adresse IP, la première étape consiste à créer un service. Vous remarquerez peut-être qu'il n'y a pas de sélecteurs de pods pour ce service. Autrement dit, nous avons créé un service qui ne saura pas où envoyer le trafic. Cela vous permettra de créer manuellement un objet de point de terminaison qui recevra le trafic de ce service.
L'exemple de code suivant montre que les points de terminaison déterminent l'adresse IP de la base de données en utilisant le même nom mongo que le service.
Kubernetes utilisera toutes les adresses IP pour rechercher les points de terminaison comme s'il s'agissait de pods Kubernetes classiques. Vous pouvez donc désormais accéder à la base de données avec une simple chaîne de connexion au nom ci-dessus mongodb://mongo. Il n'est pas du tout nécessaire d'utiliser des adresses IP dans votre code.
Si les adresses IP changent à l'avenir, vous pouvez simplement mettre à jour vos points de terminaison avec la nouvelle adresse IP et vos applications n'auront pas besoin d'être modifiées d'une manière supplémentaire.
Si vous utilisez une base de données hébergée sur un hôte tiers, il est probable que les propriétaires de l'hôte vous aient fourni un URI d'identifiant de ressource uniforme auquel vous connecter. Ainsi, si une adresse IP vous a été attribuée, vous pouvez simplement utiliser la méthode précédente. Cet exemple montre que j'ai deux bases de données MongoDB hébergées sur un hôte mLab.
L’une est la base de données des développeurs et l’autre est la base de données de production. Les chaînes de connexion pour ces bases de données ressemblent à ceci : mLab vous fournit un URI dynamique et un port dynamique. Comme vous pouvez le constater, ils sont différents.
Pour résumer cela, utilisons Kubernetes et connectons-nous à la base de données des développeurs. Vous pouvez créer un nom de service Kubernetes externe, qui vous donnera un service statique qui transmettra le trafic vers le service externe.
Ce service effectuera un simple transfert CNAME au niveau du noyau avec un impact minimal sur les performances. Grâce à cela, vous pouvez utiliser une chaîne de connexion plus simple.
Mais comme le nom externe utilise la redirection CNAME, il ne peut pas effectuer de redirection de port. Par conséquent, cette solution n’est applicable qu’aux ports statiques et ne peut pas être utilisée avec des ports dynamiques. Mais mLab Free Tier donne à l'utilisateur un numéro de port dynamique par défaut et vous ne pouvez pas le modifier. Cela signifie que vous avez besoin de lignes de commande de connexion différentes pour dev et prod. Le problème est que cela vous obligera à coder en dur le numéro de port. Alors, comment faire fonctionner la redirection de port ?
La première étape consiste à obtenir l'adresse IP à partir de l'URI. Si vous exécutez nslookup, le nom d'hôte ou pingez l'URI, vous pouvez obtenir l'adresse IP de la base de données. Si le service vous renvoie plusieurs adresses IP, alors toutes ces adresses peuvent être utilisées aux points finaux de l'objet.
Une chose à garder à l’esprit est que les URI IP peuvent changer sans préavis, ce qui les rend assez risqués à utiliser en production. Grâce à cette adresse IP, vous pouvez vous connecter à une base de données distante sans spécifier de port. Ainsi, le service Kubernetes effectue la redirection de port de manière assez transparente.
Le mappage, ou le mappage de ressources externes avec des ressources internes, vous offre la flexibilité nécessaire pour utiliser ces services au sein du cluster à l'avenir tout en minimisant les efforts de refactorisation. Cela facilite également la gestion et donne un aperçu des services externes utilisés par votre entreprise.
A suivre très prochainement...
Quelques publicités 🙂
Merci de rester avec nous. Vous aimez nos articles ? Vous voulez voir du contenu plus intéressant ? Soutenez-nous en passant une commande ou en recommandant à vos amis, , un analogue unique des serveurs d'entrée de gamme, que nous avons inventé pour vous : (disponible avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).
Dell R730xd 2 fois moins cher dans le centre de données Equinix Tier IV à Amsterdam ? Ici seulement aux Pays-Bas! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99$ ! En savoir plus
Source: habr.com