Declarative Manifesto

K8s operates on the Declarative Model

Basically, it means that we give the API server(present inside our Master Node) a manifest file(Containing some intructions) that describes the end state(Desired State). In simple terms what we want Kubernetes to do.

Note - The state in which we want our cluster or apps to look like is called the end state of the desired state

Let's say that we want three instances of web front end Pod running. Hence we will have 3 nodes and each pod has 1 container. This is what we needed and it is our desired state.

Our folks working inside master node get into action and scheduler see work being assigned to API Server, scheduler immediately picks up the work and spins up 3 nodes based on the manifest instructions. We asked for 3 replicas. Our controllers folks set a watch loop and check if the Desired state(3) are = Observer State

Now the desired State and Observed State will be

But what if one of the Node goes down

Then the desired state still says that 3 Pods but the Observed state will now have only 2 Pods.

Now by design, K8s is obsessed with observed state matching desired state. And our controller folks are working really hard to ensure that the same is achieved but because the node is down. Controller flags the same and our scheduler spins another pod or maybe a node to balance the desired and observed state.

Hence now Observed State = Desired State

Well, thats all fine but I still didn't understand the actual flow.

To understand that check what's next

Step 1 -  Manifest is passed to API Server via REST API or something, just imagine it

Step 2 - The Declarative manifest is then stored inside the Cluster Store

Step 3 - The Desired state of the cluster has been defined now

Step 4 -  Scheduler spins up Nodes containing pods as per the desired state

Step 5 - Controllers keep watch on the nodes and ensure that desired state is = Observed state