Use cases

This section assumes your developers have the permissions required to deploy workloads to the cluster.

Create an Istio virtual service

The following example describes how to create an Istio virtual service to route all requests matching <domain>/{status,delay} to an application. Virtual services are namespace-scoped and can only route to applications within the namespace in which they are created.

  1. Access kubectl as an administrator.

  2. Create the virtual service:

    cat <<EOF | kubectl create -f -
    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      generation: 1
      name: httpbin-vs
      selfLink: /apis/networking.istio.io/v1alpha3/namespaces/default/virtualservices/httpbin-vs
    spec:
      gateways:
      - application-gateway
      hosts:
      - httpbin
      http:
      - match:
        - uri:
           prefix: /status
        - uri:
           prefix: /delay
        route:
        - destination:
           host: httpbin
           port:
              number: 8000
    EOF
    

Enable split testing

To enable split testing of an application, you can add an Istio destination rule for routing a small percentage of traffic to the new version of the application.

  1. Access kubectl as an administrator.

  2. Add the Istio destination rule in the namespace where the application is deployed. This creates the service subsets needed for the virtual service matcher, based on Kubernetes Pod labels.

    cat <<EOF | kubectl create -f -
    apiVersion: networking.istio.io/v1alpha3
    kind: DestinationRule
    metadata:
       name: httpbin-destination-rule
    spec:
       host: httpbin
       subsets:
       - name: 'v1.0.0'
         labels:
           version: 'v1.0.0'
       - name: 'v1.1.0-featuretest'
         labels:
           version: 'v1.1.0-featuretest'
    EOF
    
  3. Edit the existing virtual service and add the needed routing policy using the destination rule:

    cat <<EOF | kubectl apply -f -
    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
       name: httpbin-vs
    spec:
       gateways:
       - application-gateway
       hosts:
       - '*'
       http:
       - route:
          - destination:
             host: httpbin
             subset: 'v1.0.0'
             weight: 95
          - destination:
             host: httpbin
             subset: 'v1.1.0-featuretest'
             weight: 5
    EOF
    

Configure sticky sessions

Sticky sessions enable users who participate in split testing to consistently see a particular feature. An administrator must add a sticky session to the initial application configuration, which forces Istio Ingress to route all follow-up requests to the same Pod.

  1. Access kubectl as an administrator.

  2. Create a new destination rule, declaring a hashing-based load balancer for the application using the user cookie as the hash key:

    cat <<EOF | kubectl create -f -
    apiVersion: networking.istio.io/v1alpha3
    kind: DestinationRule
    metadata:
       name: httpbin-destination-rule
    spec:
       host: httpbin.default.svc.cluster.local
       trafficPolicy:
          loadBalancer:
             consistentHash:
                httpCookie:
                   name: User
                   ttl: 0s
    EOF
    

Canary deployments

Canary deployments are a pattern for rolling out releases to a subset of users or servers. Canary deployments are useful when a developer wants to gradually deploy a new version of an application without any downtime.

To create a canary deployment, you must create a destination rule for both versions of the application.

  1. Access kubectl as an administrator.

  2. Add the Istio destination rule in the namespace where the application is deployed. This creates the service subsets needed for the virtual service matcher, based on Kubernetes Pod labels.

  3. Edit the existing virtual service and add the needed routing policy using the destination rule.

  4. In the virtual service configuration, specify the weight of each version.

  5. Gradually increase the weight of the new version until it reaches 100%.

  6. Use the Cluster Autoscaler to make sure that there are always available instances.

Blacklisting

You can prevent DoS attacks by blacklisting the offending IP address to prevent the degradation of the application uptime. You can create the blacklist by using Istio mixer policies.

  1. Create a handler, instance, and rule to filter out any requests from IP addresses specified in the handler override spec, as in the following example:

    cat <<EOF | kubectl create -f -
    apiVersion: "config.istio.io/v1alpha2"
    kind: handler
    metadata:
       name: blacklisthandler
       namespace: istio-system
    spec:
       compiledAdapter: listchecker
       params:
          overrides:
          - 37.72.166.13
          - <IP/CIDR TO BE BLACKLISTED>
          blacklist: true
          entryType: IP_ADDRESSES
          refresh_interval: 1s
          ttl: 1s
          caching_interval: 1s
    ---
    apiVersion: "config.istio.io/v1alpha2"
    kind: instance
    metadata:
       name: blacklistinstance
       namespace: istio-system
    spec:
       compiledTemplate: listentry
       params:
          value: ip(request.headers["x-forwarded-for"]) || ip("0.0.0.0")
    ---
    apiVersion: "config.istio.io/v1alpha2"
    kind: rule
    metadata:
      name: blaclistcidrblock
      namespace: istio-system
    spec:
      match: (source.labels["istio"] | "") == "ingressgateway"
      actions:
      - handler: blacklisthandler
        instances:
        - blacklistinstance
    EOF
    

    Use the x-forwarded-for header that Istio automatically attaches.

  2. In the MKE configuration file, change the value of cluster_config.service_mesh.ingress_preserve_client_ip to true.