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
    metadata:
      labels:
        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
    metadata:
      labels:
        app: nginx-deployment
      name: nginx-deployment
      namespace: default
    spec:
      progressDeadlineSeconds: 600
      replicas: 3
      revisionHistoryLimit: 10
      selector:
        matchLabels:
          app: nginx-pod
      strategy:
        rollingUpdate:
          maxSurge: 25%
          maxUnavailable: 25%
        type: RollingUpdate
      template:
        metadata:
          labels:
            app: nginx-pod
        spec:
          containers:
          - image: nginx:1.18
            imagePullPolicy: IfNotPresent
            name: nginx-pod
            command:
            - '/docker-entrypoint.sh'
            args:
            - 'nginx'
            - '-g'
            - 'daemon off;'
            env:
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  apiVersion: v1
                  fieldPath: metadata.namespace
            resources:
              requests:
                cpu: 200m
                memory: 120Mi
            livenessProbe:
              failureThreshold: 5
              httpGet:
                path: /
                port: 80
                scheme: HTTP
            readinessProbe:
              failureThreshold: 3
              httpGet:
                path: /
                port: 80
                scheme: HTTP
            ports:
            - 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.

    Conclusion

    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 with your friends
    cloudplex
    Cloudplex

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

    Latest stories


    What Developers Think About GitHub Copilot

    GitHub Copilot is a controversial developer assistant introduced to the public in June 2021. It …

    Why Golang Is Widely Used in the DevOps and Cloud Native Space?

    The Golang programming language has been rising to popularity in the DevOps community in recent …

    The app used by the organization's staff for their activities, Facebook Workplace, is also down.
    Facebook, WhatsApp, Instagram Prolonged Downtime: Facts and Impacts

    A news report on a recent outage to the apps managed by Facebook inc.

    What are the criteria for selecting a Magento agency?

    Magento development company can help the business step up its eCommerce website to ensure its …

    7 Remote Working Tools That Simplify Your Work

    With the tools mentioned below, remote work has proven to become much more manageable.