Image for post
Image for post

Imperative vs Declarative

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.

Kubernetes is often described as a declarative system and compared with imperative systems. However, the meaning of the terms “declarative” and “imperative” are not readily obvious. This blog post provides a concise model to illustrate the similarities and difference between the two.

Model of Computation

The remainder of this post will adopt a simple state machine model of computation. In the state machine model, a computation is defined as applying a command which transitions the system from one state to another. A running system is therefore a series of commands that transitions the system through various states.

Image for post
Image for post
Figure 1. State Machine Model of Computation

The system is considered to be in a state match if the current state is equal to the desired state. In contrast, the system is considered to be in a state drift if the current state is not equal to the desired state. The set of commands that transitions the system from its current state to a given desired state is called the set of mitigating actions.

For example, given the initial state S, the command c transitions the system to the state S’. Similarly, c’ transitions the system to S’’ and so forth. With S being the current state and S’’’ being the desired state, the set of mitigating actions is equal to {c, c’, c’’}.

Image for post
Image for post
Figure 2. Structural Diagram highlighting the actors involved in the State Machine Model of Computation

Figure 2. highlights the actors involved in the state machine model of computation. The automaton is responsible for applying a given command to the current state which transitions the system to the next state. However, the environment in which the system exists can also affect the state.

Here, an intended state change is any state change that is a result of an explicitly supplied command. In contrast, an unintended state change is any change in state that is a result of an interaction with the environment.

In the context of Kubernetes, an intended state change might be the deployment of a Pod or a ReplicaSet, whereas an unintended state change might be a single container or an entire node going down.

Imperative Systems

In an imperative system, the user knows the desired state, determines the sequence of commands to transition the system to the desired state, and supplies a representation of the commands to the system. The component of the system that applies the command to transition the state is called a processor.

Image for post
Image for post
Figure 3. Imperative Systems

Declarative Systems

By contrast, in a declarative system, the user knows the desired state, supplies a representation of the desired state to the system, then the system reads the current state and determines the sequence of commands to transition the system to the desired state. The component that determines the necessary sequence of commands is called a controller.

Image for post
Image for post
Figure 4. Declarative Systems

Declarative systems have the distinct advantage of being able to react to unintended state changes without further supervision: In the event of an unintended state change leading to a state drift, the system may autonomously determine and apply the set of mitigating actions leading to a state match. This process is called a control loop, a popular choice for the implementation of controllers.

Kubernetes

Kubernetes is a declarative system. Instead of a single controller, however, it has several controllers that are each responsible for a different Kubernetes object type, such as ReplicaSet or Deployment, for example. The API Server acts as the processor, applying the commands given by the controllers to the system state, which is stored in the Kubernetes Object Store.

Image for post
Image for post
Figure 5. Kubernetes as a Declarative System

In summary

The defining aspect of imperative and declarative systems is the answer to the question of who is in the driver’s seat. Is the user or the system responsible for orchestrating the transition to the desired state?

In an imperative system, the user is responsible for knowing how to drive the system to the desired state, whereas in a declarative system, the system is responsible for knowing how to drive itself to the desired 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.

Principal Engineer at Cisco, Office of the CTO

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store