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.
First, here are some fundamentals of Controllers. 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:
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.
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.
A ReplicaSet is a set of multiple, identical pods with no unique identities. ReplicaSets were designed to address two requirements:
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.
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.
While Deployments manage stateless applications, StatefulSets are valuable for applications that require one or more of the following:
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.
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:
Jobs can also run multiple Pods in parallel, giving you some extra throughput.
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.
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.