Migrate and manage TCP traffic with ASM - Alibaba Cloud Service Mesh

Le centre de gestion du trafic Service Mesh (ASM) assure une migration fluide du trafic des applications TCP lors de l'optimisation de la topologie réseau, du déploiement horizontal des serveurs d'applications ou de l'ajustement du trafic de service. Cette fonctionnalité garantit la continuité des activités et la haute disponibilité. Cette rubrique s'appuie sur la tâche Istio TCP-Traffic-Shifting pour décrire le basculement progressif du trafic entre deux versions d'un service TCP.

Prérequis

Services cloud et ressources

Les services Alibaba Cloud suivants sont activés :
- Container Service for Kubernetes (ACK)
- Classic Load Balancer (CLB)
Un cluster ACK a été créé. Pour plus d'informations, consultez les rubriques Créer un cluster ACK managé et Créer un cluster ACK dédié (obsolète).
Le cluster ACK a été ajouté à une instance ASM. Pour plus d'informations, consultez les rubriques Créer une instance ASM et Ajouter un cluster à une instance ASM.

Outils client locaux

Le client kubectl est installé et connecté au cluster Kubernetes. Pour plus d'informations, consultez la rubrique Obtenir le fichier kubeconfig et utiliser kubectl pour se connecter au cluster.
Un client telnet et Docker sont disponibles sur l'ordinateur utilisé pour la vérification. L'étape 4 utilise telnet pour établir une connexion TCP au service tcp-echo, et l'étape 5 utilise docker run pour envoyer des requêtes de test.

Étape 1 : Déployer l'exemple d'application

L'exemple d'application tcp-echo s'exécute en deux versions : la version v1 préfixe chaque réponse par one, tandis que la version v2 utilise le préfixe two. Ce préfixe permet d'identifier la version qui traite une requête, ce qui facilite l'observation de la répartition du trafic ultérieurement dans cette rubrique.

Déployez les deux versions de l'application tcp-echo.

Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Workloads > Deployments.
Sur la page Deployments, sélectionnez le Namespace cible en haut de la page, puis cliquez sur Create Resources in YAML dans le coin supérieur droit.

Définissez Sample Template sur Custom, collez le code YAML suivant dans la zone de texte Template, puis cliquez sur Create.

Afficher le fichier YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tcp-echo-v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tcp-echo
      version: v1
  template:
    metadata:
      labels:
        app: tcp-echo
        version: v1
    spec:
      containers:
      - name: tcp-echo
        image: docker.io/istio/tcp-echo-server:1.1
        imagePullPolicy: IfNotPresent
        args: [ "9000", "one" ]
        ports:
        - containerPort: 9000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: tcp-echo-v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tcp-echo
      version: v2
  template:
    metadata:
      labels:
        app: tcp-echo
        version: v2
    spec:
      containers:
      - name: tcp-echo
        image: docker.io/istio/tcp-echo-server:1.1
        imagePullPolicy: IfNotPresent
        args: [ "9000", "two" ]
        ports:
        - containerPort: 9000

Les deux nouvelles versions de l'application tcp-echo apparaissent sur la page Deployments.

Créez un Service pour exposer l'application tcp-echo vers l'extérieur.

Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Network > Services.
Sur la page Services, sélectionnez le Namespace cible en haut de la page, puis cliquez sur Create dans le coin supérieur droit.

Dans la boîte de dialogue Create Service, configurez les paramètres décrits dans le tableau suivant, puis cliquez sur Confirm.

Paramètre	Description
Service	Saisissez tcp-echo.
Service Type	Sélectionnez la méthode d'accès pour le Service. Les types pris en charge sont ClusterIP, NodePort et LoadBalancer. Remarque Headless Service ne peut être défini que lorsque Service Type est défini sur Cluster IP. Utilisez un Headless Service pour interagir avec d'autres systèmes de découverte de services plutôt que de vous lier à l'implémentation Kubernetes.
Backend	Définissez Name sur app et Value sur tcp-echo. Remarque Le Service utilise le libellé `app` du Deployment associé comme sélecteur, ce qui détermine le Deployment vers lequel le Kubernetes Service transfère le trafic. Étant donné que les Deployments `tcp-echo-v1` et `tcp-echo-v2` partagent le même libellé `app:tcp-echo`, le Service peut router le trafic vers l'un ou l'autre Deployment.
External Traffic Policy	Les options Local et Cluster sont prises en charge. Remarque External Traffic Policy ne peut être défini que lorsque le type de Service est Node Port ou Server Load Balancer.
Port Mapping	Dans cette rubrique, définissez Name sur tcp, Service Port et Container Port sur 9000, et Protocol sur TCP.
Annotations	Ajoutez une `annotation` au Service pour configurer les paramètres d'équilibrage de charge. Par exemple, `service.beta.kubernetes.io/alicloud-loadbalancer-bandwidth:20` définit la bande passante maximale du Service à 20 Mbit/s, ce qui permet de contrôler le trafic du Service. Pour plus d'informations sur les paramètres, consultez la rubrique Configurer une instance Classic Load Balancer (CLB) à l'aide d'annotations.
Label	Ajoutez un libellé pour identifier le Service.

Après la création du Service, le nouveau service tcp-echo apparaît sur la page Services.

Étape 2 : Configurer les règles de routage

Configurez une passerelle Istio, un VirtualService et une DestinationRule dans Service Mesh pour router tout le trafic vers la version v1 du service tcp-echo. La passerelle écoute sur le port 31400 ; le trafic externe n'atteindra ces règles qu'après l'ajout du port 31400 au service de passerelle d'entrée à l'étape 3.

Connectez-vous à la console ASM. Dans le volet de navigation de gauche, choisissez Service Mesh > Mesh Management.
Sur la page Mesh Management, localisez l'instance ASM à configurer. Cliquez sur le nom de l'instance ASM ou sur Manage dans la colonne Actions.
Créez une passerelle.
1. Sur la page de détails de l'instance ASM, choisissez ASM Gateways > Gateway dans le volet de navigation de gauche. Sur la page qui s'affiche, cliquez sur Create from YAML.
2. Sur la page Create, définissez Namespace sur default, sélectionnez n'importe quel Scenario Template, collez le code YAML suivant, puis cliquez sur Create.
```
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: tcp-echo-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 31400
      name: tcp
      protocol: TCP
    hosts:
    - "*"
```
Créez un VirtualService.
1. Sur la page de détails de l'instance ASM, choisissez Traffic Management Center > VirtualService dans le volet de navigation de gauche. Sur la page qui s'affiche, cliquez sur Create from YAML.
2. Sur la page Create, définissez Namespace sur default, sélectionnez n'importe quel Scenario Template, collez le code YAML suivant, puis cliquez sur Create.
```
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: tcp-echo
spec:
  hosts:
  - "*"
  gateways:
  - tcp-echo-gateway
  tcp:
  - match:
    - port: 31400
    route:
    - destination:
        host: tcp-echo
        port:
          number: 9000
        subset: v1
```
Créez une DestinationRule.
1. Sur la page de détails de l'instance ASM, choisissez Traffic Management Center > DestinationRule dans le volet de navigation de gauche. Sur la page qui s'affiche, cliquez sur Create from YAML.
2. Sur la page Create, définissez Namespace sur default, sélectionnez n'importe quel Scenario Template, collez le code YAML suivant, puis cliquez sur Create.
```
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: tcp-echo-destination
spec:
  host: tcp-echo
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
```

Étape 3 : Déployer une passerelle d'entrée

Important

Allouez une instance CLB à chaque Kubernetes Service. Si plusieurs Kubernetes Services partagent la même instance CLB, les risques et limitations suivants s'appliquent :

L'utilisation d'une instance CLB existante écrase de force ses écouteurs existants, ce qui peut rendre votre application inaccessible.
Vous ne pouvez pas réutiliser une instance CLB créée par Kubernetes via un Service. Seules les instances CLB créées manuellement dans la console ou via un appel d'API OpenAPI peuvent être réutilisées.
Plusieurs Services partageant la même instance CLB ne peuvent pas utiliser le même port d'écoute frontal. Sinon, un conflit de port se produit.
Lors de la réutilisation d'une instance CLB, Kubernetes utilise le nom de l'écouteur et le nom du groupe de serveurs virtuels comme identifiants uniques. Ne modifiez pas ces noms.
Vous ne pouvez pas réutiliser une instance CLB entre différents clusters.

Connectez-vous à la console ASM. Dans le volet de navigation de gauche, choisissez Service Mesh > Mesh Management.
Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, choisissez ASM Gateways > Ingress Gateway.

Sur la page Ingress Gateway, cliquez sur Create, effectuez la configuration, puis cliquez sur Create.

Le tableau suivant décrit certains éléments de configuration. Pour plus d'informations, consultez la rubrique Créer une passerelle d'entrée.

Paramètre

Description

Cluster

Sélectionnez le cluster dans lequel vous souhaitez déployer la passerelle d'entrée.

CLB instance type

Dans cette rubrique, sélectionnez Access over the Internet.

Sélectionner une instance CLB

Sélectionnez l'une des options suivantes. Use Existing CLB Instance : sélectionnez une instance dans la liste des instances CLB existantes. Create CLB Instance : cliquez sur Create SLB Instance et sélectionnez la spécification CLB requise dans la liste déroulante.

Port Mapping

Cliquez sur Add Port, définissez Name sur tcp et Service Port sur 31400.

Étape 4 : Vérifier le déploiement

Utilisez kubectl pour confirmer que le trafic vers le service tcp-echo est routé comme prévu.

Exécutez les commandes suivantes pour obtenir l'adresse et le port du service :

export INGRESS_HOST=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="tcp")].port}')

Exécutez la commande telnet pour envoyer une demande de connexion au service tcp-echo.

telnet $INGRESS_HOST $INGRESS_PORT

Trying xxx.xxx.xxx.xxx...
Connected to xxx.xxx.xxx.xxx.
Escape character is '^]'

Saisissez n'importe quelle chaîne de caractères et appuyez sur Entrée.

La chaîne renvoyée est préfixée par one, ce qui indique que le service tcp-echo est déployé et que tout le trafic est routé vers la version tcp-echo-v1.

Étape 5 : Router le trafic vers v2 par pondération

Cette étape route 20 % du trafic vers la version tcp-echo-v2 et les 80 % restants vers tcp-echo-v1.

Remarque

Avec un petit échantillon de 10 requêtes, les résultats ne montreront pas toujours exactement 2 requêtes sur 10 routées vers tcp-echo-v2. Toutefois, sur une période plus longue, le ratio global tend vers 20 %.

Modifiez la configuration VirtualService de l'instance ASM.

Sur la page de détails de l'instance ASM, choisissez Traffic Management Center > VirtualService dans le volet de navigation de gauche.
Sur la page VirtualService, localisez le service tcp-echo et cliquez sur YAML dans la colonne Actions.

Dans la zone de texte de la page Edit, saisissez le contenu YAML suivant, puis cliquez sur OK.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: tcp-echo
spec:
  hosts:
  - "*"
  gateways:
  - tcp-echo-gateway
  tcp:
  - match:
    - port: 31400
    route:
    - destination:
        host: tcp-echo
        port:
          number: 9000
        subset: v1
      weight: 80
    - destination:
        host: tcp-echo
        port:
          number: 9000
        subset: v2
      weight: 20

Exécutez la commande suivante pour envoyer 10 requêtes au service tcp-echo :

for i in {1..10}; do \
docker run -e INGRESS_HOST=$INGRESS_HOST -e INGRESS_PORT=$INGRESS_PORT -it --rm busybox sh -c "(date; sleep 1) | nc $INGRESS_HOST $INGRESS_PORT"; \
done

one Mon Nov 12 23:38:45 UTC 2018
two Mon Nov 12 23:38:47 UTC 2018
one Mon Nov 12 23:38:50 UTC 2018
one Mon Nov 12 23:38:52 UTC 2018
one Mon Nov 12 23:38:55 UTC 2018
two Mon Nov 12 23:38:57 UTC 2018
one Mon Nov 12 23:39:00 UTC 2018
one Mon Nov 12 23:39:02 UTC 2018
one Mon Nov 12 23:39:05 UTC 2018
one Mon Nov 12 23:39:07 UTC 2018

La sortie montre que 20 % du trafic est routé vers tcp-echo-v2.