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

When you need to optimize your network topology, scale application servers, or adjust traffic, use the Traffic Management Center of Service Mesh (ASM) to smoothly migrate TCP application traffic. This process ensures business continuity and high service availability. This topic uses the official Istio task TCP-Traffic-Shifting as an example to demonstrate a canary release for a TCP service by gradually shifting traffic between two versions. The example tcp-echo service has two versions: v1 prefixes responses with one and v2 prefixes them with two. This lets you observe the effects of traffic shifting and fine-tune the routing policy to meet your business requirements.

Prerequisites

The following services are activated:
- Container Service for Kubernetes (ACK)
- Classic Load Balancer (CLB)
An ACK cluster is created. For more information, see Create an ACK dedicated cluster (Discontinued) and Create an ACK managed cluster.
The ACK cluster is added to an ASM instance. For more information, see Create an ASM instance and Add a cluster to an ASM instance.

Step 1: Deploy the sample application

Deploy two versions of the tcp-echo application.

Log on to the ACK console. In the left navigation pane, click Clusters.
On the Clusters page, click the name of your cluster. In the left navigation pane, click Workloads > Deployments.
On the Deployments page, select your target namespace from the Namespace drop-down list and click Create Resources in YAML in the upper-right corner.

Set Sample Template to Custom, paste the following YAML into the Template text box, and then click Create.

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

On the Deployments page, the two versions of the tcp-echo application now appear.

Create a Service to expose the application.

Log on to the ACK console. In the left navigation pane, click Clusters.
On the Clusters page, click the name of your cluster. In the left navigation pane, click Network > Services.
On the Services page, select your target namespace from the Namespace drop-down list and click Create in the upper-right corner.

In the Create Service dialog box, configure the parameters and click Confirm.

Parameter	Description
Service	Enter `tcp-echo`.
Service Type	Select the access method for the Service. Supported types are ClusterIP, NodePort, and LoadBalancer. Note You can use a Headless Service only when Service Type is set to Cluster IP. You can use a Headless Service to connect with other service discovery systems, bypassing the native Kubernetes implementation.
Backend	Set Name to app and Value to tcp-echo. Note The Service's selector uses the `app` label from the associated Deployment to determine where to forward traffic. Because both the `tcp-echo-v1` and `tcp-echo-v2` Deployments share the `app:tcp-echo` label, the Service can route to either Deployment.
External Traffic Policy	The Local and Cluster options are supported. Note You can set the External Traffic Policy only when Node Port is set to Server Load Balancer or Server Load Balancer.
Port Mapping	In this topic, set Name to `tcp`, Service Port and Container Port to `9000`, and Protocol to TCP.
Annotations	Add an `annotation` to the Service to configure load balancer parameters. For example, setting `service.beta.kubernetes.io/alicloud-loadbalancer-bandwidth:20` sets the peak bandwidth to 20 Mbit/s. For more information about the parameters, see Configure a Classic Load Balancer (CLB) instance by using annotations.
Label	Add a label to identify the Service.

After you create the Service, the new tcp-echo Service appears on the Services page.

Step 2: Configure routing rules

Configure an Istio Gateway, VirtualService, and DestinationRule in Service Mesh to route all traffic to the v1 version of the tcp-echo service.

Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.
On the Mesh Management page, find the ASM instance that you want to configure. Click the name of the ASM instance or click Manage in the Actions column.
Create a gateway.
1. On the details page of the ASM instance, choose ASM Gateways > Gateway in the left-side navigation pane. On the page that appears, click Create from YAML.
2. On the Create page, set Namespace to default, select a template from the Scenario Template drop-down list, paste the following YAML, and then click 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:
    - "*"
```
Create a virtual service.
1. On the details page of the ASM instance, choose Traffic Management Center > VirtualService in the left-side navigation pane. On the page that appears, click Create from YAML.
2. On the Create page, set Namespace to default, select a template from the Scenario Template drop-down list, paste the following YAML, and then click 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
```
Create a destination rule.
1. On the details page of the ASM instance, choose Traffic Management Center > DestinationRule in the left-side navigation pane. On the page that appears, click Create from YAML.
2. On the Create page, set Namespace to default, select a template from the Scenario Template drop-down list, paste the following YAML, and then click 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
```

Step 3: Deploy an ingress gateway

Add port 31400 to the ingress gateway service to allow external TCP traffic to reach the Istio Gateway.

Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.
On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose ASM Gateways > Ingress Gateway.

On the Ingress Gateway page, click Create, configure the parameters, and then click Create.

The following table describes some of the key parameters. For more information about the parameters, see Create an ingress gateway.

Parameter	Description
Cluster	Select the cluster where you want to deploy the ingress gateway.
CLB instance type	In this topic, select Access over the Internet.
CLB instance	Use Existing CLB Instance: Select an instance from the list of existing CLB instances. Create CLB Instance: Click Create SLB Instance and select the required instance specification from the drop-down list. Note Allocate a dedicated CLB instance for each Kubernetes Service. If multiple Kubernetes Services share a CLB instance, the following risks and limitations apply: Using an existing CLB instance overwrites its existing listeners, which can make your application inaccessible. You cannot reuse a CLB instance created by a Kubernetes Service. You can reuse only CLB instances that you manually create in the console or by calling an API operation. Multiple Services that share a CLB instance cannot use the same frontend listener port, or a port conflict will occur. When you reuse a CLB instance, Kubernetes uses the listener and virtual server group names as unique identifiers. Do not modify these names. You cannot reuse a CLB instance across different clusters.
Port Mapping	Click Add Port, set Name to `tcp`, and set Service Port to `31400`.

Step 4: Verify the deployment

Use kubectl to confirm that traffic to the tcp-echo service is routed as expected.

Connect to your Kubernetes cluster by using kubectl. For more information, see Obtain the kubeconfig file and use kubectl to connect to the cluster.

Run the following commands to get the service address and port:

$ 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}')

Use the telnet command to send a connection request to the tcp-echo service.

$ telnet $INGRESS_HOST $INGRESS_PORT
Trying xxx.xxx.xxx.xxx...
Connected to xxx.xxx.xxx.xxx.
Escape character is '^]'

Enter any string and press Enter.

The response is prefixed with one, which indicates that all traffic is routed to the tcp-echo-v1 version.

Step 5: Route traffic to v2 by weight

This step routes 20% of the traffic to the tcp-echo-v2 version and the remaining 80% to tcp-echo-v1.

Modify the VirtualService configuration of the ASM instance.

On the details page of the ASM instance, choose Traffic Management Center > VirtualService in the left-side navigation pane.
On the VirtualService page, find the tcp-echo service and click YAML in the Actions column.

In the Edit panel, replace the content with the following YAML and click 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

Run the following command to send 10 requests to the tcp-echo service:

$ 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

The output shows that approximately 20% of the traffic is routed to tcp-echo-v2.

Note

With a small sample of 10 requests, the results may not show an exact 80/20 split. However, the ratio will approach this distribution as the number of requests increases.