Deployments

PODs deploy single instance of our application. Each container is encapuslated in the POD.
Multiple such PODs are deployed using replication controllers or replicasets.
Deployment is the kubernetes object that comes higher in the hierarchy. Deployment provides us with the capability to upgrade the underlying instances seemlessly using rolling updates, undo changes, pause and resume changes as required.

To create a deployment we first create a deployment definition yaml file. The contents of deployment definition file will be similar to the replicaset definition file, except the kind, which will be deployment.

kubectl create -f <deployment definition file>
To create the deployment.

kubectl get deployments
To view the created deployments. The deployment automatically creates replicaset.

kubectl describe deployment <deploymnet name>
To get more information about the particular deployment.

kubectl get replicasets
To view the available replicasets.
Here, we can see a new replicaset in the name of the deployment.
replicaset ultimately create pods.

kubectl get pods
We can able to see the pods in the name of the deployment and the replicaset.

kubectl get all
To view all the objects created in the kuberntes cluster.

Update and Rollback

Rollout and Versioning

When we first create a deployment, it triggers a rollout. A new rollout creates a new deployment revision, lets call it revision 1.
In future when the application is upgraded i.e., when the container version is updated to a new one, a new rollout is triggered and a new deployment revision is created named revision 2.
This helps us to keep track of changes made to our deployment and enables us to rollback to previous versions of deployment if necessary.

kubectl rollout status <deployment name>
To view the status of our rollout

kubectl rollout history <deployment name>
To view the revisions and history of deployment.

Deployment Strategies

There are two types of deployment strategies.

For example: we have 5 replicas of web application instance deployed.
One way to upgrade these to newer version is to destroy all of these instances and then create newer versions of application instances.
First destroy the 5 running instances and then deploy 5 new instances of new application version. The problem with this is during the period after the older versions are down and newer versions are up, the application is down and inaccessible to users.
This strategy is called Recreate strategy.

The second strategy is where we don't destroy all of the instances at once, instead we take down the older version and bring up the newer version one by one. This way the application never goes down and the upgrade is seamless. This strategy is called Rolling Update strategy.
If we do not specify a strategy while creating deployment, it will assume it to be rolling update.
Rolling Update is the default deployment strategy.

kubectl apply

Updating the deployment could be different things like updating the application version by updating the version of docker containers used, updating the labels or updating the number of replicas etc,. As we have depolyment definition file, it will be easy for us to modify this file.

Once we make necessary changes to the file run kubectl apply -f <deployment definition file> to apply changes. A new rollout is triggered and a new revision of the deployment is created.

Other way to update the image version of application is
kubectl set image <deployment name> <oldimage=newimage>
kubectl set image deployment/myapp-deployment nginx=nginx:1.9.1
In this way, definition file will have old image version and we need to be extra careful when we use this definition file to make changes in the future.

Upgrades (how deployment performs upgrade)

When a new deployment is created to deploy 5 replicas,it first creates a replicaset automatically which inturn creates the number of PODs required to meet the number of replicas.
When we upgrade our application, the kubernetes deployment object creates a new replicaset and starts deploying the containers there. At the same taking down the pods in the old replicaset following a rolling update strategy.

When we upgrade our application, we can see old replicaset with 0 pods and new replicaset with 5 replicas using the following command.
kubectl get replicasets

Rollback

For an instance, after we upgrade our application, we realise that there is something wrong with newer version of build we used to upgrade and so we would like to rollback the upgrade.
Kubernetes deployments allow to rollback to a previous revision.
To undo a change kubectl rollout undo <deployment name>
The deployment then destroy the pods in the new replicaset and bring the older ones up in the older replicaset and the application is back to its older format.

Kubectl run

We use kubectl run command to create a POD.
kubectl run nginx --image=nginx
This command creates a deployment, not just a POD.
This is one more way of creating deployments without having definition file. The required replicaset and PODs are created automatically in the backend.
Using the definition file is recommended, as we can save the file, check it into the code repository and modify later as required.

Summarize Commands

Create

kubectl create -f <deployment definition file>

Get

kubectl get deployments

Update

kubectl apply -f <deployment definition file>
kubectl set image <deployment name> <oldimage=newiamge>

Status

kubectl rollout status <deployment name>
kubectl rollout history <deployment name>
kubectl rollout undo <deployment name>

Scale

To scale up the deployment
kubectl scale deployment <deployment name> --replicas=3