Je suis nouveau dans les microservices et je souhaite comprendre quelle est la meilleure façon de mettre en œuvre le comportement ci-dessous dans les microservices déployés sur Kubernetes:
Il existe 2 clusters K8 différents. Le microservice B est déployé sur les deux clusters.
Désormais, si un microservice A appelle le microservice B et que les pods de B ne sont pas disponibles dans le cluster 1, alors l'appel doit aller à B du cluster 2.
J'aurais pu imaginer implémenter cette fonctionnalité en utilisant Netflix OSS mais ici je ne l'utilise pas.
De plus, en laissant de côté la communication inter-cluster pendant une seconde, comment dois-je communiquer entre les microservices?
Une façon que je connais est de créer un service Kubernetes de type NodePort pour chaque microservice et d'utiliser l'IP et le nodePort dans le microservice appelant.
Question: Que faire si quelqu'un supprime le service K8s du microservice cible? Un nouveau nodePort sera assigné aléatoirement par K8s lors de la recréation du service K8s, puis à nouveau je devrai revenir à mon microservice appelant et changer le nodePort du microservice cible. Comment puis-je dissocier le nodePort?
J'ai fait des recherches sur les kubedns, mais il semble que cela ne fonctionne que dans un cluster.
J'ai des connaissances très limitées sur Istio et Kubernetes Ingress. Est-ce que l'un de ces éléments fournit quelque chose que je recherche?
Désolé pour une longue question. Toutes sortes de conseils seront très utiles.
3 Réponses :
Utilisez l'entrée pour la communication entre les clusters et utilisez le service de type IP de cluster pour la communication intra-cluster entre deux micro services.
Merci d'avoir répondu. Pourriez-vous s'il vous plaît parcourir les commentaires que j'ai postés ci-dessus en réponse à KoopaKiller?
Vous pouvez exposer votre application en utilisant des services, il existe des types de services que vous pouvez utiliser:
ClusterIP: Expose le service sur une adresse IP interne au cluster. Le choix de cette valeur rend le service accessible uniquement à partir du cluster. Il s'agit duServiceTypepar défaut .ExternalName: Maps le Service au contenu du champexternalName(par exemplefoo.bar.example.com), en renvoyant un enregistrementCNAME
Pour la communication interne , utilisez le type de service ClusterIP , et vous pouvez configurer le service DNS pour vos applications à la place d'une adresse IP.
Ie: un service appelé my-app-1 pourrait être atteint en interne en utilisant le dns http: // my-app-1 ou avec fqdn http: // mon-app-1. .
Pour la communication externe , vous pouvez utiliser NodePort ou LoadBalancer .
NodePort est utile lorsque vous avez peu de nœuds et que vous connaissez l'adresse IP de chacun d'entre eux. Et oui, grâce aux documentation du service , vous pouvez spécifier un port spécifique numéro:
Si vous souhaitez un numéro de port spécifique, vous pouvez spécifier une valeur dans le champ
nodePort. Le plan de contrôle vous attribuera ce port ou signalera que la transaction API a échoué. Cela signifie que vous devez vous occuper des éventuelles collisions de port. Vous devez également utiliser un numéro de port valide, qui se trouve dans la plage configurée pour l'utilisation de NodePort.
LoadBalancer vous donne plus de flexibilité, car vous n'avez pas besoin de connaître toutes les ips des nœuds, vous devez juste connaître l'IP et le port du service. Mais LoadBalancer n'est pris en charge que dans les fournisseurs de cloud, si vous souhaitez l'implémenter dans un cluster bare-metal, je vous recommande de jeter un œil dans MetalLB .
Enfin, il existe une autre option qui consiste à utiliser ingress , à mon avis, c'est le meilleur moyen d'exposer des applications HTTP en externe, car vous pouvez créer des règles par chemin et par hôte, et cela vous donne beaucoup plus de flexibilité que les services. Mais seul HTTP / HTTPS est pris en charge, si vous avez besoin de TCP, allez dans Services
Je vous recommande de consulter ces liens pour comprendre en profondeur le fonctionnement des services et des entrées:
Merci beaucoup d'avoir pris le temps de répondre. Je ne peux certainement pas utiliser un service de type LoadBalancer car j'ai des clusters Kubernetes bare metal sans aucun fournisseur de cloud. Je ne veux pas utiliser le type NodePort car si mS1 sur cluster1 parle à mS2 sur cluster2 et si le service de mS2 est supprimé ou si le nodePort change par quelque moyen que ce soit, je devrai changer le nodePort de mS2 dans la configuration de mS1, ce qui est pénible . Je veux découpler de nodePort. ClusterIP ne me sera pas utile car je souhaite une communication de service inter-cluster.
Je passais par Istio, mais il s'est avéré qu'il n'utilise que le mécanisme de découverte de service des K8 natifs. J'ai essayé d'utiliser Eureka et Ribbon pour la découverte de services, mais il s'est avéré que les noms des pods Kubernetes sont enregistrés dans Eureka au lieu des services Kubernetes. Donc, Ribbon ne comprend pas le nom du pod. J'explore Consul en ce moment, mais il semble qu'il se comportera à peu près comme Eureka uniquement. Dois-je écrire mon propre mécanisme de découverte de services? Je pourrais créer un microservice Service Registry qui enregistrera tous les microservices, puis effectuera une résolution d'URL à l'aide d'un client personnalisé.
Vous pouvez utiliser le type LoadBalancer dans un cluster bare-metal, il vous suffit d'installer MetalLB. Avec MetalLB, vous pouvez configurer une plage d'adresses IP à partir de votre réseau et le service obtiendra cette adresse IP et sera accessible à partir de votre réseau. Si l'une de ces solutions n'est pas réalisable pour vous, vous pouvez écrire votre propre découverte de service. Donnez une chance d'essayer MetalLB, peut-être que cela vous aidera et gagnera du temps pour écrire votre découverte de service personnalisé.
J'ai exploré Metallb et j'étais tellement soulagé quand je l'ai vu pour la première fois. Mais en parcourant sa documentation, j'ai trouvé ceci: «La majorité des changements de code, ainsi que la direction générale du projet, est un effort personnel d'une personne, travaillant sur MetalLB pendant son temps libre, comme la motivation le permet. signifie qu'actuellement, le support et le développement de nouvelles fonctionnalités sont principalement à la merci de la disponibilité et des ressources d'une seule personne. Vous devez définir vos attentes de manière appropriée. " Je ne peux donc évidemment pas utiliser Metallb dans mes systèmes de production.
Je pense essayer Consul et Linkerd. Voyez ce que ceux-ci peuvent offrir.
Votre conception est assez proche de l'exemple Istio Multicluster .
En suivant les étapes du Istio multicluster lab vous obtiendrez deux clusters avec un plan de contrôle Istio qui équilibrent le trafic entre deux services ClusterIP situés dans deux clusters Kubernetes indépendants.
La configuration surveille la charge du trafic, mais en réécrivant le code du module de contrôleur, vous pouvez le configurer pour basculer le trafic vers le deuxième cluster si le service du cluster One n'a pas de points de terminaison (tous les pods du certain type ne sont pas à l'état Prêt).
Ce n'est qu'un exemple, vous pouvez modifier istiowatcher.go code pour implémenter la logique de votre choix.
Il existe une une solution plus avancée utilisant Admiral en tant qu'outil d'automatisation de gestion Istio Multicluster.
Admiral fournit une configuration automatique pour qu'un maillage Istio couvrant plusieurs clusters fonctionne comme un maillage unique basé sur un identifiant de service unique qui associe des charges de travail s'exécutant sur plusieurs clusters à un service. Il fournit également le provisionnement et la synchronisation automatiques de la configuration Istio entre les clusters. Cela supprime la charge des développeurs et des opérateurs de maillage, ce qui aide à évoluer au-delà de quelques clusters.
Cette solution résout ces exigences clés pour l'infrastructure Kubernetes moderne:
Cette solution peut devenir très utile à grande échelle.
Merci d'avoir répondu. Pouvez-vous s'il vous plaît parcourir la discussion ci-dessous avec @KoopaKiller? Il a plus d'informations sur ce que je veux exactement. Apprécier ton aide !
J'ai lu tous vos commentaires et je pense que le laboratoire répond à presque toutes vos questions si vous passez du temps à faire toutes les étapes. Cela peut être un peu plus compliqué de le faire sur site, mais je suis sûr que l'offre gratuite de GCP est suffisante pour terminer l'atelier.
Toute raison que quelqu'un a révélé la question sans même prendre la peine d'ajouter un commentaire?
Pourquoi ne pas configurer un réseau virtuel et autoriser certains sous-domaines à communiquer entre eux à l'aide de l'adresse IP Endpoint. Par exemple, dans le monde Azure, créez un vnet et une passerelle vnet pour chaque cluster kubernates, puis créez une connexion entre eux. Nous l'avons fait sur GCP et Azure. A fonctionné à merveille.