Mastering Kubernetes One Task at a Time — Pods, Deployments, and ReplicaSets

Learn how to manage a stateless application workload by running the right number of the right kind of pods matching a specification always.

Table of Contents

1. Introduction
2. Remember the Relationship — Pod vs. Deployment vs. ReplicaSet
3. Create and Access KIND Kubernetes Cluster on EC2
4. Create a Deployment
5. Update a Deployment with Rolling Update Strategy
6. Roll Back a Deployment Update
7. Scale a Deployment
8. BONUS — Deployment Edit Commands Summary
9. Conclusion

Introduction

The previous chapter, Containers and Pods, was a gentle introduction to understanding and learning how to write pods. If you missed reading the blog post, follow the link below. If you’re just interested in browsing the code to see what was covered, take a quick browse of de>containers-and-pods.sh script at the Mastering Kubernetes One Task at a Time Series Hands-On Scripts GitHub repo.

This chapter’s emphasis is on Pods, Deployments, and ReplicaSets, the first of the four groups of Kubernetes built-in Workload Resources as listed below. The rest will be covered in the subsequent posts.

1. Deployment and ReplicaSet — to manage a stateless application workload on a cluster, where any Pod in the Deployment is interchangeable and can be replaced if needed.
2. StatefulSet — to manage a stateful application by providing a guarantee about the ordering and uniqueness of the pods.
3. DaemonSet — to manage pods that must run on each cluster node, including existing and future nodes.
4. Job and CronJob — to manage one-off and recurring scheduled tasks that run to completion.

Kubernetes.io — Workloads provides detailed documentation and is a good place to visit to learn more about these groups.

Remember the Relationship — Pod vs. Deployment vs. ReplicaSet

Before we tackle the first group of the Kubernetes Workload Resources hands-on, the following minimum theory should be understood about the three resources.

Remember the Relationship — A Deployment controls the ReplicaSet and a ReplicaSet controls the Pods. The description of a ReplicaSet and a Pod reveals that truth.

1. Kubernetes.io — Pods page teaches everything one needs to know about a pod. We’ve already looked at the basics of creating and interacting with a pod in the last post. Eventually, we’ll end up learning how to write and manage complex pods, including pods with multiple containers, static pods, etc. For our purpose here, it is sufficient to know that in a Kubernetes cluster, (a) a Pod is the smallest deployable unit of computing; (b) it models an application-specific “logical host,” and (c) from an application architecture perspective; pods are often managed by a Kubernetes controller like a Deployment to support scaling and maintain resiliency. That basically means a new pod is created automatically if it loses its host node for some reason, or a pod was manually deleted, or it was added for horizontal scaling.
2. A Deployment provides a declarative configuration for Pods and ReplicaSets. The Deployment Controller changes the actual state to the desired state based on the desired state in the specification. The state change occurs at a controlled rate by creating, deleting, and replacing pods as necessary, matching the deployment configuration.
3. A ReplicaSet guarantees the running of a specified number of identical Pods to maintain a stable set of replica Pods matching the Deployment specification. In practice, even though it can be done independently, we usually don’t need to manipulate ReplicaSet objects directly but use a Deployment instead to define our application in the spec section.

Having gone through the theoretical distinctions of the three, we are now ready to explore Deployment in-depth and learn how to create and manage stateless applications through this resource. We won’t cover Pods and ReplicaSets directly but through the lens of Deployment.

Create and Access KIND Kubernetes Cluster on EC2

Let’s access the cluster after getting it up and running. Refer to The AWS Way — IaC in Action — A Docker and KIND Ready Amazon EC2 Node blog for a detailed explanation if you’re doing it for the first time. If you’ve done it before, it’s mere repetition.

Create a Deployment

We will demonstrate four use cases to cover the most important capabilities of a Deployment, focusing on the ReplicaSets, Pods, Update, Rollback, and Scaling. In the end, I’ll show the three common ways to edit a deployment.

As always, if you want to see and execute the whole script on your own, you will find it on GitHub at de>jdluther-kubernetes-io-tasks/pods-deployments-replicasets.sh. The script, along with the entire repository, is already cloned inside the EC2 running the KIND cluster.

In this section, we are creating a deployment from scratch. All the commands are shown below. Issuing the command one after another is all that’s needed to witness the workings of a Deployment with the power of the kubectl capabilities.

Update a Deployment with Rolling Update Strategy

There are a few things to learn about how a Deployment update works in accordance with a rolling update strategy. Since we haven’t specified one in our example, the default strategy is at work here.

1. A Deployment’s rollout is triggered if and only if the Deployment’s Pod template (that is .spec.template) is changed, for example, if the labels or container images of the template are updated. Other updates, such as scaling the Deployment, do not trigger a rollout.
2. See in action how the ReplicaSets are controlled by the Deployment and the pods by the ReplicaSet. Peeking inside the output of the command kubectl describe rs nginx-deployment-5555cdd897 will show Controlled By: Deployment/nginx-deployment line. Similarly kubectl describe pod nginx-deployment-5555cdd897-t8mqh command output will have the Controlled By: ReplicaSet/nginx-deployment-5678479d89 line.
3. The kubectl describe deployments nginx-deployment output shows the rolling update strategy (default) in action. It first creates a new Pod, then deletes an old Pod, and creates another new one. It does not kill old Pods until a sufficient number of new Pods have come up and does not create new Pods until a sufficient number of old Pods have been killed. It makes sure that at least 3 Pods (desired state) are available and that at max 4 Pods (max surge) in total are available.

Roll Back a Deployment Update

Sometimes the updates can go awry, and Kubernetes provides speedy rollback options to remedy such situations, as demonstrated below. By default, all of the Deployment’s rollout history is kept in the system so that one can roll back anytime if a situation necessitates it.

Scale a Deployment

Below is a demonstration of simple scaling up the replica counts and scaling down. Of course, this is a basic illustration. In serious production implementation, HPA (Horizontal Pod Autoscaler) fills this role by automatically scaling up and down. I plan to cover HPA in a post by itself.

BONUS — Deployment Edit Commands Summary

Let’s wrap up by compiling the summary of commands commonly used to edit deployments. There are three common ways to edit a Deployment:

1. By making live configuration changes via kubectl edit command.
2. Imperatively, see both commands below.
3. Changing and applying the Deployment specification manifest file. This is preferred since the first two ways can be overwritten unless changes have been reflected and preserved in the manifest file.

Conclusion

The Pods, Deployments, and ReplicaSets topic of the Mastering Kubernetes One Task at a Time series covers FOUR common use cases employed in serious Kubernetes applications in real life. All three resources belong to the first of the four Kubernetes built-in Workload Resources groups. Learning them teaches the important skill of building, running, and managing Stateless Applications in a Kubernetes Cluster environment.

This post provides an end-to-end hands-on demonstration and access to codes to perform all the activities necessary to practice and master Pods, Deployments, and ReplicaSets, starting with creating a Kubernetes cluster using Terraform and including all the Kubernetes task scripts I’ve covered so fat.

Thank you for following and staying in touch. Please check out the next task in the series Know Thy Nodes!

If you benefited from reading the post, please 👏 a few times before parting, and help others by sharing it; I highly appreciate that!

Please follow to stay in touch, track, and be the first to get notified of all future writings on AWS Cloud, Containers, Kubernetes, and Machine Learning. Also, check all my stories on The AWS Way publication.