Guest post originally published on Fairwinds’ blog by Robert Brennan, Director of Open Source Software at Fairwinds
If you’re new to Kubernetes, one of the first concepts you’ll want to familiarize yourself with is the Controller. Most Kubernetes users do not create Pods directly; instead they create a Deployment, CronJob, StatefulSet, or other Controller which manages the Pods for them.
Controller Basics
First, here are some Controller basics. The Kubernetes documentation uses the example that a controller is like your heat thermostat. The position of the dial is its desired state, the current temperature is its actual state, and the thermostat constantly applies or removes heat in an effort to keep the two in sync. This is how a Kubernetes controller works – it is a loop that watches the state of your cluster and makes changes as needed, always working to maintain your desired state.
Controllers can track many objects including:
- What workloads are running and where
- Resources available to those workloads
- Policies around how the workloads behave (restart, upgrades, fault-tolerance)
When the controller notices a divergence between the actual state and the desired state, it will send messages to the Kubernetes API server to make any necessary changes.
Types of Controllers
In our essential Kubernetes concepts, we highlight a number of Pod Controllers including the below. We’ll then dig into the four most used controllers.
- ReplicaSet – A ReplicaSet creates a stable set of pods, all running the same workload. You will almost never create this directly.
- Deployment – A Deployment is the most common way to get your app on Kubernetes. It maintains a ReplicaSet with the desired configuration, with some additional configuration for managing updates and rollbacks.
- StatefulSet – A StatefulSet is used to manage stateful applications with persistent storage. Pod names are persistent and are retained when rescheduled (app-0, app-1). Storage stays associated with replacement pods, and volumes persist when pods are deleted.
- Job – A Job creates one or more short-lived Pods and expects them to successfully terminate.
- CronJob – A CronJob creates Jobs on a schedule.
- DaemonSet – A DaemonSet ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage collected. Common for system processes like CNI, Monitor agents, proxies, etc.
ReplicaSet
A ReplicaSet is a set of multiple, identical pods with no unique identities. ReplicaSets were designed to address two requirements:
- Containers are ephemeral. When they fail, we need their Pod to restart.
- We need to run a defined number of Pods. If one is terminated or fails, we need new Pods to be activated.
A ReplicaSet ensures that a specified number of Pod replicas are running at any given time. Even though you’ll probably never create a ReplicaSet directly, it’s an important part of keeping your Kubernetes infrastructure up and running.
Deployment
Like a ReplicaSet, a Deployment is a set of multiple, identical pods with no unique identities. However, Deployments can be upgraded and patched easier than ReplicaSets. Users can configure the strategy for rolling out new versions of a Deployment, making it possible to roll out changes with minimal downtime.
For example, we might choose a RollingUpdate strategy. Then, when we go to update our Deployment, a second ReplicaSet will be created alongside the existing one, and as more Pods become ready in the new ReplicaSet, some will be removed from the old ReplicaSet, until the old ReplicaSet is empty and can be deleted. We can even set parameters like maxUnavailable and maxSurge to control the mechanics of this switch over.
StatefulSet
While Deployments manage stateless applications, StatefulSets are valuable for applications that require one or more of the following:
- Stable, unique network identifiers
- Stable, persistent storage
- Ordered, graceful deployment and scaling
- Ordered, automated rolling updates
A StatefulSet keeps a unique identity for each Pod it manages. It uses the same identity whenever it needs to reschedule those Pods.
StatefulSets are recommended when running Cassandra, MongoDB, MySQL, PostgreSQL or any other workload utilizing persistent storage. They can help maintain state during scaling and update events, and are particularly useful for maintaining high availability.
Job
Jobs are short-lived workloads that can be used to carry out a single task. A Job will simply create one or more Pods, and wait for those Pods to finish successfully. Jobs can be helpful for doing things like:
- Running database migrations
- Performing maintenance tasks
- Rotating logs
Jobs can also run multiple Pods in parallel, giving you some extra throughput.
CronJob
CronJobs simply run Jobs on a user-defined schedule. You can provide the schedule using cron syntax, and the CronJob controller will automatically create a Job every time the schedule requires one.
The CronJob controller also allows you to specify how many Jobs can run concurrently, and how many succeeded or failed Jobs to keep around for logging and debugging.
Summary
Kubernetes Controllers allow you to run and manage your applications inside a cluster, and are one of the core concepts you’ll need to understand to be successful with Kubernetes.
Of course, there’s much more you’ll need before you have a production-ready cluster. If you are looking to create a fully operational Kubernetes cluster, you can check out our blog post on the topic. Or if you are in the process of learning about Kubernetes, check out our series on How to Kube, which showcases Kubernetes best practices around concepts, tooling, security and more.