Skip to main content
In this lesson we cover the kube-controller-manager: the process that runs the controllers implementing Kubernetes’ control loops. Each controller watches the cluster state and takes corrective actions via the API server to drive the system toward the declared (desired) state. Think of a controller as a department on the control plane with a focused responsibility—node health, ReplicaSets, PersistentVolumes binding, and so on. How controllers work
  • A controller is a loop: it monitors one or more resource types, evaluates the current state against the desired state, then issues API calls to reconcile differences.
  • Controllers continuously run inside the kube-controller-manager process (or can be managed separately in very custom setups).
  • Examples include: NodeController, ReplicaSet (and ReplicationController), Deployment controller, PV binder, Job controller, Namespace controller, and many others.
A stylized diagram titled "Controller" showing multiple Kubernetes controller components (Deployment‑Controller, Namespace‑Controller, Job‑Controller, ReplicaSet, Node‑Controller, PV‑Binder‑Controller, etc.) arranged inside a framed area. To the right are control buttons and settings like "Watch Status", "Remediate Situation", "Node Monitor Period = 5s", "Node Monitor Grace Period = 40s", and "POD Eviction Timeout = 5m".
Key controller examples Node controller
  • The node controller monitors node health and takes action so workloads keep running.
  • Default timing behavior:
    • It checks node status periodically (node-monitor-period).
    • If heartbeats/conditions stop, the node is marked unreachable after the grace period (node-monitor-grace-period).
    • After a node is marked unreachable, pods on that node get a pod eviction timeout (pod-eviction-timeout) before they are evicted and, if managed by a controller (ReplicaSet/Deployment), recreated elsewhere.
Defaults and common timing flags: Healthy nodes example:
If a node stops responding it may appear as:
Replication Controller / ReplicaSet
  • The ReplicationController (and its successor ReplicaSet) ensures a specified number of pod replicas run.
  • If a pod fails or is deleted, the controller creates a replacement to maintain the declared replica count.
These are representative examples—many Kubernetes features (Deployments, Services, Namespaces, PersistentVolumes, Jobs, StatefulSets, etc.) rely on controllers to implement their behavior. Where are these controllers located?
  • Controllers are packaged together into a single binary/process: kube-controller-manager.
  • When kube-controller-manager starts, it runs multiple controller loops inside the same process.
  • The binary can be downloaded from the Kubernetes release page and run as a service or as a static pod depending on how your cluster is installed.
Example: running kube-controller-manager (download + systemd ExecStart snippet)
Controlling which controllers run
  • One important flag is --controllers. It controls which controllers are enabled or disabled.
  • The default enables all on-by-default controllers ([*]). You can enable a specific controller by its name or disable one by prefixing with -.
You can restrict which controllers run by using --controllers. The default is [*] (all on-by-default controllers). Enable a controller with its name (e.g., replicaset) or disable it by prefixing with - (e.g., -replicaset).
Illustrative description for --controllers:
How to view kube-controller-manager options in a running cluster With kubeadm
  • kubeadm deploys kube-controller-manager as a static pod in the kube-system namespace on the control plane node. You can list pods and inspect the static pod manifest to view flags.
Example pod listing:
Static pod manifest location (on control plane host):
Non-kubeadm / systemd-run clusters
  • Some installations run kube-controller-manager as a systemd service. Inspect the systemd unit file (commonly under /etc/systemd/system/) to review ExecStart and flags.
Example systemd unit snippet:
Inspecting the running process
  • You can also run ps aux | grep kube-controller-manager on the control plane host to see the runtime arguments actually in use.
Summary
  • The kube-controller-manager runs controllers that implement Kubernetes control loops.
  • Controllers monitor resources and reconcile state via the API server.
  • You can configure which controllers run with --controllers and tune controller behavior with flags like --node-monitor-period, --node-monitor-grace-period, and --pod-eviction-timeout.
  • Inspect manifests (static pods) or systemd units to verify the flags active in your environment.
Links and references

Watch Video