Getting Started with Deploying Releases

Deploying releases

In today’s competitive environment, we have to release features to production as soon as they are developed and tested. The need for frequent releases fortifies the need for zero-downtime Deployments.

We learned how to deploy our applications packaged as Pods, scale them through ReplicaSets, and enable communication through Services. However, all that is useless if we cannot update those applications with new releases. That is where Kubernetes Deployments are useful.

The desired state of our applications is changing all the time. The most common reasons for new states are new releases. The process is relatively simple. We make a change and commit it to a code repository. We build and test it. Once we’re confident that it works as expected, we deploy it to a cluster.

It does not matter whether the Deployment is to a development, test, staging, or production environment. We need to deploy a new release to a cluster, even when it is a single-node Kubernetes running on a laptop. No matter how many environments we have, the process should always be the same or, at least, as similar as possible.

Why zero downtime?

The Deployment must produce no downtime. It does not matter whether it is performed on a testing or a production cluster. Interrupting consumers is disruptive and leads to a loss of money and confidence in a product.

Gone are the days when users did not care if an application sometimes did not work. There are so many competitors out there that a single bad experience might lead users to another solution. With today’s scale, a 0.1% rate of failed requests is considered disastrous.

While we might never be able to reach 100% availability, we should certainly not cause downtime ourselves and must minimize other factors that could cause downtime.

Kubernetes Deployments

Kubernetes Deployments provide us with the tools that can help us avoid such failures by allowing us to update our applications without downtime.