This topic describes how to use standard Istio route rules to manage inbound TCP traffic in a unified manner.
Background information
The Istio traffic management model decouples traffic flow from infrastructure scaling. You can use Pilot to specify rules for traffic routing. Envoy proxies are deployed as sidecars to services. This sidecar proxy model allows you to manage traffic without modifying the application code.
A typical mesh has one or more load balancers that are referred to as Istio gateways. Istio gateways terminate TLS connections established from the Internet and allow traffic to flow into the mesh. Then, traffic flows to internal services through sidecar gateways. The following diagram shows the principles of gateways in an Istio mesh.

An Istio gateway enables load balancing for HTTP/TCP traffic and manages inbound traffic at the edge of a mesh. A mesh can have one or more gateways. We recommend that you do not use the Ingress APIs in Kubernetes to manage inbound traffic. The Ingress APIs cannot express the routing needs of Istio. An ingress in Kubernetes attempts to draw a common denominator across HTTP proxies. As a result, the ingress only supports the basic HTTP routing. You can only use non-portable annotations to enable advanced features of modern proxies. Different proxies use different annotation modes.
A Kubernetes ingress does not support the TCP protocol. Therefore, you cannot enable TCP load balancing by deploying an NGINX ingress controller. To enable TCP load balancing, create a ConfigMap in Kubernetes to configure NGINX. For more information, see Support for TCP/UDP load balancing. Such configurations are non-portable and have low compatibility among proxies.
To address this issue, Istio gateways allow you to configure only layer 4 to layer 6 settings, such as port and TLS settings. All major proxies enable these features in a unified manner. For layer 7 settings of the inbound traffic, Istio allows you to bind a VirtualService to a gateway. In this case, you can use standard Istio rules to manage HTTP and TCP traffic that flows through the gateway.
Prerequisites
- A Kubernetes cluster is created. The cluster version must be V1.11.2 or later. For more information, see Create a cluster of ACK Managed Edition.
- A master node is connected. For more information, see Use kubectl to connect to a cluster.
- The netcat tool is installed. You can use yum or apt-get to install netcat.
Deploy Istio
Build an image of a TCP server
You can use the following image file: registry.cn-hangzhou.aliyuncs.com/wangxining/tcptest:0.1. You can also perform the following steps to build an image of a TCP server.
Deploy an application
Create gateways
kubectl apply -f gateway.yaml
command to create gateways. Two gateways are created. One gateway listens to port
31400, and the other listens to port 31401. apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: tcp-echo-gateway
spec:
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 31400
name: tcp
protocol: TCP
hosts:
- "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: tcp-echo-gateway-v2
spec:
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 31401
name: tcp
protocol: TCP
hosts:
- "*"

Create Istio route rules
kubectl apply -f destination-rule-all.yaml
and kubectl apply -f virtualservice.yaml
commands. apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: tcp-echo
spec:
hosts:
- "*"
gateways:
- tcp-echo-gateway
- tcp-echo-gateway-v2
tcp:
- match:
- port: 31400
gateways:
- tcp-echo-gateway
route:
- destination:
host: tcp-echo.default.svc.cluster.local
subset: v1
port:
number: 3333
- match:
- port: 31401
gateways:
- tcp-echo-gateway-v2
route:
- destination:
host: tcp-echo.default.svc.cluster.local
subset: v2
port:
number: 3333