Deploying New App Versions by Using Blue-Green Deployments with Contour’s IngressRoute

April 12, 2019 Steve Sloka

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

Previous
Supercharging Kubernetes Storage with CSI
Supercharging Kubernetes Storage with CSI

Kubernetes adopted the Container Storage Interface, or CSI, which is a community-driven effort to standardi...

Next
Isolated to Conformant: Testing Air-Gapped Kubernetes with Sonobuoy 0.14
Isolated to Conformant: Testing Air-Gapped Kubernetes with Sonobuoy 0.14

Today we are releasing Sonobuoy 0.14.0, which delivers on one of our top roadmap goals: support for running...

SpringOne. All online. All free. Sep 2-3.

Register