Here, schedule this...

At its heart, Kubernetes is a system for scheduling work to a cluster of computers—a scheduler. But why would you want a scheduler?

If you think about your own systems, then you'll realize that you probably already have a scheduler, but unless you are already using something like Kubernetes, it might look very different.

Perhaps your scheduler is a team of people, with spreadsheets and documentation about which services run on each server in your data center. Perhaps that team of people looks at past traffic statistics to try and guess when there will be a heavy load in the future. Perhaps your scheduler relies on your users alerting members of your team at any time of the night if your applications stop functioning.

This book is about these problems, about how we can move on from a world of manual processes and making guesses about the future usage of our systems. It is about harnessing the skill and experience of the humans that administer the systems to encode our operational knowledge into systems that can make decisions about your running system second by second, seamlessly responding to crashed processes, failed machines, and increased load without any human intervention.

Kubernetes chooses to model its scheduler as a control loop so that the system is constantly discovering the current state of the cluster, comparing it to a desired state, and then taking actions to reduce the difference between the desired and the actual state. This is summarized in the following diagram:

Being able to declare the state that we want the system to be in, and then have the system itself take the actions needed to manifest that desired state, is very powerful.

You may previously have used an imperative tool or a script to manage a system, or you may even have used a written playbook of the manual steps to take. This sort of approach is very much like a recipe: you take a set of actions one after another and hopefully end up in the state that you desire.

This works well when describing how to install and bootstrap a system for the first time, but when you need to run your script against a system that is already running, your logic needs to become more complicated as, for each stage in your recipe, you have to stop and check what needs to be done before you do it.

When using a declarative tool such as Kubernetes to manage your system, your configuration is simplified and becomes much easier to reason about. One important side effect of this approach is that Kubernetes will repair your configuration if an underlying failure causes it to drift away from your desired state.

By combining control loops and declarative configuration, Kubernetes allows you to tell it what to do for you, not how to do it. Kubernetes gives you, the operator, the role of the architect and Kubernetes takes the role of the builder. An architect provides a builder with detailed plans for a building, but doesn't need to explain how to build the walls with bricks and mortar. Your responsibility is to provide Kubernetes with a specification of your application and the resources it needs, but you don't need to worry about the details of exactly how and where it will run.