kube/ooda loop blog post
working title: ooda’s in Kubernetes
Kubernetes control plane is like the ooda (observe orient decide act), combines two main factors:
- how kubernetes controllers respond to external stimuli
- duration/frequency of external stimuli?
- intensity aka amplitude of external stimuli?
- when this stimuli comes in, how do we reconcile this with what we want?
- gasch: events, the dna of kubernetes
- bowes: level triggering and reconciliation
Draft: The fundalmental building block in the Kubernetes (k8s) lego box is the concept of a k8s controller, a program that implements a control loop that is responsible for moving k8s towards the desired state.
Now this is relatively banal, most people already take this sort of decision making process into their daily lives. However, what I want to drill down into is how this process is stateless, that is, you don’t actually need to persist any information between one iteration loop and into the next.
An example: pretend you are setting up a k8s ReplicaSet. This ReplicaSet is responsible for spinning up a certain number of Docker containers, organized into k8s pods, say 3 pods2. Now k8s handles this behavior like so on the first iteration:
- observe the number of pods already running for this replicaset (at iteration 0, this is 0 pods)
- compute the difference between the desired amount and current amount (at iteration 0, this is
current= 3-0 = 3 pods): https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/replicaset/replica%5Fset.go#L542
- decide whether pods need to be spun up or down: https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/replicaset/replica%5Fset.go#L548
- spin up pods or spin down pods accordingly
This is exactly an OODA loop3! Kubernetes observes the current state, orients itself, and then decides to act upon the given information. Now, if you pretend one of the 3 pods has failed to spin up. Iteration 1 would look like:
- observe the number of pods already running (iteration 1, this is 2 pods)
- compute the difference between the desired and current (iteration 1, this is 3-2=1 pod)
- decide/act on the information
What’s interesting here is that no state was stored between iteration 0 and iteration 1. Iteration 1 did not need any information from iteration 0 to perform its actions, rather, iteration 1 oriented itself based on the current state of the world (that two pods already existed).
Now, you might say that this system is not actually stateless, since there was state encapsulated within the number of pods already running. While this is true, it’s important to note that we never explicitly managed the state, that is, we never allocated any variables to track any information generated within the loop. Using this OODA loop, Kubernetes has managed to perform stateful actions while keeping the implementation stateless.