The master is the host or hosts that contain the master components, including the API server, controller manager server, and etcd. The master manages nodes in its Kubernetes cluster and schedules pods to run on nodes.
| Component | Description |
|---|---|
API Server |
The Kubernetes API server validates and configures the data for pods, services, and replication controllers. It also assigns pods to nodes and synchronizes pod information with service configuration. Can be run as a standalone process. |
etcd |
etcd stores the persistent master state while other components watch etcd for changes to bring themselves into the desired state. etcd can be optionally configured for high availability, typically deployed with 2n+1 peer services. |
Controller Manager Server |
The controller manager server watches etcd for changes to replication controller objects and then uses the API to enforce the desired state. Can be run as a standalone process. Several such processes create a cluster with one active leader at a time. |
HAProxy |
Optional, used when configuring
highly-available masters with the |
While in a single master configuration, the availability of running applications remains if the master or any of its services fail. However, failure of master services reduces the ability of the system to respond to application failures or creation of new applications. You can optionally configure your masters for high availability (HA) to ensure that the cluster has no single point of failure.
To mitigate concerns about availability of the master, two activities are recommended:
-
A runbook entry should be created for reconstructing the master. A runbook entry is a necessary backstop for any highly-available service. Additional solutions merely control the frequency that the runbook must be consulted. For example, a cold standby of the master host can adequately fulfill SLAs that require no more than minutes of downtime for creation of new applications or recovery of failed application components.
-
Use a high availability solution to configure your masters and ensure that the cluster has no single point of failure. provides specific examples using the
nativeHA method and configuring HAProxy. You can also take the concepts and apply them towards your existing HA solutions using thenativemethod instead of HAProxy.
When using the native HA method with HAProxy, master components have the
following availability:
| Role | Style | Notes |
|---|---|---|
etcd |
Active-active |
Fully redundant deployment with load balancing |
API Server |
Active-active |
Managed by HAProxy |
Controller Manager Server |
Active-passive |
One instance is elected as a cluster leader at a time |
HAProxy |
Active-passive |
Balances load between API master endpoints |