Best practices to achieve Zero downtime

on Kubernetes deployments

What is Zero downtime deployment?

Whether you are upgrading your application version, scaling up, or

scaling down, if your end-user/customer has the access to your
application 24x7 without any disruption or failure, then you can say
your application has achieved zero-downtime deployment.
Let’s discuss some of the best practices for Kubernetes zero downtime
deployment…(●'◡'●)

⭐ReplicaSet

A good idea is to have a minimum of 3 ReplicaSet for any application

deployment. Because if any 1–2 of them crushes there will always be a
3rd pod which will be up and running.

⭐podAntiAffinity

When we do multiple ReplicaSet deployments, it doesn’t ensure to be

deployed in different Nodes. In that case, let's suppose 3 ReplicaSet
deployed in the same node, and the node crushes. So, now your service
will be unreachable. 😑

The best decision is to always define the podAntiAffinity field in your

deployment configuration file. Let’s take a quick example here…

Say, you want to deploy a Redis cache, and you want to have the cache
server to be in different nodes.

To achieve that your Redis cache deployment file should have

the podAntiAffinity field declared like this 👇

⭐Resource Declaration
It’s always a best practice to declare the minimum and maximum
resources required for your deployment. The reason behind this is-

When Scheduler checks the resource usage and tries to find a suitable

node for the deployment. It might be a chance that the deployment is
scheduled to an overused node 🤢. The reason for that is your
deployment specification does not indicate how much resources you
actually required.

⭐Readiness & Liveness Probe

If my Pod is running that doesn’t mean, it’s working fine and can
handle the traffic.

Sometimes, applications are temporarily unable to serve traffic. For

example, an application might need to load large data or configuration
files during startup or depend on external services after startup. In
such cases, you don’t want to kill the application, but you don’t want to
send it requests either. So, to deal with this you should define a
readiness probe.

Sometimes, your application is running, but unable to make progress.

Restarting a container in such a state can help to make the application
more available despite bugs. Here, liveness probes could catch a
deadlock and help you to restart the container. Read more
The kubelet uses readiness probes to know when a container
is ready to start accepting traffic.

The kubelet uses liveness probes to know when to restart a

container.

⭐Rolling Update

By default, K8s work on Rolling update strategy. It allows deployment

to take place with zero downtime by incrementally updating Pods
instances with new ones. We can customize maxSurge (how many
pods we can add at a time) and maxUnavailable (maxUnavailable
defines how many pods can be unavailable during the rolling update)
from the deployment configuration.
e.g, to customize the RollingUpdate fields

📎If we want to test with some partial traffic first and then want to go
for actual traffic, we can use the Canary Deployment strategy to
achieve that. We can point some percentage of traffic (as canary
weight) to our new application version. If everything stays ok, we can
point the service fully to the new application version.
There are various deployment strategies through which we can achieve
different requirements. I will discuss different deployments strategy
in-depth in another post.

⭐preStop lifecycle hook

It’s always a better idea to define preStop container lifecycle hook. The
reason being is, that it’ll maintain good cluster health while
destroying/stopping a running pod.

F inally, Whenever you go for your next deployment, try to keep

these things in place so that your cluster will not suffer from any of the
above-mentioned situations.

T H A N K 🙏Y O U, have a good dep