Flexible software deployment patterns with IngressRoute

This is the third post in a series highlighting some of the exciting new features released in Heptio Contour version 0.6. If you missed out on those, start with Introducing Heptio Contour 0.6 and Improving the multi-team Kubernetes ingress experience with Heptio Contour 0.6.

One of the improvements that we added to IngressRoute is the ability to route traffic to multiple Services for a given path as well as apply weights to those upstream Services. This seemingly small addition allows users to implement some simple, yet very powerful deployment patterns.

Canary Deployments

One way to roll out a new version of an application is to utilize a canary deployment. In this model, first deploy the change to a small subset of users to gather information on how the new version is responding. Since only a small set of traffic is targeted, the impact overall will not be as apparent in the event of a failure of the new version. The amount of traffic sent to the canary version is determined by the weight configured, a higher proportion of weight means more traffic will be sent.

Without IngressRoute, the only way to implement this would be to have a Service select pods from two different deployments, however, traffic would be limited by the number of replicas of each deployment and it would be difficult to manage. Additionally, the standard Kubernetes Ingress object does not allow for multiple Services per virtual host and does not support configurable weighting.

We took these requirements into account as we designed the IngressRoute specification and added the ability to define multiple Services per Route as well as configurable weighting. By manipulating weights across the Services, the entire rollout can be managed easily until the new version of the application is receiving 100% of the traffic.

Following is a diagram which visualizes how a canary deployment is rolled out:

apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata: 
  name: production-webapp
spec: 
  virtualhost:
    fqdn: foo.com
  routes: 
  - match: /
      services: 
      - name: webapp-v1.0.0
        port: 80
        weight: 90
      - name: webapp-v1.1.0
        port: 80
        weight: 10

In this example, 90% of the requests to foo.com are routed to the Service webapp-v1.0.0 and 10% are routed to webapp-v1.1.0. It’s important to note that modifying the weights triggers an immediate shift of traffic pattern in Envoy (via Contour).

Other Use-Cases

Heptio Gimbal is an open source initiative that builds on Heptio Contour with the goal of unifying and managing internet traffic on hybrid environments consisting of multiple Kubernetes clusters running on cloud providers and on traditional data centers.

Gimbal allows users to utilize multi-service IngressRoutes to route traffic across clusters. You can read more about Gimbal from our launch blog post.

What’s next?

In this post, we have explored how traffic can be routed to multiple weighted Services within a Kubernetes cluster utilizing IngressRoute. This is one of the many exciting features available in the latest version of Heptio Contour.

In future posts, we will explore other patterns enabled by the IngressRoute, including blue/green deployments and load balancing strategies. If you have any questions or are interested in learning more, reach us via the #contour channel on the Kubernetes community Slack or follow us on Twitter.