- Deployment is a controller which wraps Pod/s and manages its life cycle, which is to say actual state to the desired state.
- There is one more layer in between Deployment and Pod which is ReplicaSet.
- A pod is the basic building block for Kubernetes and it groups one or more containers (such as Docker containers), with shared storage/network, and a specification for how to run the containers.
As you saw, we can manage the application with pods and replica set then why there is one more layer on top of a replica set.
So some of you might be wondering, why are we complicating things by adding a deployment layer on top of a replica set, and why can’t we just use a replica set in straight?
So whenever we deploy an application, there are a few things that need to consider:
- Scaling up and down of the application
- Roll out of the application — v1.0 — v1.1
- Rollback of the application — v1.1 — v1.0
- No downtime when deploying the newer version of the application
- Different strategies of deployment.
All the above feature is provided by the deployment controller.
In real-time, all we have to create is deployment only, this will take care of the rest of creating and managing replica sets and Pods.
- Deployment features are defined into two categories.
- So this first category mainly deals with the rollout of the application, pause and resume and application rollback ie. application upgrades back to their previous stable stage.
- The scaling department uses the replica set to create multiple instances of pods that provide self-healing and high availability to the application.
- We can scale up and down of the application depending upon the traffic of the application.
So there are multiple ways to deploy and upgrade applications and these are called deployment strategies.
- This strategy of deployment in Kubernetes is a dummy deployment.
- In this strategy, we need to shut down version A then deploy version 2.
This deployment strategy will slowly roll out the newer version of an application by replacing the older versions one after the other until all the instances are successfully rolled out.
- Release a new version to a subset of users, then proceed to a full rollout.
- we use the Canary deployment strategy to test a newer version of the application before it is fully rolled out.
- Using this deployment the strategy will deploy the same number of newer version pods.
- If the new version of pods is working fine then traffic is shifted from version A to version B at the load balancer level.