Kubernetes: Zero Downtime Release Pattern

<h1>Introduction</h1> <p>As is the nature of software, there will come a point where it’s required to deploy a bug fix or new features. Any Ops team will attest that a release is fraught with worry, that’s because performing a software release has the potential to introduce a new bug or even cause an unplanned outage. Releasing software is somewhat counter productive to the goal of an operations team, which is to maintain stability of the platform. Over the years I’ve heard phrases from colleagues, (even uttered myself), such as:</p> <blockquote> <p>“was this release tested”</p> <p>“what’s the roll back procedure”</p> <p>“how quickly can we patch this”</p> </blockquote> <p>For workloads running within a Kubernetes cluster I’m going to describe a way in which you can release updated container images while minimising the aforementioned risks.</p> <h1>Background</h1> <p>A blue/green deployment strategy is a way to update an application without any downtime. The idea behind it is to have a matching sets of infrastructure, one that’s currently live (the “blue”) and one that’s running the updated code and isn’t actively receiving traffic (the “green”). To avoid confusion <code>blue</code> always refers to the current live infrastructure; <code>green</code> is reserved for the updated, non live infrastructure.</p> <p><a href="https://medium.com/@a.j.abbott24/kubernetes-zero-downtime-release-pattern-942223d6bad3"><strong>Read More</strong></a></p>