The Mechanics of Kubernetes
By Andrew Chen and Dominik Tornow
Kubernetes is a Container Orchestration Engine designed to host containerized applications on a set of nodes, commonly referred to as a cluster. Using a systems modeling approach this series aims to advance the understanding of Kubernetes and its underlying concepts.
For this blog post, an advanced understanding of Kubernetes, Kubernetes Objects, and Kubernetes Controllers is recommended.
Kubernetes is characterized as a declarative Container Orchestration Engine: In a declarative system, the user supplies a representation of the desired state of the system to the system. Then, the system considers the current state and the desired state to determine the sequence of commands to transition from current state to desired state.
Therefore, the term “declarative system” sparks the notion of a calculated, coordinated effort with the explicit purpose to transition from the current state to the desired state.
However, this is not how Kubernetes actually works!
Kubernetes does not determine a calculated, coordinated sequence of commands to execute based on the current state and the desired state.
Instead, Kubernetes iteratively determines the next command to execute based on the current state only. If and when no next command can be determined, Kubernetes reached a steady state.
State Transition Mechanics
This paragraph outlines an abstract model of Kubernetes’ state transition semantics. The next paragraphs outline a concrete example based on Deployment Objects and the Deployment Controller.
Listing 1. specifies the state transition semantics of Kubernetes: Given a Next Command Function, the system will determine the next command based on the current state, k8s, that transitions the system from its current state, k8s, to its next state, k8s’.
Conceptually, the Next Command Function is the composition of the Next Command Functions of every Kubernetes Controller.
The sequence of states is terminated by a state k8s.last for which the Next Command function does not yield a next command, a state commonly referred to as Steady State.
Enter Kubernetes Objects
The Kubernetes Object Store is a set of Kubernetes Objects. Kubernetes Objects are data records that come in different flavors, called kinds.
Listing 4. illustrates a Deployment Object: The Listing states the fact that there exists a Kubernetes Object, so that the object’s
.kindequalsDeployment.spec.replicasequals3.spec.template.spec.containers[0].imageequalsBusyBox
Enter Kubernetes Controllers
Every Kubernetes Controller contributes to the Next Command function: A Controller is implemented as a continuous process that yields commands based on Kubernetes’ current state.
Listing 5. illustrates the the Deployment Controller: The Controller monitors Deployment Objects and for each Object performs a set of conditional statements:
- Condition
If there is less than 1 matching ReplicaSet Object
Command
then the Deployment Controller will yield a Create ReplicaSet Command - Condition
If there is more than 1 matching ReplicaSet Object
Command
then the Deployment Controller will issue a Delete ReplicaSet Command
From the point of view of a Controller, Kubernetes is in steady state if none of the Controller’s conditions are enabled, that is, the Controller will not yield any command.
Cascading Commands
Controllers (may) cascadingly enable each other:
- Given the state k8s, if a Kubernetes Controller C is enabled, C will perform a command that transitions to k8s’.
- Given the state k8s’, if Kubernetes Controller C’ is enabled, C’ will perform a command that transitions to k8s’’
Figure 2. illustrates the resulting Command cascade after a Deployment Object has been submitted to the API Server by the user.
Is Kubernetes a declarative system?
Listing 6. specifies the state transition mechanics of a declarative system. Given a Desired State Predicate, the system will determine a sequence of commands that transitions the system from its current state k8s.first to its desired state k8s.last.
We may subscribe to the notion that Kubernetes is a declarative system, if we interpret a Kubernetes Object not as a record of fact but as a record of intent:
For example we may interpret the Deployment Object from Listing 4. as the intent that there shall exist a set of 3 Pod Objects, so that the objects’
.spec.containers[0].imageequalsBusyBox
However, this notion is not without subtleties: if you interpret an Object as a record-of-intent, you are presented with multiple options. For example, a Deployment Object may be interpreted as:
- there shall be a ReplicaSet or
- there shall be a set of Pods
Depending on the interpretation, the current state may or may not match the desired state
- if there is a ReplicaSet and optionally a set of Pods or
- if there is a ReplicaSet and mandatorily a set of Pods
Independent of our interpretation
- K8s is in steady state in relation to the Deployment Object if there is a ReplicaSet Object (the Deployment Controller will not yield Commands)
- K8s is in steady state in relation to the ReplicaSet Object if there is a
set of Pod Objects (the ReplicaSet Controller will not yield Commands)
Conclusion
In casual conversations, Kubernetes may be described as a declarative system and Kubernetes Objects may be described as records-of-intent.
However, when you reason about Kubernetes and Kubernetes’ behavior, you should keep in mind that Kubernetes does not make a coordinated effort to transition to a desired state. Instead, Kubernetes makes continuous, uncoordinated efforts to transition to a steady state.
About this post
This blog post is part of a collaborative effort between the CNCF, Google, and SAP to advance the understanding of Kubernetes and its underlying concepts.
