Canary deployments can be a great way to gradually see how a new version of an application will perform by rolling out the new version incrementally. Sometimes, however, your application can’t be deployed that way due to dependencies such as database migrations or application design differences between versions. In these cases, blue-green deployments can be utilized.
With this deployment strategy, the new version of the application is stood up in a green deployment where testing and validation can happen without production traffic. Once you have deployed and fully tested the software in the green deployment, you switch the traffic so all incoming requests now go to the green deployment instead of the current deployment, which is known as the blue deployment. Green is now servicing all requests and blue is idle. In the event that green does not function properly or is experiencing errors, you can switch back to blue to debug the green deployment and determine if a new green version needs to be deployed. You can see an example of blue-green deployment in this video.
Delegation
The previous blog post on Contour discussed how delegation with IngressRoute can address how teams work together in a single cluster by utilizing a feature called “delegation.” Delegation allows administrators to pass authority over portions of ingress to namespaces. Within a namespace, users can freely update the ingress resources that they have been delegated.
Using the same concept, a user in a namespace can use delegation to implement the blue-green deployment by swapping which IngressRoute has the current authority to handle the production traffic.
To enable this pattern, we’ll deploy a root IngressRoute (named root-blog), which will delegate containersteve.com/blog to an IngressRoute named blog. Then we’ll deploy the blue and green versions, knowing that only the blue version will receive traffic.
---
apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata:
name: root-blog
namespace: root-ingressroute
spec:
virtualhost:
fqdn: containersteve.com
tls:
secretName: containersteve-com
routes:
- match: /blog
delegate:
name: blog
namespace: marketing
--- apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata:
name: blog
namespace: marketing
spec:
routes:
- match: /blog
services:
- name: blue
port: 80
---
apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata:
name: blog2
namespace: marketing
spec:
routes:
- match: /blog
services:
- name: green
port: 80
Now that those are deployed, we’ll verify the green version by running tests against it.
Once you have tested the new version and are happy with how it is functioning, you can then swap the delegation in the root-blog IngressRoute to point to the green version:
---
apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata:
name: root-blog
namespace: root-ingressroute
spec:
virtualhost:
fqdn: containersteve.com
tls:
secretName: containersteve-com
routes:
- match: /blog
delegate:
name: blog2 # For the swap, blog was changed to blog2 here
namespace: marketing
Shifting Weights
Another way to achieve blue-green deployments with Contour’s IngressRoute is by using the weighting feature. Similar to how Canary deployments were implemented, weights on the upstream services can be manipulated to start out with 100 percent of weight on the blue version and 0 percent on the green version. Then, all at once, you can switch the weights so that 100 percent is targeted at the green version and 0 percent at the blue. In the event of a failure, you can reverse the action quickly and the old version will again receive traffic.
---
apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata:
name: blog
namespace: marketing
spec:
routes:
- match: /blog
services:
- name: blue
port: 80
weight: 100
- name: green
port: 80
weight: 0
What’s Next?
In this post, we have explored how traffic can be routed from a blue deployment to a green deployment within a Kubernetes cluster utilizing IngressRoute, which is one of the many capabilities available in the latest version of Contour.
In future posts, we will explore other patterns enabled by IngressRoute, such as load-balancing strategies.
Join the Contour Community
Get updates on Twitter (@projectcontour) Chat with us on Slack (#contour on Kubernetes) Collaborate with us on GitHub: github.com/heptio/contour
