TCP Traffic Shifting

This task shows you how to gradually migrate TCP traffic from one version of amicroservice to another. For example, you might migrate TCP traffic from anolder version to a new version.

A common use case is to migrate TCP traffic gradually from one version of amicroservice to another. In Istio, you accomplish this goal by configuring asequence of rules that route a percentage of TCP traffic to one service oranother. In this task, you will send 100% of the TCP traffic to tcp-echo:v1.Then, you will route 20% of the TCP traffic to tcp-echo:v2 using Istio’sweighted routing feature.

Before you begin

Apply weight-based TCP routing

  • To get started, deploy the v1 version of the tcp-echo microservice.

Zip

  1. $ kubectl apply -f <(istioctl kube-inject -f @samples/tcp-echo/tcp-echo-services.yaml@)

The istioctl kube-inject command is used to manually modify the tcp-echo-services.yamlfile before creating the deployments.

  1. $ kubectl label namespace default istio-injection=enabled

Then simply deploy the services using kubectl

Zip

  1. $ kubectl apply -f @samples/tcp-echo/tcp-echo-services.yaml@
  • Next, route all TCP traffic to the v1 version of the tcp-echo microservice.

Zip

  1. $ kubectl apply -f @samples/tcp-echo/tcp-echo-all-v1.yaml@
  • Confirm that the tcp-echo service is up and running.

The $INGRESS_HOST variable below is the External IP address of the ingress, as explained inthe Ingress Gateways doc. To obtain the$INGRESS_PORT value, use the following command.

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

Send some TCP traffic to the tcp-echo microservice.

  1. $ for i in {1..10}; do \
  2. 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"; \
  3. done
  4. one Mon Nov 12 23:24:57 UTC 2018
  5. one Mon Nov 12 23:25:00 UTC 2018
  6. one Mon Nov 12 23:25:02 UTC 2018
  7. one Mon Nov 12 23:25:05 UTC 2018
  8. one Mon Nov 12 23:25:07 UTC 2018
  9. one Mon Nov 12 23:25:10 UTC 2018
  10. one Mon Nov 12 23:25:12 UTC 2018
  11. one Mon Nov 12 23:25:15 UTC 2018
  12. one Mon Nov 12 23:25:17 UTC 2018
  13. one Mon Nov 12 23:25:19 UTC 2018

The docker command may require using sudo depending on your Docker installation.

You should notice that all the timestamps have a prefix of one, which means that all trafficwas routed to the v1 version of the tcp-echo service.

  • Transfer 20% of the traffic from tcp-echo:v1 to tcp-echo:v2 with the following command:

Zip

  1. $ kubectl apply -f @samples/tcp-echo/tcp-echo-20-v2.yaml@

Wait a few seconds for the new rules to propagate.

  • Confirm that the rule was replaced:
  1. $ kubectl get virtualservice tcp-echo -o yaml
  2. apiVersion: networking.istio.io/v1alpha3
  3. kind: VirtualService
  4. metadata:
  5.   name: tcp-echo
  6.   ...
  7. spec:
  8.   ...
  9.   tcp:
  10.   - match:
  11.     - port: 31400
  12.     route:
  13.     - destination:
  14.         host: tcp-echo
  15.         port:
  16.           number: 9000
  17.         subset: v1
  18.       weight: 80
  19.     - destination:
  20.         host: tcp-echo
  21.         port:
  22.           number: 9000
  23.         subset: v2
  24.       weight: 20
  • Send some more TCP traffic to the tcp-echo microservice.
  1. $ for i in {1..10}; do \
  2. 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"; \
  3. done
  4. one Mon Nov 12 23:38:45 UTC 2018
  5. two Mon Nov 12 23:38:47 UTC 2018
  6. one Mon Nov 12 23:38:50 UTC 2018
  7. one Mon Nov 12 23:38:52 UTC 2018
  8. one Mon Nov 12 23:38:55 UTC 2018
  9. two Mon Nov 12 23:38:57 UTC 2018
  10. one Mon Nov 12 23:39:00 UTC 2018
  11. one Mon Nov 12 23:39:02 UTC 2018
  12. one Mon Nov 12 23:39:05 UTC 2018
  13. one Mon Nov 12 23:39:07 UTC 2018

The docker command may require using sudo depending on your Docker installation.

You should now notice that about 20% of the timestamps have a prefix of two, which means that80% of the TCP traffic was routed to the v1 version of the tcp-echo service, while 20% wasrouted to v2.

Understanding what happened

In this task you partially migrated TCP traffic from an old to new version ofthe tcp-echo service using Istio’s weighted routing feature. Note that this isvery different than doing version migration using the deployment features ofcontainer orchestration platforms, which use instance scaling to manage thetraffic.

With Istio, you can allow the two versions of the tcp-echo service to scale upand down independently, without affecting the traffic distribution between them.

For more information about version routing with autoscaling, check out the blogarticle Canary Deployments using Istio.

Cleanup

  • Remove the tcp-echo application and routing rules:

ZipZip

  1. $ kubectl delete -f @samples/tcp-echo/tcp-echo-all-v1.yaml@
  2. $ kubectl delete -f @samples/tcp-echo/tcp-echo-services.yaml@

See also

Istio as a Proxy for External Services

Configure Istio ingress gateway to act as a proxy for external services.

Multi-Mesh Deployments for Isolation and Boundary Protection

Deploy environments that require isolation into separate meshes and enable inter-mesh communication by mesh federation.

Secure Control of Egress Traffic in Istio, part 3

Comparison of alternative solutions to control egress traffic including performance considerations.

Secure Control of Egress Traffic in Istio, part 2

Use Istio Egress Traffic Control to prevent attacks involving egress traffic.

Secure Control of Egress Traffic in Istio, part 1

Attacks involving egress traffic and requirements for egress traffic control.

Version Routing in a Multicluster Service Mesh

Configuring Istio route rules in a multicluster service mesh.