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-kubia-ssl.yaml file to dp-kubia-ssl.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.

root@AlexRampUpVM-01:~# cat dp-kubia-ssl.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kubia
spec:
  replicas: 3
  selector:
    matchLabels:
      app: kubia
      rel: stable
  template:
    metadata:
      labels:
        app: kubia
        rel: stable
    spec:
      containers:
      - name: kubia
        image: luksa/kubia:1.0
        ports:
        - name: http
          containerPort: 8080
      - name: envoy
        image: luksa/kubia-ssl-proxy:1.0
        ports:
        - name: https
          containerPort: 8443
        - name: admin
          containerPort: 9901
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

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.

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.

root@AlexRampUpVM-01:~# kubectl apply -f dp-kubia-ssl.yaml
deployment.apps/kubia created
1
2

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:

root@AlexRampUpVM-01:~# kubectl get deploy kubia
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
kubia   3/3     3            3           40s
1
2
3

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.

root@AlexRampUpVM-01:~# kubectl get deploy kubia -o yaml
1

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=kubia,rel=stable as follows:

root@AlexRampUpVM-01:~#  kubectl get pods -l app=kubia,rel=stable
NAME                    READY   STATUS    RESTARTS   AGE
kubia-6f8d9dd87-2xdht   2/2     Running   0          88s
kubia-6f8d9dd87-w25cl   2/2     Running   0          88s
kubia-6f8d9dd87-w8qpt   2/2     Running   0          88s
1
2
3
4
5

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:

root@AlexRampUpVM-01:~# kubectl get rs
NAME                       DESIRED   CURRENT   READY   AGE
kubia-6f8d9dd87            3         3         3       107s
1
2
3

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.

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
 ...
1
2
3
4
5
6

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 
1

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.