Kubernetes Deployments
Kubernetes Deployments
Why we need Kubernetes Deployment
In the previous chapter, you learned how to deploy Pods via ReplicaSets. However, workloads are rarely deployed this way because ReplicaSets don’t provide the functionality necessary to easily update these Pods. This functionality is provided by the Deployment object type.
Introducing Kubernetes Deployment
When you deploy a workload to Kubernetes, you typically do so by creating a Deployment object. A Deployment object doesn’t directly manage the Pod objects, but manages them through a ReplicaSet object that’s automatically created when you create the Deployment object. As shown in the next figure, the Deployment controls the ReplicaSet, which in turn controls the individual Pods.
A Deployment allows you to update the application declaratively. This means that rather than manually performing a series of operations to replace a set of Pods with ones running an updated version of your application, you just update the configuration in the Deployment object and let Kubernetes automate the update.
As with ReplicaSets, you specify a Pod template, the desired number of replicas, and a label selector in a Deployment. The Pods created based on this Deployment are exact replicas of each other and are fungible. For this and other reasons, Deployments are mainly used for stateless workloads, but you can also use them to run a single instance of a stateful workload. However, because there’s no built-in way to prevent users from scaling the Deployment to multiple instances, the application itself must ensure that only a single instance is active when multiple replicas are running simultaneously.
Creating a Deployment
Creating a Deployment manifest is trivial if you already have the ReplicaSet manifest. You just need to copy the rs.kiada.versionLabel.yaml file to deploy.kiada.yaml, for example, and then edit it to change the kind field from ReplicaSet to Deployment. While you’re at it, please also change the number of replicas from two to three. Your Deployment manifest should look like the following listing.
apiVersion: apps/v1
kind: Deployment
metadata:
name: kiada
spec:
replicas: 3
selector:
matchLabels:
app: kiada
rel: stable
template:
metadata:
labels:
app: kiada
rel: stable
ver: '0.5'
spec:
...
The spec section of a Deployment object isn’t much different from a ReplicaSet’s. As you can see in the following table, the main fields are the same as the ones in a ReplicaSet, with only one additional field.
| Field name | Description |
|---|---|
| replicas | The desired number of replicas. When you create the Deployment object, Kubernetes creates this many Pods from the Pod template. It keeps this number of Pods until you delete the Deployment. |
| selector | The label selector contains either a map of labels in the matchLabels subfield or a list of label selector requirements in the matchExpressions subfield. Pods that match the label selector are considered part of this Deployment. |
| template | The Pod template for the Deployment’s Pods. When a new Pod needs to be created, the object is created using this template. |
| strategy | The update strategy defines how Pods in this Deployment are replaced when you update the Pod template. |
The replicas, selector, and template fields serve the same purpose as those in ReplicaSets. In the additional strategy field, you can configure the update strategy to be used when you update this Deployment.
To create the Deployment object from the manifest file, use the kubectl apply command.
kubectl apply -f deploy.kiada.yaml
inspecting the Deployment object
You can use the usual commands like kubectl get deployment and kubectl describe deployment to get information about the Deployment you created. For example:
$ kubectl get deploy kiada
NAME READY UP-TO-DATE AVAILABLE AGE
kiada 3/3 3 3 25s
The Pod number information that the kubectl get command displays is read from the readyReplicas, replicas, updatedReplicas, and availableReplicas fields in the status section of the Deployment object. Use the -o yaml option to see the full status.
$ kubectl get deploy kiada -o yaml
Now list the Pods that belong to the Deployment. It uses the same selector as the ReplicaSet from the previous chapter, so you should see three Pods, right? To check, list the Pods with the label selector app=kiada,rel=stable as follows:
$ kubectl get pods -l app=kiada,rel=stable
NAME READY STATUS RESTARTS AGE
kiada-4t87s 2/2 Running 0 16h
kiada-5lg8b 2/2 Running 0 16h
kiada-7bffb9bf96-4knb6 2/2 Running 0 6m
kiada-7bffb9bf96-7g2md 2/2 Running 0 6m
kiada-7bffb9bf96-qf4t7 2/2 Running 0 6m
At the beginning of this chapter, I explained that the Deployment doesn’t directly control the Pods but delegates this task to an underlying ReplicaSet. Let’s take a quick look at this ReplicaSet:
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
kiada-7bffb9bf96 3 3 3 17m
Updating a Deployment
In the previous section where you learned about the basics of Deployments, you probably didn’t see any advantage in using a Deployment instead of a ReplicaSet. The advantage only becomes clear when you update the Pod template in the Deployment. You may recall that this has no immediate effect with a ReplicaSet. The updated template is only used when the ReplicaSet controller creates a new Pod. However, when you update the Pod template in a Deployment, the Pods are replaced immediately.
| Strategy type | Description |
|---|---|
| Recreate | In the Recreate strategy, all Pods are deleted at the same time, and then, when all their containers are finished, the new Pods are created at the same time. For a short time, while the old Pods are being terminated and before the new Pods are ready, the service is unavailable. Use this strategy if your application doesn’t allow you to run the old and new versions at the same time and service downtime isn’t an issue. |
| RollingUpdate | The RollingUpdate strategy causes old Pods to be gradually removed and replaced with new ones. When a Pod is removed, Kubernetes waits until the new Pod is ready before removing the next Pod. This way, the service provided by the Pods remains available throughout the upgrade process. This is the default strategy. |
The following figure illustrates the difference between the two strategies. It shows how the Pods are replaced over time for each of the strategies.
The difference between the Recreate and the RollingUpdate strategies
Enabling the Recreate update strategy in a Deployment
...
spec:
strategy:
type: Recreate
replicas: 3
...
You can add these lines to the Deployment object by editing it with the kubectl edit command or by applying the updated manifest file with kubectl apply. Since this change doesn’t affect the Pod template, it doesn’t trigger an update.
Delete the deployment
Before we get to Deployment updates, which are the most important aspect of Deployments, let’s take a quick look at what happens when you delete a Deployment. After learning what happens when you delete a ReplicaSet, you probably already know that when you delete a Deployment object, the underlying ReplicaSet and Pods are also deleted.
kubectl delete deployment -n
Preserving the ReplicaSet and Pods when deleting a Deployment
If you want to keep the Pods, you can run the kubectl delete command with the --cascade=orphan option, as you can with a ReplicaSet. If you use this approach with a Deployment, you’ll find that this not only preserves the Pods, but also the ReplicaSets. The Pods still belong to and are controlled by that ReplicaSet.
Summary
A Deployment is an abstraction layer over ReplicaSets. In addition to all the functionality that a ReplicaSet provides, Deployments also allow you to update Pods declaratively. When you update the Pod template, the old Pods are replaced with new Pods created using the updated template.
During an update, the Deployment controller replaces Pods based on the strategy configured in the Deployment. In the Recreate strategy, all Pods are replaced at once, while in the RollingUpdate strategy, they’re replaced gradually.