Difficulty: beginner
Estimated Time: 5-10 minutes


The Kubernetes documentation states that a Deployment allows you to:

... describe a desired state in a Deployment object, and the Deployment controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.

In this scenario, we’ll explain both how Deployments work from a high-level perspective, and then get our hands dirty by creating a Deployment and seeing how it relates to ReplicaSet and Pod objects.

Congratulations. You've now created, manipulated and deleted a Deployment, both through the Kubernetes CLI (kubectl) and through YAML manifests.

If you have any questions, please speak to the host.

You are free to continue onto the next scenario in this course.

Don’t stop now! The next scenario will only take about 10 minutes to complete.

Basic Deployments

Step 1 of 4

Creating a deployment through kubectl

Kubernetes deployments manage stateless services running in your cluster (as opposed to - for example - StatefulSets, which manage stateful services). Their purpose is to keep a set of identical pods running and upgrade them in a controlled way – performing a rolling update by default. There are different deployment strategies that work with Deployments. They are, however, out of scope of this scenario. For more information on deployment strategies, read the Kubernetes Documentation here.


Creating a Deployment in kubectl

Before we start, you should already have a namespace created called contino. If you do not have this namespace yet, or you have deleted it, then please re-create it:

kubectl create namespace contino

Create a basic deployment called nginx-deployment using the nginx image, and expose port 80 in the container:

kubectl run nginx-deployment -n contino --image=nginx --port 80

$ kubectl run nginx-deployment -n contino --image=nginx --port 80

deployment.apps "nginx-deployment" created

Now let's inspect the deployment that we've just created:

kubectl get deployment nginx-deployment -n contino -o yaml

apiVersion: extensions/v1beta1
kind: Deployment
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: 2018-08-07T18:30:51Z
  generation: 1
    run: nginx-deployment
  name: nginx-deployment
  namespace: contino
  resourceVersion: "849"
  selfLink: /apis/extensions/v1beta1/namespaces/contino/deployments/nginx-deployment
  uid: 035c4414-9a70-11e8-a7a6-0242ac110067

The metadata contains the name of the deployment (which must be unique), an internal uid used by Kubernetes, and the annotations object. It contains one annotation, namely that the current deployment revision is 1. Also as seen in other scenarios throughout this course, each object in Kubernetes can have a set of labels, which are key-value pairs.

Take Away Point: Label everything!

Deployment Object

Next, we're going to cover the main deployment object, or spec.

  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
      run: nginx-deployment
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
      creationTimestamp: null
        run: nginx-deployment
      - image: nginx
        imagePullPolicy: Always
        name: nginx-deployment
        - containerPort: 80
          protocol: TCP

The spec (specification) of the deployment has two keys you must set:

  • replicas: describes how many pods this deployment should have. In our case, there will be one only one pod created.
  • template: describes how each pod should look like. It describes a list of containers that should be in the Pod.

The two other keys can be set to customize the behavior of the deployment.

  • selector: determines which pods are considered to be part of this deployment. This uses labels to 'select' pods.
  • strategy: states how an update to a deployment should be rolled out. See earlier at the start of this chapter for the Kubernetes API link on more information on deployment strategies.