Kubernetes Deployment 101

Kubernetes Deployment 101

Get started with Kubernetes deployment: with common Kubernetes deployment tasks and deployment strategies including rolling updates, blue-green, and canary releases.

In this page: Kubernetes basics

Kubernetes has exploded in growth over the past few years because of its powerful abilities to manage containers in production. While it’s easy to spin up your first container locally, taking containers into production in a cloud environment is a completely different ball game. There are numerous aspects like scale, networking, security, high availability, and performance that need to be considered. All of these factors come into play when deploying containers. This makes deployment the most stressful part of running containers in production. Fortunately, Kubernetes is a mature and robust option for running containers in production and has some strong defaults, wide-ranging options, and is a complete package when looking for a tool to deploy containerized applications.

Key Components of Kubernetes

To understand the Kubernetes approach to deployment you need to know the various components that work together.


pod is a group of containers that share common resources like networking and storage and are located on the same node.


A ReplicaSet ensures that all pods have a required number of replicas running at any given time.


A DaemonSet ensures that all active nodes are running at least one pod. It dynamically allocates pods on nodes as they are created and removed.


In Kubernetes, a deployment is a feature that manages pods and ReplicaSets. In other words, as you trigger a release the Deployment controller updates the pods and ReplicaSets by making changes to them or replacing them with newly updated pods and ReplicaSets.


Helm is growing in popularity as a package manager for Kubernetes. It helps manage charts, which are packages of pre-configured Kubernetes resources. Helm can find and install popular software packaged as Kubernetes charts, share applications as Kubernetes charts, create reproducible builds, manage Kubernetes manifest files and releases used for packages.

DockerHub can also automatically scan images in private repositories for vulnerabilities, producing a report detailing vulnerabilities found in each image layer, by severity (critical, major or minor).

Note that multiple private repos, parallel builds and image security scanning are only available with paid subscriptions.

Common Deployment Tasks

Execute a Deployment

To initiate a deployment you need to create a YAML file with the specifications for the deployment using the kubectl create command.

Rollback During a Deployment

Kubernetes always records the change history for deployments in the pod template file. If a deployment has issues and you want to revert to an older version while a deployment is in progress you need to run the rollback command which will stop the existing deployment and start reverting back to the old replicas. This is possible because of the way Kubernetes scales replicas up and down during a deployment.

If you’ve labeled your previous deployments, you can even rollback to a specific previous deployment.

Kubernetes also lets you pause a rollout, update any images that are part of that deployment, and then resume the rollout. This way you can reduce the number of rollouts.

Phases of a Deployment

Kubernetes has multiple phases for a deployment. A deployment can be in progress, complete, or failed. You can view the state of a deployment by running the kubectl rollout status command.

A deployment can fail due to many reasons such as resource constraints, image pull errors, inadequate permissions and more.

Clean-up After a Deployment

After every deployment Kubernetes automatically checks for previous replicas that can be deleted. You specify how many past versions you’d like to keep using the .spec.revisionHistoryLimit field. The default value is 2, and if you set it to 0 all older replicas will be deleted. But ideally, you want to keep some of the older replicas in case you’d like to rollback any deployment.

Deployment Commands

Create a deployment based on a YAML file
kubectl create
Deploy using a phased rolling update
kubectl rollout             
Check the status of a rolling update
kubectl rollout status              
Rollback a recent or ongoing rolling update to a previous version
kubectl rollback              
Option to delete old replicas

Deployment Strategies

There are many approaches to deployment in Kubernetes ranging from the simple to the complex.

Recreate Deployment

In this approach all replicas are killed, and are then replaced by new replicas. It involves some downtime for as long as it takes for the system to shut down and boot up again. This works fine for applications that are used infrequently, and where users don’t expect them to be available 24x7. This is rare in today’s cloud-driven world, and hence, this isn’t the most popular deployment method.

Rolling Update

By default Kubernetes takes a phased approach to updates. When a deployment command is executed, Kubernetes starts to replace existing replicas with the new updated ones one at a time. This scaling up and scaling down of replicas is how Kubernetes manages deployments, and is what makes Kubernetes particularly effective at managing deployments with containers. As discussed earlier, you can rollback a rolling update even when it’s in progress.

Blue-green Deployments

Blue green deployments are not native to Kubernetes, but you can set them up with ease. In this method the ‘blue’ replicas are the existing instances, and they are to be replaced by the ‘green’ replicas.

First, You setup Deployments to rollout the green replicas alongside the blue ones. This would take additional resources to run both the old and new deployments, but not for long. Once the green replicas are deployed and tested, you can use an external load balancer to route traffic from the ‘blue’ replicas to the ‘green’ ones. Tools like Linkerd allow for advanced load balancing so you can define how much and which kind of traffic you’d like to route to which replicas. The biggest advantage of blue-green deployments is that it ensures a smooth transition without any downtime.

Canary Releases

A canary release is when you release a new version of the app to a subset of users, say 5% of all users. Once this version is tested and reliable for the initial 5% it is released to a bigger subset, until eventually all users get updated to the release without experiencing any downtime.

The biggest advantage of canary releases is that they enable you to test the app in real-world conditions and with real users. This brings a big boost in productivity. However, it does take some upfront planning and management along the way to ensure the release is seamless from a user experience point of view.

On the Kubernetes blog, Bitmovin has written about how they implement multi-stage canary deployments. They go into more detail about this type of deployment strategy


Kubernetes is built to manage containers in production, and this is evident in the powerful features it has for deployments. It makes deployments easy by allowing you to control then using a simple YAML configuration file. It can do vanilla deployments where old versions are deleted and replaced by new ones, or it can take more mature approaches like rolling updates, blue-green deployments, and canary releases. You can experiment and find out which best suits your application. By understanding the various Kubernetes components involved in a deployment, and the many options at your disposal, you are now ready to take your Kubernetes deployments to the next level.

Further Reading

  • No labels