Where do I begin?

Ok so before we start to jump into examples, there are some simple “fundamentals” we need to cover here.

At its heart Kubernetes is nothing more than a monitoring system; essentially an infinite loop, constantly monitoring everything it knows about.

The things that Kubernetes monitors can be referred to as Perceived State, and comparing this against reality, referred to as Actual State.

When Kubernetes detects a discrepancy between perceived and actual states it then calculates which action to take to make these two states match.

Examples of actions Kubernetes could take during Reconciliation include:

A new version of an application is deployed; meaning new instances need creating and old ones removing once the new pods are stable.

Creating a new pod/instance of a service due to a running pod becoming unhealthy.

Removing pods because a user has issued a request to scale down or delete a service.

This list is not exhaustive, but just a few examples to get us started.

It’s time to Reconcile our Differences

So now we are thinking in terms of State; what happens when Kubernetes decides something is out of sync?

Well when state discrepancies are detected, K8s starts something we call “Reconciliation”. When this happens, K8s is trying to essentially make reality match what it’s been told reality should look like. Remember when we deploy services, our YAML files are essentially telling Kubernetes “I want the world to look like this”, and once it has achieved this, and the states are in sync, it will go back to monitoring this waiting for state discrepancies to appear.

For the most part Reconciliation is very simple; spinning something new up or tearing something unwanted down. But K8s can do so much more than just start and stop things. So let’s look a bit deeper shall we?

A Real World Example

Okay, so let’s take an example of an advanced scenario; let’s imagine we want to have kubernetes deploy and monitor instances of AWS SQS. This would allow us to deploy new SQS instances as part of our service deployment YAML and then have kubernetes do all the configuration, maintenance and heavy lifting for us.

Now I hate to state the obvious, but SQS does not run in a container; it runs in the AWS cloud platform, so how on earth can Kubernetes (a container orchestration platform) help us?

Well this is the part where I’m here to tell you:

Not everything we need to manage via Kubernetes needs to run in a container. Sometimes we need to think outside the proverbial box

i know right… mind blown!

Instead what we need to have is have something running in a container, that will allow us to interact with SQS.

Operator Framework to the Rescue!

Right, so we need K8s to be able to handle something stateful, but whatever that “something stateful” is, may or may not be running inside the Kubernetes eco-system. Great!

But how do we do this??? Well luckily there is something called the Kubernetes Operator Framework that can help us. Initially developer by CoreOS the framework was announced back in 2018 to much fanfare. The framework gives us all the tools and guidance we need to try and build extensions into Kubernetes called Operators. But what exactly are they?

My TL;DR; definition of Operators:

An Operator can be thought of simply as a RESTful API which runs in a container on K8s. They have Controllers and Actions (same as all RESTful services), that will get called by K8s whenever Reconciliation needs to happen.

But, how does Kubernetes know which controller to call?

When we write our operators we will be creating custom Controllers, we will then install or register our controllers with the K8s control plane. We do this by hooking our controller into something called the Controller Manager.

But even with our controller registered, how can Kubernetes know which controller does what? So there is one last piece of the puzzle that we haven’t looked at yet, one key concept/term of the Kubernetes that lets the Operator Framework do its thing; and that is CRD’s or Custom Resource Definitions.