Service Mesh léger
Une solution Ingress (matérielle, virtualisée ou conteneurisée) effectue généralement des fonctions de proxy L7 pour le trafic nord-sud (N-S). L'architecture Service Mesh lite utilise la même solution Ingress pour gérer également le trafic est-ouest.
Dans un déploiement Kubernetes standard, le trafic est-ouest (E-O) transite par le kube-proxy intégré déployé dans chaque nœud. Kube-proxy est un proxy L4 qui ne peut effectuer qu'un équilibrage de charge basé sur TCP/UDP et ne peut pas offrir les avantages fournis par un proxy L7.
NetScaler (MPX, VPX ou CPX) peut offrir les avantages d'un proxy L7 pour le trafic E-O, tels que :
-
TLS mutuel et déchargement SSL.
-
Routage basé sur le contenu, autoriser ou bloquer le trafic en fonction des paramètres d'en-tête HTTP et HTTPS.
-
Algorithmes d'équilibrage de charge avancés (moins de connexions ou temps de réponse le plus court).
-
Observabilité du trafic est-ouest en mesurant les signaux d'or (erreurs, latences, saturation, volume de trafic). NetScaler Console Service Graph est une solution d'observabilité pour surveiller et déboguer les microservices.
Une architecture Service Mesh (telle qu'Istio ou LinkerD) est complexe à gérer. L'architecture Service Mesh lite est une version légère et beaucoup plus simple à mettre en œuvre pour atteindre les mêmes exigences.
Pour configurer la communication est-ouest avec NetScaler CPX dans une architecture Service Mesh lite, vous devez d'abord comprendre comment le kube-proxy est configuré pour gérer le trafic est-ouest.
Communication est-ouest avec kube-proxy
Lorsque vous créez un déploiement Kubernetes pour un microservice, Kubernetes déploie un ensemble de pods basé sur le nombre de réplicas. Pour accéder à ces pods, vous créez un service Kubernetes qui fournit une abstraction pour accéder à ces pods. L'abstraction est fournie en attribuant une adresse IP de cluster au service.
Le DNS Kubernetes est renseigné avec un enregistrement d'adresse qui mappe le nom du service avec l'adresse IP du cluster. Ainsi, lorsqu'une application, par exemple
tea, souhaite accéder à un microservice nommé coffee, alors le DNS renvoie l'adresse IP du cluster du service coffee à l'application tea. L'application tea initialise une connexion qui est ensuite interceptée par kube-proxy pour l'équilibrer vers un ensemble de pods coffee.
Communication est-ouest avec NetScaler CPX dans l'architecture Service Mesh Lite
L'objectif est d'insérer le NetScaler CPX dans le chemin est-ouest et d'utiliser les règles Ingress pour contrôler ce trafic.
Effectuez les étapes suivantes pour configurer la communication est-ouest avec NetScaler CPX.
Étape 1 : Modifier la définition du service coffee pour qu'elle pointe vers NetScaler CPX
Pour que NetScaler CPX gère le trafic est-ouest, le FQDN du microservice (par exemple,
coffee) doit pointer vers l'adresse IP du NetScaler CPX au lieu de l'adresse IP de cluster du microservice cible (coffee). (Ce déploiement de NetScaler CPX peut être le même que le dispositif NetScaler CPX Ingress.) Après cette modification, lorsqu'un pod du cluster Kubernetes résout le FQDN du service coffee, l'adresse IP du NetScaler CPX est renvoyée.
Remarque :
Si vous déployez un service mesh lite pour afficher le graphique de service dans NetScaler Console à des fins d'observabilité, vous devez ajouter l'étiquette
citrix-adc: cpx à tous les services de votre application qui pointent vers l'adresse IP du NetScaler CPX après avoir modifié le service.
Étape 2 : Créer un service sans tête nommé coffee-headless pour les pods du microservice coffee
Puisque vous avez modifié le service
coffee pour qu'il pointe vers NetScaler CPX, vous devez créer un service supplémentaire qui représente le déploiement du microservice coffee.
Voici un exemple de ressource de service sans tête :
apiVersion: v1
kind: Service
metadata:
name: coffee-headless
spec:
#headless Service
clusterIP: None
ports:
- name: coffee-443
port: 443
targetPort: 443
selector:
name: coffee-deployment
Étape 3 : Créer une ressource Ingress avec des règles pour le service coffee-headless
Avec les modifications des étapes précédentes, vous êtes maintenant prêt à créer un objet Ingress qui configure le NetScaler CPX pour contrôler le trafic est-ouest vers les pods du microservice coffee.
Voici un exemple de ressource Ingress :
En utilisant la méthodologie d'équilibrage de charge Ingress habituelle avec ces modifications, NetScaler CPX peut désormais équilibrer la charge du trafic est-ouest. Les diagrammes suivants montrent comment l'architecture NetScaler CPX Service Mesh Lite fournit un proxy L7 pour la communication est-ouest entre les microservices
tea et coffee à l'aide des règles Ingress :
Communication est-ouest avec NetScaler MPX ou VPX dans l'architecture Service Mesh lite
NetScaler MPX ou VPX agissant comme un Ingress peut également équilibrer la charge de la communication de microservices est-ouest de manière similaire à ce qui a été mentionné dans la section précédente, avec de légères modifications. La procédure suivante montre comment y parvenir.
Étape 1 : Créer un service externe résolvant le nom d'hôte coffee vers l'adresse IP de NetScaler MPX/VPX
Il existe deux façons de procéder. Vous pouvez ajouter un service externe mappant un nom d'hôte ou en utilisant une adresse IP.
Mappage par un nom d'hôte (CNAME)
-
Créez un nom de domaine pour l'adresse IP du point de terminaison Ingress (adresse IP du serveur virtuel Content Switching) dans NetScaler MPX ou VPX (par exemple,
myadc–instance1.us-east-1.mydomain.com) et mettez-le à jour dans votre serveur DNS. -
Créez un service Kubernetes pour
coffeeavecexternalNamecommemyadc–instance1.us-east-1.mydomain.com. -
Maintenant, lorsqu'un pod recherche le microservice
coffee, unCNAME(myadc–instance1.us-east-1.mydomain.com) est renvoyé.
kind: Service
apiVersion: v1
metadata:
name: coffee
spec:
type: ExternalName
externalName: myadc–instance1.us-east-1.mydomain.com
Mappage d'un nom d'hôte à une adresse IP
Lorsque vous souhaitez que votre application utilise le nom d'hôte
coffee qui redirigera vers l'adresse IP virtuelle hébergée dans NetScaler MPX ou VPX, vous pouvez créer ce qui suit :
---
kind: "Service"
apiVersion: "v1"
metadata:
name: "coffee"
spec:
ports:
-
name: "coffee"
protocol: "TCP"
port: 80
---
kind: "Endpoints"
apiVersion: "v1"
metadata:
name: "coffee"
subsets:
-
addresses:
-
ip: "1.1.1.1" # Ingress IP in MPX
ports:
-
port: 80
name: "coffee"
Étape 2 : Créer un service sans tête pour les pods de microservices
Puisque vous avez modifié le service coffee pour qu'il pointe vers NetScaler MPX, vous devez créer un service supplémentaire qui représente le déploiement du microservice coffee.
Étape 3 : Créer une ressource Ingress
Créez une ressource Ingress en utilisant l'annotation
ingress.citrix.com/frontend-ip où la valeur correspond à l'adresse IP du point de terminaison Ingress dans NetScaler MPX ou VPX.
Maintenant, vous pouvez créer un objet Ingress qui configure le NetScaler MPX ou VPX pour contrôler le trafic est-ouest vers les pods du microservice de café.
Voici un exemple de ressource Ingress :
En utilisant la méthodologie habituelle d'équilibrage de charge Ingress avec ces modifications, NetScaler MPX peut désormais équilibrer le trafic est-ouest. Le diagramme suivant montre un NetScaler MPX ou VPX configuré comme proxy N-S et E-W à l'aide des règles Ingress.
Déploiement automatisé d'applications dans Service Mesh lite
Pour déployer une application dans une architecture Service Mesh lite, vous devez effectuer plusieurs tâches manuellement. Cependant, lorsque vous souhaitez déployer plusieurs applications composées de plusieurs microservices, il existe un moyen plus simple de déployer les services dans une architecture Service Mesh lite. NetScaler® vous offre un moyen automatisé de générer des fichiers YAML prêts à être déployés.
Ce document fournit des informations sur la façon de générer tous les fichiers YAML nécessaires au déploiement de Service Mesh lite à partir de vos fichiers YAML existants à l'aide du script fourni par NetScaler.