Istio Traffic Management

Istio implements support for the standard Kubernetes ingress resource, but the functionality is limited. The full traffic management features of Istio can be configured with the following CRDs.

• Gateway

• Virtual service

• Destination rule

Gateway

The gateway resource specifies what happens when the traffic is entering or leaving the cluster. This resource has a set of hostnames to match against incoming traffic and a list of network ports that are exposed to network traffic.

The gateway resource has the following fields on the YAML manifest.

selector

The selector specifies the Istio ingress gateway to use for this resource. The gateway configuration is applied to the envoy proxy running on a pod with the specified label.

Note	The default ingress gateway has the istio=ingressgateway label applied. [user@host kbe]$ kubectl get pods -l 'istio=ingressgateway' -n istio-system NAME READY STATUS RESTARTS AGE istio-ingressgateway-78f69bd5db-s5pjz 1/1 Running 1 (1d ago) 4d

servers

The servers section is a list of host and ports that are matched against incoming HTTP traffic. The host can be set to a specific DNS name, wildcards such as *.example.com are supported, and it can be defined as '*' to match all hostnames.

Note	There are other configurations for TLS and SNI that can be applied to this resource, but they are outside the scope of this section.

The following is an example of an gateway resource manifest.

---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  selector:
    istio: ingressgateway  # (1)
  servers:
  - hosts:
    - "bookinfo.192.168.59.20.nip.io"  # (2)
    port:  # (3)
      name: http
      number: 80
      protocol: HTTP

1. Use the Istio default ingress gateway.

2. DNS host name where the ingress serves traffic.

3. Port number where the proxy listen for incoming connections.

Virtual Service

The virtual service resource defines a set of rules. These rules match the HTTP traffic and the backend service name and port number, they forward the traffic if the requests match.

The virtual service resource has the following fields on the YAML manifest.

gateways

Specifies the Istio gateway that handles the incoming traffic.

hosts

List of host names to match the HTTP traffic. The host can be set to a specific DNS name, wildcards such as *.example.com are supported, and it can be defined as '*' to match all hostnames.

http

List of rules to match against incoming HTTP traffic.

match

Specifies the URI to perform a case-sensitive match for either the exact path, treat the path as a prefix, or provide a regex for matching.

route

Specifies the back-end service host and port number that process the request. Each route can have a weight to configure which percentage of the traffic should be forwarded to a given destination.

The following code listing is an example of a virtual service resource manifest.

---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
spec:
  gateways:
  - bookinfo-gateway  # (1)
  hosts:
  - "bookinfo.192.168.59.20.nip.io"  # (2)
  http:  # (3)
  - match:  # (4)
    - uri:
        exact: /productpage
    - uri:
        prefix: /static
    - uri:
        exact: /login
    - uri:
        exact: /logout
    - uri:
        prefix: /api/v1/products
    route:  # (5)
    - destination:
        host: productpage
        port:
          number: 9080

1. Apply the virtual service rules to the specified gateway in the current namespace.

2. DNS host name where the ingress serves traffic.

3. List of routing rules for the HTTP traffic.

4. List of rules to match against incoming requests.

5. The matching requests are forwarded to this service and port number.

The virtual service resource can also work with destination rules to specify different subsets or service versions, and route part of the traffic to them.

---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - weight: 10  # (1)
      destination:
        host: reviews
        subset: v1
    - weight: 30  # (2)
      destination:
        host: reviews
        subset: v2
    - weight: 60  # (3)
      destination:
        host: reviews
        subset: v3

1. 10% of the traffic is redirected to reviews subset v1.

2. 30% of the traffic is redirected to reviews subset v2.

3. 60% of the traffic is redirected to reviews subset v3.

[user@host kbe]$ kubectl edit virtualservice/reviews -n bookinfo
error: virtualservices.networking.istio.io "reviews" could not be patched:
admission webhook "validation.istio.io" denied the request:
configuration is invalid: total destination weight 90 != 100

Destination Rule

This resource defines configurations that take place after the routing has been performed, and you can specify a subset of the service pods by matching a set of labels to differentiate service versions.

The destination rule resource has the following fields on the YAML manifest.

host

The name of the back-end service on the Kubernetes cluster.

subsets

Defines the service subset, this can be used to distribute traffic between different versions of the service.

labels

The labels to match the destination pod.

The following resource definition specifies that there are three versions of the service and that different percentages of the traffic are routed to each one.

---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1  # (1)
    labels:
      version: v1
  - name: v2  # (2)
    labels:
      version: v2
  - name: v3  # (3)
    labels:
      version: v3

1. The subset v1 references pods with label version: v1.

2. The subset v2 references pods with label version: v2.

3. The subset v3 references pods with label version: v3.