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

in Kubernetes

YAML, Pods, Deployments, and ReplicaSets

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 apply -f deployment.yaml

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

    $ kubectl get deployments.apps
    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    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   AGE
    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.

    Get similar stories in your inbox weekly, for free

    Share this story:

    Founder and CEO of Cloudplex - We make Kubernetes easy for developers.


    Latest stories

    How ManageEngine Applications Manager Can Help Overcome Challenges In Kubernetes Monitoring

    We tested ManageEngine Applications Manager to monitor different Kubernetes clusters. This post shares our review …

    AIOps with Site24x7: Maximizing Efficiency at an Affordable Cost

    In this post we'll dive deep into integrating AIOps in your business suing Site24x7 to …

    A Review of Zoho ManageEngine

    Zoho Corp., formerly known as AdventNet Inc., has established itself as a major player in …

    Should I learn Java in 2023? A Practical Guide

    Java is one of the most widely used programming languages in the world. It has …

    The fastest way to ramp up on DevOps

    You probably have been thinking of moving to DevOps or learning DevOps as a beginner. …

    Why You Need a Blockchain Node Provider

    In this article, we briefly cover the concept of blockchain nodes provider and explain why …

    Top 5 Virtual desktop Provides in 2022

    Here are the top 5 virtual desktop providers who offer a range of benefits such …