Supercharging your blue/green deployments by using an Ingress Controller

Over the past couple of week, I\’ve been playing around with blue/green deployments into Kubernetes. Up till now, we\’ve been doing this using the service object in Kubernetes, we\’ve then turned this model into a Helm chart, and we turned this into a CI/CD pipeline as well.

In order to stay on theme, is this post we\’ll change our deployment strategy. Up until now, we\’ve been using the service object to do our traffic routing to either blue or green. This works very well if you want to do a true blue-green deployment and a binary cut over. This is however the most you can achieve with the service object. This object doesn\’t allow you to do A/B testing, canary deployments or any other more complicated deployment strategy.

In this post, we\’ll adapt our deployment to include an IngressController. We\’ll then do a couple of manual blue/green deployments. Finally, we\’ll briefly explore how we can do A/B testing using our IngressController.

But to get started, let\’s explore the Ingress Controller object in Kubernetes, and what this allows us to do.

What is an Ingress Controller

An Ingress Controller is essentially a L7 load balancer within your Kubernetes Cluster. It allows you to setup external hostnames to your services, and route traffic based on different HTTP metrics. Typically, Ingress Controllers are used for HTTP and HTTPS, but they could be used for non-HTTP traffic as well.

There are a lot of implementations of Ingress Controllers. This means that although the definition object is the same across implementations, you can use a different technology in the background the actually implement the functionality. It\’s important to understand that from a Kubernetes perspective an Ingress Controller is simply another API object. You define which Ingress Controller you want to use.

The Kubernetes project itself supports 2 ingress controllers, GCE and an NGINX implementation. From an Azure perspective, Microsoft released the general availability support of the Application Gateway Ingress Controller. For our work today, we\’ll be using the Traefik Ingress Controller. Although I\’m not opinionated about which Ingress is best, I have some experience with using Traefik, so that\’s what I\’ll be using the showcase the functionality.

Setting up the Traefik Ingress Controller on AKS

Traefik recently upgraded from v1.7 to v2.0. This upgrade had some breaking changes. As we\’re setting up greenfield implementation here, we\’ll use v2.0.

There\’s an experimental Helm chart that be used to setup Traefik v2.0 on our cluster. Let\’s be brave and walk through this experimentation.

Let\’s start with pulling in that repo locally.

git clone git@github.com:containous/traefik-helm-chart.git
cd traefik-helm-chart

Note: I\’m using Helm v3.

And with the Chart available locally, we can go ahead and install Traefik in our cluster:

helm install traefik-ingress .

This will install all the required Traefik components in our cluster. To get our ingress to work, we\’ll need to map it to a DNS name. Get the IP of the traefik ingress service, and then create a DNS record for it:

kubectl get svc | grep traefik

If we connect to this DNS url, we\’ll get a 404 returned, becaues we don\’t have any ingresses defined yet. But getting a 404 is a good sign, because it shows us Traefik is up and running.

We can now create an actual ingress controller. I have a service running, called blue. I will create to following ingress controller to map traffic to ingress.nillsf.com to that blue service.