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.

Access kubectl as an administrator.

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.

Access kubectl as an administrator.

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

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.

Access kubectl as an administrator.

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.

Access kubectl as an administrator.
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.
Edit the existing virtual service and add the needed routing policy using the destination rule.
In the virtual service configuration, specify the weight of each version.
Gradually increase the weight of the new version until it reaches 100%.
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.

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.

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