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
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.