Pour effectuer un déploiement canari sur l'ensemble d'une chaîne d'appels ou appliquer une isolation des versions, utilisez les voies de trafic en mode strict afin d'isoler les versions pertinentes (ou d'autres attributs) d'une application dans un environnement d'exécution indépendant. Cette approche garantit que seul le trafic répondant à des conditions spécifiques est acheminé vers la nouvelle version du service, améliorant ainsi la stabilité et le contrôle de votre processus de déploiement.
Prérequis
-
Vous avez créé une instance ASM de type Enterprise Edition ou Ultimate Edition, version 1.18.2.111 ou ultérieure. Pour plus d'informations, consultez les rubriques Créer une instance ASM ou Mettre à niveau une instance ASM.
RemarqueSi la version de votre instance est comprise entre la 1.17.2.22 (incluse) et la 1.18.2.111 (exclue), consultez la rubrique Utiliser la fonctionnalité de gestion du trafic en mode voie.
Vous avez créé une passerelle ingress ASM nommée ingressgateway. Pour plus d'informations, consultez la rubrique Créer un service de passerelle ingress.
-
Vous avez créé une passerelle nommée ingressgateway dans le namespace istio-system. Pour plus d'informations, consultez la rubrique Gérer les passerelles.
Exemple
Cet exemple utilise trois services (mocka, mockb et mockc) pour créer trois voies (s1, s2 et s3) représentant trois versions de la chaîne d'appels de service.
Étape 1 : Déployer les exemples de services
-
Activez l'injection automatique du proxy sidecar pour le namespace default. Pour plus de détails, consultez la rubrique Activer l'injection automatique du proxy sidecar.
Pour plus d'informations sur l'injection automatique, consultez la rubrique Configurer les politiques d'injection sidecar.
-
Exécutez les commandes suivantes dans votre cluster Container Service for Kubernetes (ACK) pour déployer les exemples de services :
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v1/mock-tracing-v1.yaml kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v2/mock-tracing-v2.yaml kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v3/mock-tracing-v3.yaml
Étape 2 : Créer un groupe de voies et des voies
-
Créez un groupe de voies.
Connectez-vous à la console ASM. Dans le volet de navigation de gauche, sélectionnez .
Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, sélectionnez .
-
Sur la page Traffic Lane, cliquez sur Create Swimlane Group. Dans le panneau Create Swimlane Group, configurez les paramètres puis cliquez sur OK.
Paramètre
Description
Name of swim lane group
Pour cet exemple, saisissez test.
Entrance gateway
Sélectionnez ingressgateway.
Lane Mode
Sélectionnez Strict Mode.
Swimlane service
Sélectionnez le cluster Kubernetes cible et le namespace default. Dans la liste ci-dessous, sélectionnez les services mocka, mockb et mockc, puis cliquez sur l'icône
pour les ajouter à la section selected.
-
Créez les voies s1, s2 et s3 et associez-les respectivement aux versions v1, v2 et v3.
Dans la section Traffic Lane de la page Traffic Rule Definition, cliquez sur Create swimlanes.
-
Dans la boîte de dialogue Create swimlanes, configurez les paramètres puis cliquez sur OK.
Paramètre
Description
Swimlane Name
Définissez les noms des voies sur s1, s2 et s3.
Configure Service Tag
Label Key : Sélectionnez ASM_TRAFFIC_TAG.
Label Value : Sélectionnez respectivement v1, v2 et v3 pour les voies s1, s2 et s3.
Une fois les trois voies créées, chacune contient les services de voie
mocka,mockbetmockc.Après la création des voies, ASM génère automatiquement un DestinationRule et un VirtualService correspondants pour chaque service du groupe de voies. Pour afficher ces ressources, accédez à ou VirtualService dans le volet de navigation de gauche.
-
Créez une règle de trafic ingress pour chaque voie.
Dans la section Traffic Lane de la page Traffic Rule Definition, repérez la voie cible et cliquez sur Ingress traffic rules dans la colonne Actions.
-
Dans la boîte de dialogue Add drainage rule, configurez les paramètres puis cliquez sur OK.
Dans cet exemple, l'URI ingress pour les services de voie est
/mock. Par conséquent, vous configurez la même règle de trafic ingress pour chaque voie.Paramètre
Description
Ingress service
Sélectionnez mocka.default.svc.cluster.local.
Ingress traffic rules
Définissez Name sur r1 et Domain Name sur *.
Matching request URI
Définissez Method sur Exact et Content sur /mock.
Add Header Matching Rule
Cliquez sur Add Header Matching Rule. Définissez Name sur x-asm-prefer-tag et Method sur Exact. Pour les trois voies, définissez respectivement Content sur s1, s2 et s3.
Une fois les règles de trafic ingress créées, la page Traffic Rule Definition se met à jour. Les voies sont désormais balisées s1, s2 et s3, et les services de voie (mocka, mockb et mockc) sont activés pour toutes les voies.
Après la création des règles, un VirtualService implémentant la règle de trafic ingress est automatiquement créé pour chaque voie.
Étape 3 : Vérifier le déploiement canari de bout en bout
Obtenez l'adresse IP publique de la passerelle ingress ASM. Pour plus d'informations, consultez la rubrique Obtenir l'adresse de la passerelle ingress ASM.
-
Exécutez la commande suivante pour définir une variable d'environnement.
Remplacez
xxx.xxx.xxx.xxxpar l'adresse IP obtenue à l'étape précédente.export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx -
Vérifiez que le déploiement canari de bout en bout fonctionne comme prévu.
-
Exécutez la commande suivante pour tester le routage vers la voie s1.
La valeur
s1pourx-asm-prefer-tagspécifie la voie s1 configurée à l'étape 2.for i in {1..100}; do curl -H 'x-asm-prefer-tag: s1' http://${ASM_GATEWAY_IP}/mock ; echo ''; sleep 1; done;Résultat attendu :
-> mocka(version: v1, ip: 172.17.0.54)-> mockb(version: v1, ip: 172.17.0.129)-> mockc(version: v1, ip: 172.17.0.130)Le résultat indique que les requêtes comportant l'en-tête HTTP
x-asm-prefer-tag: s1sont acheminées vers les services de la voie s1. -
Exécutez la commande suivante pour tester le routage vers la voie s2.
La valeur
s2pourx-asm-prefer-tagspécifie la voie s2 configurée à l'étape 2.for i in {1..100}; do curl -H 'x-asm-prefer-tag: s2' http://${ASM_GATEWAY_IP}/mock ; echo ''; sleep 1; done;Résultat attendu :
-> mocka(version: v2, ip: 172.17.0.9)-> mockb(version: v2, ip: 172.17.0.126)-> mockc(version: v2, ip: 172.17.0.128)Le résultat indique que les requêtes comportant l'en-tête HTTP
x-asm-prefer-tag: s2sont acheminées vers les services de la voie s2. -
Exécutez la commande suivante pour tester le routage vers la voie s3.
La valeur
s3pourx-asm-prefer-tagspécifie la voie s3 configurée à l'étape 2.for i in {1..100}; do curl -H 'x-asm-prefer-tag: s3' http://${ASM_GATEWAY_IP}/mock ; echo ''; sleep 1; done;Résultat attendu :
-> mocka(version: v3, ip: 172.17.0.132)-> mockb(version: v3, ip: 172.17.0.127)-> mockc(version: v3, ip: 172.17.0.69)Le résultat indique que les requêtes comportant l'en-tête HTTP
x-asm-prefer-tag: s3sont acheminées vers les services de la voie s3.
-
Acheminer le trafic avec un service virtuel personnalisé
La fonctionnalité de voie de trafic inclut une capacité intégrée permettant de configurer des règles de routage des requêtes. Lorsque vous créez ces règles, ASM génère automatiquement un service virtuel correspondant sur la passerelle ingress. Cela permet à la passerelle ingress d'acheminer les requêtes vers différentes voies de trafic.
Les règles de routage des requêtes pour une voie de trafic font correspondre les requêtes en fonction des en-têtes de requête et des chemins de requête. Pour mettre en œuvre des conditions de correspondance plus complexes ou un comportement de routage personnalisé, vous pouvez créer un service virtuel personnalisé.
Lorsque vous utilisez un service virtuel personnalisé pour acheminer le trafic vers une voie de trafic, évitez de créer des règles de routage des requêtes intégrées pour cette même voie. Un service virtuel personnalisé peut entrer en conflit avec les règles intégrées et provoquer une distribution du trafic imprévisible ou erronée.
Créer un service virtuel pour la passerelle ASM
-
Pour poursuivre avec le scénario d'exemple, au lieu de terminer l'étape 2,3, Créer des règles de routage des requêtes pour les trois voies de trafic, créez un service virtuel avec la configuration suivante. Pour plus d'informations, consultez la rubrique Gérer les services virtuels.
apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: swimlane-ingress-vs-custom namespace: istio-system spec: gateways: - istio-system/ingressgateway hosts: - '*' http: - match: # This rule matches requests with the exact header 'env: dev'. - headers: env: exact: dev name: dev-route route: - destination: host: mocka.default.svc.cluster.local # The destination service for the traffic. subset: s2 # Set 'subset' to the name of the traffic lane. weight: 50 - destination: host: mocka.default.svc.cluster.local # The destination service for the traffic. subset: s3 # Set 'subset' to the name of the traffic lane. weight: 50 - name: base-route route: - destination: host: mocka.default.svc.cluster.local # The destination service for the traffic. subset: s1 # Set 'subset' to the name of the traffic lane. -
Exécutez les commandes de l'Étape 3 : Vérifier le déploiement canari de bout en bout. Le résultat attendu lors de l'accès aux voies de trafic s1, s2 et s3 est le suivant :
-> mocka(version: v1, ip: 192.168.0.50)-> mockb(version: v1, ip: 192.168.0.46)-> mockc(version: v1, ip: 192.168.0.48)Exécutez la commande suivante pour vérifier le comportement lors de l'accès à la voie de trafic s1 avec l'en-tête de requête
env: dev.for i in {1..100}; do curl -H 'x-asm-prefer-tag: s1' -H 'env: dev' http://${ASM_GATEWAY_IP}/mock ; echo ''; sleep 1; done;Résultat attendu :
Le résultat montre que pour les requêtes incluant l'en-tête
env: dev, le trafic est réparti approximativement à 50/50 entre les voies de trafic s2 et s3. Toutes les autres requêtes sont acheminées vers la voie de trafic s1.
Le service virtuel précédent définit une règle de routage personnalisée sur la passerelle ASM pour transférer le trafic vers différentes voies de trafic. Lorsque vous utilisez un service virtuel personnalisé pour acheminer le trafic vers une voie en mode strict, il vous suffit de spécifier le nom de la voie cible dans le champ subset de la destination de la route. Une fois qu'une requête entre dans une voie de trafic, tous les appels suivants dans la chaîne de requêtes restent dans cette voie.
Créer un service virtuel pour les sidecars
En plus de définir des règles sur la passerelle ingress, vous pouvez également créer un service virtuel qui s'applique à tous les sidecars. Cela vous permet de définir des règles de routage des requêtes qui contrôlent la manière dont les services du cluster accèdent à d'autres services dans une voie de trafic. Contrairement à un service virtuel pour une passerelle, un service virtuel basé sur un sidecar omet le champ gateway et le champ hosts spécifie le FQDN du service mocka au sein du cluster. Voici un exemple de fichier YAML :
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: swimlane-ingress-vs-custom
namespace: istio-system
spec:
hosts:
- mocka.default.svc.cluster.local
http:
- match: # This rule matches requests with the exact header 'env: dev'.
- headers:
env:
exact: dev
name: dev-route
route:
- destination:
host: mocka.default.svc.cluster.local # The destination service for the traffic.
subset: s2 # Set 'subset' to the name of the traffic lane.
weight: 50
- destination:
host: mocka.default.svc.cluster.local # The destination service for the traffic.
subset: s3 # Set 'subset' to the name of the traffic lane.
weight: 50
- name: base-route
route:
- destination:
host: mocka.default.svc.cluster.local # The destination service for the traffic.
subset: s1 # Set 'subset' to the name of the traffic lane.-
Exécutez la commande suivante pour vérifier le comportement lors de l'accès au service mocka depuis un sidecar sans l'en-tête de requête
env: dev.kubectl exec -it deploy/sleep -c sleep -- sh -c 'for i in $(seq 1 100); do curl http://mocka:8000; echo ""; sleep 1; done;'Résultat attendu :
-> mocka(version: v1, ip: 192.168.0.50)-> mockb(version: v1, ip: 192.168.0.46)-> mockc(version: v1, ip: 192.168.0.48)Le résultat montre que sans l'en-tête de requête
env: dev, toutes les requêtes suivent la chaîne d'appels v1, ce qui confirme que le trafic est acheminé vers la voie de trafic s1. -
Exécutez la commande suivante pour vérifier le comportement lorsque la requête inclut l'en-tête de requête
env: dev.kubectl exec -it deploy/sleep -c sleep -- sh -c 'for i in $(seq 1 100); do curl -H "env: dev" http://mocka:8000; echo ""; sleep 1; done;'Résultat attendu :
Le résultat est cohérent avec celui obtenu via le service virtuel basé sur la passerelle. Lorsque vous accédez au service mocka avec l'en-tête de requête
env: dev, le trafic est réparti approximativement à 50/50 entre les voies de trafic s2 et s3.
Le principe de fonctionnement est identique à celui du service virtuel basé sur la passerelle. Lorsqu'un autre service du cluster appelle le service mocka, l'ensemble de la chaîne de requêtes suivante reste dans la voie de trafic sélectionnée.
Documentation connexe
Une voie de trafic dispose de deux modes : strict et permissif. Pour une comparaison de ces modes, consultez la rubrique Présentation des voies de trafic.
Le mode permissif offre une plus grande flexibilité pour les voies de trafic, en particulier lorsque votre application utilise des en-têtes de requête transitaires dans une trace. Par exemple, vous pouvez créer un environnement de test qui inclut de nouvelles versions uniquement pour certains services de la trace. Pour plus de détails, consultez la rubrique Utiliser des voies de trafic en mode permissif pour la gestion du trafic de bout en bout.
Vous pouvez implémenter des voies de trafic à l'aide de règles de trafic telles que VirtualService et DestinationRule. Vous pouvez également configurer le basculement de trafic pour acheminer le trafic vers une application de secours désignée lorsqu'une application d'une version spécifique (ou possédant d'autres caractéristiques) n'est pas disponible. Pour plus d'informations, consultez la rubrique Configurer des voies de trafic et le basculement de trafic à l'aide de règles de trafic.