Master Components

Master components comprise the cluster control plane. They are responsible for making global decisions about the cluster such as scheduling and event response. 

Master components can run on any machine in the cluster; however, for simplicity, many setup scripts start all master components on the same machine, and do not run user containers on the same server.


This component exposes the Kubernetes API and can be thought of as the front-end for the Kubernetes control plane. It is designed to scale horizontally (more instances can be deployed).


A consistent and highly-available key-value store which functions as Kubernetes' backing data store. Users are expected to have a backup plan for etcd's data in the case of failure.


This component watches for newly created pods without an assigned node, and is responsible for selecting a node that the pod will run on. Resource requirements, hardware and policy constraints, affinity and anti-affinity, data locality, inter-workload interference and deadlines all factor into scheduling decisions.


The component that is responsible for managing controllers. Each controller is a separate process, but to reduce complexity, are compiled into a single binary which run in a single process.

Controlllers include:

  • Node Controller - responsible for identifying "down" nodes, and responding accordingly
  • Replication Controller -  maintains the correct number of pods for each replication controller object in the system
  • Endpoints Controller - responsible for populating the Endpoints object (joins Services & Pods)
  • Service Account and Token Controllers - creates default accounts and API access tokens for new system namespaces


This component runs controllers that interact with the underlying cloud provider. The binary was released as an alpha feature in Kubernetes 1.6, and will only operate on cloud provider specific controller loops. These loops must be disabled in the kube-controller-manager by setting the --cloud-provider  flag to external at start-time.

This controller allows the Kubernetes core code to evolve independently from that of the cloud vendor. 

The following controllers depend on cloud providers:

  • Node Controller - Checks the cloud provider API to determine if a node has been terminated if it stops responding
  • Route Controller - sets up routes in the underlying cloud infrastructure
  • Service Controller - creates, updates, and deletes cloud provider load balancers
  • Volume Controller - creates, attaches, and mounts volumes

Node Components

Node components run on every node, providing the Kubernetes runtime environment and maintain running pods.


The kubelet is an agent that runs on each node in the cluster. It takes a set of PodSpecs which are provided through various mechanisms and ensures the containers described therein are both running and healthy. The kubelet is not responsible for running or managing containers which were not created by Kubernetes.


This component enables the Kubernetes service abstraction by maintaining network rules on the host, as well as performing connection forwarding.

container runtime

The container runtime is software responsible for running containers. Supported runtimes include docker and rkt.


Cluster add ons are pods and services that implement additional cluster features. Addon pods may be managed by native Kubernetes controllers such as Deployments, ReplicationControllers, etc. Namesapced addon objects are created in the kube-system  namespace. 

Did this answer your question?