<p>I see this in Kubernetes doc,</p>
<blockquote>
<p>In Kubernetes, controllers are control loops that watch the state of
your cluster, then make or request changes where needed. Each
controller tries to move the current cluster state closer to the
desired state.</p>
</blockquote>
<p>Also this,</p>
<blockquote>
<p>The Deployment controller and Job controller are examples of
controllers that come as part of Kubernetes itself (&quot;built-in&quot;
controllers).</p>
</blockquote>
<p>But, I couldn't find how does the control loop work. Does it check the current state of the cluster every few seconds? If yes, what is the default value?</p>
<p>I also found something interesting here,</p>
<p><a href="https://stackoverflow.com/questions/55453072/what-is-the-deployment-controller-sync-period-for-kube-controller-manager">What is the deployment controller sync period for kube-controller-manager?</a></p>

karthikeayan
<p>I would like to start explaining that the <a href="https://kubernetes.io/docs/concepts/overview/components/#kube-controller-manager" rel="nofollow noreferrer">kube-controller-manager</a> is a collection of individual control processes tied together to reduce complexity.</p>
<p>Being said that, the control process responsible for monitoring the node's health and a few other parameters is the <a href="https://kubernetes.io/docs/concepts/architecture/nodes/#node-controller" rel="nofollow noreferrer">Node Controller</a>, and it does that by reading the <a href="https://kubernetes.io/docs/concepts/architecture/nodes/#heartbeats" rel="nofollow noreferrer">Heartbeats</a> sent by the <a href="https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/" rel="nofollow noreferrer">Kubelet</a> agent in the nodes.</p>
<p>According to the Kubernete's documentation:</p>
<blockquote>
<p>For nodes there are two forms of heartbeats:</p>
<ul>
<li>updates to the <code>.status</code> of a Node</li>
<li><a href="https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/lease-v1/" rel="nofollow noreferrer">Lease</a> objects within the <code>kube-node-lease</code> namespace. Each Node has an    associated Lease object.</li>
</ul>
<p>Compared to updates to <code>.status</code> of a Node, a Lease is a lightweight
resource. Using Leases for heartbeats reduces the performance impact
of these updates for large clusters.</p>
<p>The kubelet is responsible for creating and updating the <code>.status</code> of
Nodes, and for updating their related Leases.</p>
<ul>
<li>The kubelet updates the node's <code>.status</code> either when there is change in    status or if there has been no update for a configured interval.
The    default interval for <code>.status</code> updates to Nodes is 5 minutes,
which is    much longer than the 40 second default timeout for
unreachable nodes.</li>
<li>The kubelet creates and then updates its Lease object every 10    seconds (the default update interval). Lease updates occur independently from updates to the Node's <code>.status</code>. If the Lease update
fails, the kubelet retries, using exponential backoff that starts at 200 milliseconds and capped at 7 seconds.</li>
</ul>
</blockquote>
<p>As for the <a href="https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/" rel="nofollow noreferrer">Kubernetes Objects</a> running in the nodes:</p>
<blockquote>
<p>Kubernetes objects are persistent entities in the Kubernetes system.
Kubernetes uses these entities to represent the state of your cluster.
Specifically, they can describe:</p>
<ul>
<li>What containerized applications are running (and on which nodes)</li>
<li>The resources available to those applications</li>
<li>The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance</li>
</ul>
<p>A Kubernetes object is a &quot;record of intent&quot;--once you create the
object, the Kubernetes system will constantly work to ensure that
object exists. By creating an object, you're effectively telling the
Kubernetes system what you want your cluster's workload to look like;
this is your cluster's desired state.</p>
</blockquote>
<p>Depending on the Kubernetes Object, the controller mechanism is responsible for maintaining its desired state. The <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/" rel="nofollow noreferrer">Deployment Object</a> for example, uses the <a href="https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/" rel="nofollow noreferrer">Replica Set</a> underneath to maintain the desired described state of the Pods; while the <a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/" rel="nofollow noreferrer">Statefulset Object</a> uses its own Controller for the same purpose.</p>
<p>To see a complete list of Kubernetes Objects managed by your cluster, you can run the command: <code>kubectl api-resources</code></p>
