Meilleures pratiques Kubernetes. Cartographie des services externes

Meilleures pratiques Kubernetes. Création de petits conteneurs
Kubernetes Best Practices. Organisation Kubernetes avec l'
espace de noms Kubernetes Best Practices. Test de viabilité Kubernetes avec tests de préparation et de vivacité Kubernetes
Best Practices. Définition des requêtes et des limites de
ressources Meilleures pratiques Kubernetes. Déconnexion correcte de Terminate

Si vous êtes comme la plupart des gens, vous utilisez probablement des ressources qui opèrent en dehors de votre cluster. Vous utilisez peut-être 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 - le point de réception des demandes côté serveur dans tous vos environnements et que vous ne prévoyez pas de migrer vos serveurs vers Kubernetes, il est parfaitement normal d'avoir un service de point de terminaison directement dans votre code. Cependant, il existe de nombreux autres scénarios. Dans cette série de bonnes pratiques Kubernetes, vous apprendrez à utiliser les mécanismes intégrés de Kubernetes pour découvrir des services à l'intérieur et à l'extérieur du cluster.

Un exemple de service externe étendu est une base de données qui s'exécute 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 le même point de terminaison pour tous les types d'accès, la plupart des bases de données ont des points de terminaison distincts pour différentes circonstances.
Les meilleures pratiques d'utilisation des bases de données traditionnelles, telles que MySQL et MongoDB, nécessitent généralement que vous vous connectiez à différents composants pour différents environnements. Vous pouvez avoir une grande machine pour les données de production et une machine plus petite pour un environnement de test. Chacun d'eux aura sa propre adresse IP ou nom de domaine, mais vous ne voudrez probablement pas changer votre code lors du passage d'un environnement à un autre. Par conséquent, au lieu de coder en dur ces adresses, vous pouvez utiliser le service intégré Kubernetes pour découvrir les services externes basés sur DNS de la même manière que pour les services Kubernetes natifs.



Supposons que vous exécutez la base de données MongoDB dans Google Compute Engine. Vous serez coincé dans ce monde hybride jusqu'à ce que vous parveniez à le transférer dans un cluster.

Heureusement, vous pouvez utiliser les services statiques de Kubernetes pour vous faciliter la vie un peu. Dans cet exemple, j'ai créé un serveur MongoDB à l'aide de Google Cloud Launcher. Comme il a été créé sur le même réseau (ou cluster Kubernetes VPC), il est accessible à l'aide d'une adresse IP interne haute performance.



Il s'agit du paramètre par défaut sur Google Cloud, vous n'avez donc rien à configurer. Maintenant que vous avez 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 foyer pour ce service. Autrement dit, nous avons créé un service qui ne saura pas où envoyer du 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 trouver les points de terminaison comme s'il s'agissait de pods Kubernetes normaux, vous pouvez donc maintenant accéder à la base de données à l'aide d'une simple chaîne de connexion au nom ci-dessus mongodb: // mongo. Cependant, 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 les points de terminaison avec la nouvelle adresse IP, et vos applications n'auront pas besoin d'être modifiées de manière supplémentaire.

Si vous utilisez une base de données hébergée sur un hôte tiers, les propriétaires de l'hôte vous ont probablement fourni un URI d'identifiant de ressource unifié pour la connexion. Donc, si vous avez reçu une adresse IP, 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 l'hôte mLab.



L'un d'eux est une base de données de développeurs et l'autre est une base de données de production. Les chaînes de connexion pour ces bases de données sont les suivantes: mLab vous fournit un URI dynamique et un port dynamique. Comme vous pouvez le voir, ils sont différents.



Pour ignorer cela, nous utilisons Kubernetes et nous connectons à la base de données des développeurs. Vous pouvez créer un nom de service Kubernetes externe, qui vous fournira un service statique qui redirigera le trafic vers le service externe.



Ce service effectuera une simple redirection CNAME au niveau du noyau, qui aura 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 s'applique uniquement aux ports statiques et ne peut pas être utilisée avec des ports dynamiques. Mais le niveau gratuit mLab Free, par défaut, fournit à l'utilisateur un numéro de port dynamique, et vous ne pouvez pas le modifier. Cela signifie que pour dev et prod, vous avez besoin de différentes lignes de commande de connexion. La mauvaise nouvelle est que vous devrez 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 de l'URI. Si vous exécutez la commande nslookup, hostname ou ping l'URI, vous pouvez obtenir l'adresse IP de la base de données. Si, en même temps, le service vous renvoie plusieurs adresses IP, toutes ces adresses peuvent être utilisées aux extrémités de l'objet.



Gardez à l'esprit que les adresses IP URI peuvent changer sans préavis, il est donc très risqué de les utiliser dans prod. En utilisant 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 mappage des ressources externes aux ressources internes, vous donne la possibilité d'utiliser de manière flexible ces services au sein du cluster à l'avenir tout en minimisant les efforts de refactoring. Il facilite également la gestion et donne un aperçu des services externes utilisés par votre entreprise.

A suivre très prochainement ...

Un peu de publicité :)

Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en recommandant à vos amis des VPS basés sur le cloud pour les développeurs à partir de 4,99 $ , un analogue unique de serveurs d'entrée de gamme que nous avons inventés pour vous: Toute la vérité sur les VPS (KVM) E5-2697 v3 (6 cœurs) 10 Go DDR4 480 Go SSD 1 Gbit / s à partir de 19 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).

Dell R730xd 2 fois moins cher au centre de données Equinix Tier IV à Amsterdam? Nous avons seulement 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV à partir de 199 $ aux Pays-Bas!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99 $! En savoir plus sur la création d'un bâtiment d'infrastructure. classe c utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?