Kubernetes Deployment resources help to manage deployments for container applications. They are typically used for managing stateless workloads. You can still use them to manage stateful applications, but the recommended approach for stateful applications is to use StatefulSet resources.
Kubernetes Deployments use ReplicaSet resources as a backend, and the chain of resources looks like what’s shown in the following diagram:
Figure 6.1 – Deployment chain
Let’s take the preceding example and create an nginx Deployment resource manifest—nginx-deployment.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
The manifest is very similar to the ReplicaSet resource, except for the kind attribute—Deployment, in this case.
Let’s apply the manifest by using the following command:
$ kubectl apply -f nginx-deployment.yaml
So, as the Deployment resource has been created, let’s look at the chain of resources it created. Let’s run kubectl get to list the Deployment resources using the following command:
$ kubectl get deployment
NAME
READY
UP-TO-DATE AVAILABLE AGE
nginx
3/3
3
3
6s
And we see there is one Deployment resource called nginx, with 3/3 ready pods and 3 up-to-date pods. As Deployment resources manage multiple versions, UP-TO-DATE signifies whether the latest Deployment resource has rolled out successfully. We will look into the details of this in the subsequent sections. It also shows 3 available pods at that time.
As we know Deployment resources create ReplicaSet resources in the background, let’s get the
ReplicaSet resources using the following command:
$ kubectl get replicaset
NAME
DESIRED
CURRENT
READY
AGE
nginx-6799fc88d8
3
3
3
11s
- Managing Advanced Kubernetes Resources
And we see that the Deployment resource has created a ReplicaSet resource, which starts with nginx and ends with a random hash. That is required as a Deployment resource might contain one or more ReplicaSet resources. We will look at how in the subsequent sections.
Next in the chain are pods, so let’s get the pods using the following command to see for ourselves:
| $ kubectl get pod | ||||
| NAME | READY | STATUS | RESTARTS | AGE |
| nginx-6799fc88d8-d52mj | 1/1 | Running | 0 | 15s |
| nginx-6799fc88d8-dmpbn | 1/1 | Running | 0 | 15s |
| nginx-6799fc88d8-msvxw | 1/1 | Running | 0 | 15s |
And, as expected, we have three pods. Each begins with the ReplicaSet resource name and ends with a random hash. That’s why you see two hashes in the pod name.
Let’s assume you have a new release and want to deploy a new version of your container image. So, let’s update the Deployment resource with a new image using the following command:
$ kubectl set image deployment/nginx nginx=nginx:1.16.1 deployment.apps/nginx image updated
To check the deployment status, run the following command:
$ kubectl rollout status deployment nginx
deployment “nginx” successfully rolled out
Imperative commands such as those just shown are normally not used in production environments because they lack the audit trail you would get with declarative manifests using Git to version them. However, if you do choose to use imperative commands, you can always record the change cause of the previous rollout using the following command:
$ kubectl annotate deployment nginx kubernetes.io/change-cause\ =”Updated nginx version to 1.16.1″ –overwrite=true deployment.apps/nginx annotated
To check the Deployment history, run the following command:
$ kubectl rollout history deployment nginx
deployment.apps/nginx
REVISION CHANGE-CAUSE
- <none>
- Updated nginx version to 1.16.1
As we can see, there are two revisions in the Deployment history. Revision 1 was the initial Deployment, and revision 2 was because of the kubectl set image command we ran, as evident from the CHANGE-CAUSE column.
Let’s say you find an issue after Deployment and want to roll it back to the previous version. To do so and also recheck the status of the Deployment, run the following command:
$ kubectl rollout undo deployment nginx && kubectl rollout status deployment nginx deployment.apps/nginx rolled back
Waiting for deployment “nginx” rollout to finish: 2 out of 3 new replicas have been updated…
Waiting for deployment “nginx” rollout to finish: 1 old replicas are pending termination…
deployment “nginx” successfully rolled out
And finally, let’s recheck the deployment history using the following command:
$ kubectl rollout history deployment nginx
deployment.apps/nginx
REVISION CHANGE-CAUSE
- Updated nginx version to 1.16.1
- <none>
And we get revision 3 with a CHANGE-CAUSE value of <none>. In this case, we did not annotate the rollback as in the last command.
Tip
Always annotate Deployment updates as it becomes easier to peek into the history to see what got deployed.
Now, let’s look at some common Kubernetes Deployment strategies to understand how to use Deployments effectively.
