Get Started Free

This is What You Need to Know About Kubernetes YAML, Pods, Deployments, and ReplicaSets (3/3)

We are going to dive deep into Kubernetes Deployments and understand the structure of a YAML Deployment file. You already understood the differences between Pods and Deployments in part I and part II of this tutorial. Now, you are going to create a managed Pod using Kubernetes Deployments.

Using Deployments to Create and Manage Kubernetes Pods

The recommended way to manage stable deployments in Kubernetes should be done by using the Deployment, ReplicaSet, and Pod resources together.

It may seem that this solution is trickier than just deploying Pods; however, that is not really the case since we only need to define the Deployment resource and the Replicaset while our Pods will be created automatically.

To better illustrate this, the Deployment resource will automatically create a ReplicaSet resource for the defined services, and the latter will take care of maintaining the service pods.

The YAML definition file for the Deployment object consists of the same four sections as other Kubernetes resources. Deployment resource API version is apps/v1, and obviously, the kind of the resource is Deployment. Below is a snippet for defining the first three sections for a Deployment resource.

apiVersion: apps/v1
kind: Deployment
    app: nginx
  name: nginx-deployment

The fourth section is the spec section, where we can define all the needed configurations for our Deployment.

Below is a brief description of the minimal configurations that need to be provided in any Deployment resource YAML definition.

  • template: The Pod template describes the Pods created for the Deployment object. The template is basically an embedded PodSpec resource. It defines containers, init containers our Deployment manages.
  • selector: A key-value pair used to identify the Pods managed by the Deployments, the key-value pair must match the same label assigned to the Pods in the Pod template. This key-value is very important to be able to enable features like rollout, rollback, and high availability.

The Deployment resource has a couple of optional specifications such as:

  • replicas: The number of Pods to be created. The default value is 1.
  • minReadySeconds: The minimum number of seconds that should elapse before considering the Pod as a healthy and available pod. The default value is 0.
  • revisionHistoryLimit: Defines how many old ReplicaSets for this Deployment you want to retain. The Default value is 10.
  • Strategy: The strategy used to roll out updates of new versions. There are two strategies supported currently the Recreate strategy where old pods are deleted first, and then new pods will be created. The other strategy is RollingUpdate, where pods are replaced gradually. The Default value is RollingUpdate.

Below is a complete example of defining Deployment resources for the same application we deployed before with only Pod resource. As it is shown, the Deployment resource contains the Pod and ReplicaSet specs as well as defining the deployment specs such as the deployment strategy.

apiVersion: apps/v1
kind: Deployment
    app: nginx-deployment
  name: nginx-deployment
  namespace: default
  progressDeadlineSeconds: 600
  replicas: 3
  revisionHistoryLimit: 10
      app: nginx-pod
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
        app: nginx-pod
      - image: nginx:1.18
        imagePullPolicy: IfNotPresent
        name: nginx-pod
        - '/'
        - 'nginx'
        - '-g'
        - 'daemon off;'
        - name: POD_NAMESPACE
              apiVersion: v1
              fieldPath: metadata.namespace
            cpu: 200m
            memory: 120Mi
          failureThreshold: 5
            path: /
            port: 80
            scheme: HTTP
          failureThreshold: 3
            path: /
            port: 80
            scheme: HTTP
         - containerPort: 80
          name: http
          protocol: TCP
        dnsPolicy: ClusterFirst
        enableServiceLinks: true
        nodeName: node01
        priority: 0
        restartPolicy: Always
        schedulerName: default-scheduler
        securityContext: {}
        serviceAccount: default
        serviceAccountName: default
        terminationGracePeriodSeconds: 30

Use the below command to deploy the above Deployment.

$ kubectl run nginx-pod --image=nginx --dry-run=client -o=yaml

The Kubectl command line provides several generating commands that can be used to create resources even without writing the YAML definition files for the resources. For instance, creating a pod that is running Nginx can be done simply by executing the following command.

$ kubectl apply -f deployment.yaml

To verify the status of the deployment, you can run the following command.

$ kubectl get deployments.apps
nginx-deployment   3/3     3            3           36s

You can also check the status of the ReplicaSet and Pods behind the deployment using the following commands.

master $ kubectl get replicasets.apps
NAME                          DESIRED   CURRENT   READY   AGEE
nginx-deployment-6f46687dcf   3         3         3       48s
master $ kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-6f46687dcf-6ptdh   1/1     Running   0          65s
nginx-deployment-6f46687dcf-l7d8j   1/1     Running   0          65s
nginx-deployment-6f46687dcf-r9x7h   1/1     Running   0          65s

In case there are some updates done on the Deployment, you will be able to see more than one ReplicaSet, and you can choose to roll back to one them.


Kubernetes offers a wide range of resources that can be used for managing deployments of applications. The purpose and the needs of each of these resources are different. However, they need to be used together to support highly available and stable services in Kubernetes clusters.

This post explained the purpose and the differences between three Kubernetes resources Pods, Replicasets, and Deployments.

Managing these Kubernetes resources by following this tutorial is the recommended way because it guarantees the stability and scalability of the services.

Asad Faizi

Founder CEO, Inc

Start building app

Start building your cloud native application

134470cookie-checkThis is What You Need to Know About Kubernetes YAML, Pods, Deployments, and ReplicaSets (3/3)