7. Kubernetes Controllers

Overview

This chapter introduces the concept of Kubernetes controllers and explains how to use them to create replicated Deployments. We will describe the use of different types of controllers, such as ReplicaSets, Deployments, DaemonSets, StatefulSets, and Jobs. You will learn how to choose a suitable controller for specific use cases. Using hands-on exercises, we will guide you through how to use these controllers with the desired configuration to deploy several replicas of Pods for your application. You will also learn how to manage them using various commands.

Introduction

In previous chapters, we created different Pods, managed their life cycle manually, and added metadata (labels or annotations) to them to help organize and identify various Pods. In this chapter, we will take a look at a few Kubernetes objects that help you manage several replica Pods declaratively.

When deploying your application in production, there are several reasons why you would want to have more than one replica of your Pods. Having more than one replica ensures that your application continues to work in cases where one or more Pods fail. In addition to handling failures, replication also allows you to balance the load across the different replicas so that one Pod is not overloaded with a lot of requests, thereby allowing you to easily serve higher traffic than what a single Pod can serve.

Kubernetes supports different controllers that you can use for replication, such as ReplicaSets, Deployments, DaemonSets, StatefulSets, and Jobs. A controller is an object...

ReplicaSets

As discussed earlier, having multiple replicas of our application ensures that it is still available even if a few replicas fail. This also makes it easy for us to scale our application to balance the load to serve more traffic. For example, if we are building a web application that's exposed to users, we'd want to have at least two replicas of the application in case one of them fails or dies unexpectedly. We would also want the failed replica to recover on its own. In addition to that, if our traffic starts growing, we would want to increase the number of Pods (replicas) running our application. A ReplicaSet is a Kubernetes controller that keeps a certain number of Pods running at any given time.

ReplicaSet acts as a supervisor for multiple Pods across the different nodes in a Kubernetes cluster. A ReplicaSet will terminate or start new Pods to match the configuration specified in the ReplicaSet template. For this reason, it is a good idea to use them even...

Deployment

A Deployment is a Kubernetes object that acts as a wrapper around a ReplicaSet and makes it easier to use. In general, in order to manage replicated services, it's recommended that you use Deployments that, in turn, manage the ReplicaSet and the Pods created by the ReplicaSet.

The major motivation for using a Deployment is that it maintains a history of revisions. Every time a change is made to the ReplicaSet or the underlying Pods, a new revision of the ReplicaSet is recorded by the Deployment. This way, using a Deployment makes it easy to roll back to a previous state or version. Keep in mind that every rollback will also create a new revision for the Deployment. The following diagram provides an overview of the hierarchy of the different objects managing your containerized application:

Figure 7.6: Hierarchy of Deployment, ReplicaSet, Pods, and containers

Deployment Configuration

The configuration of a Deployment is actually very similar...

StatefulSets

StatefulSets are used to manage stateful replicas. Similar to a Deployment, a StatefulSet creates and manages the specified number of Pod replicas from an identical Pod template. However, where StatefulSets differ from Deployments is that they maintain a unique identity for each of their Pods. So, even if all the Pods are of identical specs, they are not interchangeable. Each of the Pods has a sticky identity that can be used by the application code to manage the state of the application on a particular Pod. For a StatefulSet with n replicas, each Pod is assigned a unique integer ordinal between 0 and n – 1. The names of the Pods reflect the integer identity assigned to them. When a StatefulSet is created, all the Pods are created in the order of their integer ordinal.

Each of the Pods managed by a StatefulSet will persist their sticky identity (integer ordinal) even if the Pod restarts. For example, if a particular Pod crashes or is deleted, a new Pod will be...

DaemonSets

DaemonSets are used to manage the creation of a particular Pod on all or a selected set of nodes in a cluster. If we configure a DaemonSet to create Pods on all nodes, then if new nodes are added to the cluster, new pods will be created to run on these new nodes. Similarly, if some nodes are removed from the cluster, the Pods running on these nodes will be destroyed.

Use Cases for DaemonSets

• Logging: One of the most common use cases for a DaemonSet is to manage running a log collection Pod on all nodes. These Pods can be used to collect logs from all the nodes and then process them in a log processing pipeline.
• Local data caching: A DaemonSet can also be used to manage caching Pods on all the nodes. These Pods can be used by other application Pods to store the cached data temporarily.
• Monitoring: Another use case for a DaemonSet is to manage running monitoring Pods on all the nodes. This can be used to collect system- or application-level metrics for Pods...

Jobs

A Job is a supervisor in Kubernetes that can be used to manage Pods that are supposed to run a determined task and then terminate gracefully. A Job creates the specified number of Pods and ensures that they successfully complete their workloads or tasks. When a Job is created, it creates and tracks the Pods that were specified in its configuration. When a specified number of Pods complete successfully, the Job is considered complete. If a Pod fails because of underlying node failures, the Job will create a new Pod to replace it. This also means that the application or code running on the Pod should be capable of gracefully handling a case where a new Pod comes up during the runtime of the process.

The Pods created by a Job aren't deleted following completion of the job. The Pods run to completion and stay in the cluster with a Completed status.

A Job can be used in several different ways:

• The simplest use case is to create a Job that runs only one Pod to completion...

Summary

Kubernetes treats Pods as ephemeral entities, and ideally you would not deploy any application or a microservice in an individual Pod. Kubernetes offers various controllers to leverage various benefits, including automatic replication, health monitoring, and automatic scaling.

In this chapter, we covered different kinds of controllers and understood when to use each of them. We created ReplicaSets and observed how they manage Pods. We learned when to use DaemonSets and StatefulSets. We also created a Deployment and learned how we can scale up and down the number of replicas and roll back to an earlier version of the Deployment. Finally, we learned how to create Jobs for one-time tasks. All of these controllers come into play when you want to deploy a production-ready application or workload, as you will see in the upcoming chapters.

In the next chapter, we will see how we can discover and access the Pods or replicas managed by a Deployment or a ReplicaSet.