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