Traffic Management FAQ
How can I view the current route rules I have configured with Istio?
Rules can be viewed using
kubectl get virtualservice -o yaml
On what ports does a sidecar proxy capture inbound traffic?
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
to specify a list of ports to bypass.
What is the difference between MUTUAL and ISTIO_MUTUAL TLS modes?
Both of these
DestinationRule settings will send mutual TLS traffic.
ISTIO_MUTUAL, Istio certificates will automatically be used.
MUTUAL, the key, certificate, and trusted CA must be configured.
This allows initiating mutual TLS with non-Istio applications.
Can Istio be used with StatefulSets and headless Services?
Yes, Istio fully supports these workloads as of Istio 1.10.
Can I use standard Ingress specification without any route rules?
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
For example, the following ingress resource matches requests for the example.com host, with /helloworld as the URL.
$ kubectl create -f - <<EOF apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: simple-ingress annotations: kubernetes.io/ingress.class: istio spec: rules: - host: example.com http: paths: - path: /helloworld pathType: Prefix backend: service: name: myservice port: number: 8000 EOF
However, the following rules will not work because they use regular
expressions in the path and
$ kubectl create -f - <<EOF apiVersion: networking.k8s.io/v1 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/ pathType: Prefix backend: service: name: myservice port: number: 8000 EOF
Why is my CORS configuration not working?
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
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.
What protocols does Istio support?
Currently, Istio supports TCP based protocols. Additionally, Istio provides functionality such as routing and metrics for other protocols such as
For a list of all protocols, and information on how to configure protocols, view the Protocol Selection documentation.