Traffic Management FAQ

Rules can be viewed using kubectl get virtualservice -o yaml

Istio captures inbound traffic on all ports by default. You can override this behavior using the traffic.sidecar.istio.io/includeInboundPorts pod annotation to specify an explicit list of ports to capture, or using traffic.sidecar.istio.io/excludeOutboundPorts to specify a list of ports to bypass.

Both of these DestinationRule settings will send mutual TLS traffic. With ISTIO_MUTUAL, Istio certificates will automatically be used. For MUTUAL, the key, certificate, and trusted CA must be configured. This allows initiating mutual TLS with non-Istio applications.

Yes, Istio fully supports these workloads as of Istio 1.10.

Simple ingress specifications, with host, TLS, and exact path based matches will work out of the box without the need for route rules. However, note that the path used in the ingress resource should not have any . characters.

For example, the following ingress resource matches requests for the example.com host, with /helloworld as the URL.

$ kubectl create -f - <<EOF
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: simple-ingress
annotations:
  kubernetes.io/ingress.class: istio
spec:
rules:
- host: example.com
  http:
    paths:
    - path: /helloworld
      backend:
        serviceName: myservice
        servicePort: grpc
EOF

However, the following rules will not work because they use regular expressions in the path and ingress.kubernetes.io annotations:

$ kubectl create -f - <<EOF
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: this-will-not-work
annotations:
  kubernetes.io/ingress.class: istio
  # Ingress annotations other than ingress class will not be honored
  ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: example.com
  http:
    paths:
    - path: /hello(.*?)world/
      backend:
        serviceName: myservice
        servicePort: grpc
EOF

After applying CORS configuration, you may find that seemingly nothing happened and wonder what went wrong. CORS is a commonly misunderstood HTTP concept that often leads to confusion when configuring.

To understand this, it helps to take a step back and look at what CORS is and when it should be used. By default, browsers have restrictions on “cross origin” requests initiated by scripts. This prevents, for example, a website attack.example.com from making a JavaScript request to bank.example.com and stealing a users sensitive information.

In order to allow this request, bank.example.com must allow attack.example.com to perform cross origin requests. This is where CORS comes in. If we were serving bank.example.com in an Istio enabled cluster, we could configure a corsPolicy to allow this:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: bank
spec:
  hosts:
  - bank.example.com
  http:
  - corsPolicy:
      allowOrigins:
      - exact: https://attack.example.com
...

In this case we explicitly allow a single origin; wildcards are common for non-sensitive pages.

Once we do this, a common mistake is to send a request like curl bank.example.com -H "Origin: https://attack.example.com", and expect the request to be rejected. However, curl and many other clients will not see a rejected request, because CORS is a browser constraint. The CORS configuration simply adds Access-Control-* headers in the response; it is up to the client (browser) to reject the request if the response is not satisfactory. In browsers, this is done by a Preflight request.

Currently, Istio supports TCP based protocols. Additionally, Istio provides functionality such as routing and metrics for other protocols such as http and mysql.

For a list of all protocols, and information on how to configure protocols, view the Protocol Selection documentation.