TCP Traffic Shifting

    A common use case is to migrate TCP traffic gradually from an older version of a microservice to a new one. In Istio, you accomplish this goal by configuring a sequence of routing rules that redirect a percentage of TCP traffic from one destination to another.

    In this task, you will send 100% of the TCP traffic to . Then, you will route 20% of the TCP traffic to tcp-echo:v2 using Istio’s weighted routing feature.

    • Setup Istio by following the instructions in the .

    • Review the Traffic Management concepts doc.

    1. To get started, create a namespace for testing TCP traffic shifting and label it to enable automatic sidecar injection.

    2. Deploy the sleep sample app to use as a test source for sending requests.

      1. $ kubectl apply -f @samples/sleep/sleep.yaml@ -n istio-io-tcp-traffic-shifting

    3. Zip

      1. $ kubectl apply -f @samples/tcp-echo/tcp-echo-services.yaml@ -n istio-io-tcp-traffic-shifting

    4. Follow the instructions in to define the TCP_INGRESS_PORT and INGRESS_HOST environment variables.

    1. Route all TCP traffic to the v1 version of the tcp-echo microservice.

    2. Confirm that the tcp-echo service is up and running by sending some TCP traffic from the sleep client.

      1. $ for i in {1..20}; do \
      2. kubectl exec "$(kubectl get pod -l app=sleep -n istio-io-tcp-traffic-shifting -o jsonpath={.items..metadata.name})" \
      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
      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
      14. ...

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

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

      1. $ kubectl apply -f @samples/tcp-echo/tcp-echo-20-v2.yaml@ -n istio-io-tcp-traffic-shifting

      Wait a few seconds for the new rules to propagate.

    4. Confirm that the rule was replaced:

    5. Send some more TCP traffic to the tcp-echo microservice.

      1. $ for i in {1..20}; do \
      2. -c sleep -n istio-io-tcp-traffic-shifting -- sh -c "(date; sleep 1) | nc $INGRESS_HOST $TCP_INGRESS_PORT"; \
      3. done
      4. one Mon Nov 12 23:38:45 UTC 2018
      5. two Mon Nov 12 23:38:47 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
      14. ...

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

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

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

    For more information about version routing with autoscaling, check out the blog article .

    1. Zip

      1. $ kubectl delete -f @samples/tcp-echo/tcp-echo-all-v1.yaml@ -n istio-io-tcp-traffic-shifting
      2. $ kubectl delete -f @samples/tcp-echo/tcp-echo-services.yaml@ -n istio-io-tcp-traffic-shifting
      3. $ kubectl delete -f @samples/sleep/sleep.yaml@ -n istio-io-tcp-traffic-shifting