Deployments are the best primitive to manage and deploy our software in Kubernetes after version 1.2. They allow us to deploy pods, carry out rolling updates, and roll back pods and ReplicaSets. We can define our desired software updates declaratively using Deployments and then Deployments will do them for us progressively.

Let's take a look at how it works. In this section, we'll get a taste of how a Deployment is created, how to perform rolling updates, and rollbacks. Chapter 9, Continuous Delivery, has more information with practical examples about how we can integrate Deployments into our continuous delivery pipeline.

First, we use the kubectl run command to create deployment for us:

// using kubectl run to launch the Pods
# kubectl run nginx --image=nginx:1.12.0 --replicas=2 --port=80
deployment "nginx" created
// check the deployment status
# kubectl get deployments
NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx     2         2         2            2           4h

There are two pods that are deployed by deployment:

// check if pods match our desired count
# kubectl get pods
NAME                     READY     STATUS        RESTARTS   AGE
nginx-2371676037-2brn5   1/1       Running       0          4h
nginx-2371676037-gjfhp   1/1       Running       0          4h  

The following is a diagram of the relationship between Deployments, ReplicaSets, and pods. In general, Deployments manage ReplicaSets and ReplicaSets manage pods. Note that we shouldn't manipulate ReplicaSets that are managed by Deployments, just like there's no reason to directly change pods if they're managed by ReplicaSets:

If we delete one of the pods, the replaced pod will be scheduled and launched immediately. This is because Deployments create a ReplicaSet behind the scenes, which will ensure that the number of replicas matches our desired count:

// list replica sets
# kubectl get rs
NAME               DESIRED   CURRENT   READY     AGE
nginx-2371676037   2         2         2         4h      

We could also expose the port for deployment using the kubectl command:

// expose port 80 to service port 80
# kubectl expose deployment nginx --port=80 --target-port=80
service "nginx" exposed
// list services
# kubectl get services
NAME         CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   10.0.0.1     <none>        443/TCP   3d
nginx        10.0.0.94    <none>        80/TCP    5s  

Deployments can be created by spec as well. The previous Deployments and Service launched by kubectl can be converted into the following spec:

// create deployments by spec
# cat 3-2-3_deployments.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 2
  template:
   metadata:
    labels:
     run: nginx
   spec:
    containers:
    - name: nginx
      image: nginx:1.12.0
      ports:
      - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
  name: nginx
  labels:
   run: nginx
spec:
  selector:
   run: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      name: http

// create deployments and service
# kubectl create -f 3-2-3_deployments.yaml
deployment "nginx" created
service "nginx" created­­­­  

In order to perform rolling updates, we'll need to add a rolling update strategy. There are three parameters used to control the process:

minReadySecond is an important setting. If our application isn't available immediately when the pod is up, the pods will roll too fast without proper waiting. Although all of the new pods are up, the application might be still warming up; there's a chance that a service outage might occur. In the following example, we'll add the configuration into the Deployment.spec section:

// add to Deployments.spec, save as 3-2-3_deployments_rollingupdate.yaml
minReadySeconds: 3
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 1

This indicates that we allow only one of the pods to be unavailable at any time and one pod to be launched when rolling the pods. The warm-up time before proceeding to the next operation is three seconds. We can use either kubectl edit deployments nginx (edit directly) or kubectl replace -f 3-2-3_deployments_rollingupdate.yaml to update the strategy.

Let's say we want to simulate a new software rollout from nginx 1.12.0 to 1.13.1. We can still use the preceding two commands to change the image version or use kubectl set image deployment nginx nginx=nginx:1.13.1 to trigger the update. If we use kubectl describe to check what's going on, we'll see that Deployments have triggered rolling updates on ReplicaSets by deleting/creating pods:

// list rs
# kubectl get rs
NAME             DESIRED CURRENT READY AGE
nginx-596b999b89 2       2       2     2m

// check detailed rs information
# kubectl describe rs nginx-596b999b89
Name: nginx-596b999b89
Namespace: default
Selector: pod-template-hash=1526555645,run=nginx
Labels: pod-template-hash=1526555645
        run=nginx
Annotations: deployment.kubernetes.io/desired-replicas: 2
             deployment.kubernetes.io/max-replicas: 3
             deployment.kubernetes.io/revision: 1
Controlled By: Deployment/nginx
Replicas: 2 current / 2 desired
Pods Status: 2 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels: pod-template-hash=1526555645
          run=nginx
  Containers:
   nginx:
    Image: nginx:1.12.0
    Port: 80/TCP
    Host Port: 0/TCP
Events:
  Type Reason Age From Message
  ---- ------ ---- ---- -------
  Normal SuccessfulCreate 3m41s replicaset-controller Created pod: nginx-596b999b89-th9rx
  Normal SuccessfulCreate 3m41s replicaset-controller Created pod: nginx-596b999b89-2pp7b

The following is a diagram of how rolling update works in a Deployment:

The preceding diagram shows an illustration of a Deployment. At a certain point in time, our desired count is 2 and we have one maxSurge pod. After launching each new pod, Kubernetes will wait three seconds (minReadySeconds) and then perform the next action.

If we use the kubectl set image deployment nginx nginx=nginx:1.12.0 command to roll back to the previous version 1.12.0, Deployments will do the rollback for us.