Kubernetes Control Plane and Data Plane Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 35: Line 35:
===Controller Manager===
===Controller Manager===


The controller manager implements multiple independent control loops (it is a controller of controllers) that monitor the state of the cluster and respond to events. The controller manager is shipped as a monolithic binary.
The controller manager implements multiple independent control loops (it is a controller of controllers, and includes a [[#Node_Controller|node controller]]) that monitor the state of the cluster and respond to events. The controller manager is shipped as a monolithic binary.


===Scheduler===
===Scheduler===

Revision as of 20:40, 21 August 2019

Internal

Cluster

A Kubernetes cluster consists of a set of nodes. Of those, a small number are master nodes, which are collectively known as the control plane, and a potentially relatively larger number of worker nodes, which run the cluster's workload.

Node

A node is a Linux host that can run as a VM, a bare-metal device or an instance in a private or public cloud. A node can be a master or worker. The controller manager includes a node controller.

Control Plane

The control plane is the cluster's set of master nodes. The control plane exposes the API via the API Server and contains the cluster store, controller manager, scheduler and other management components. The control plane makes workload scheduling decisions, performs monitoring and responds to external and internal events.

Master Node

A master node is a collection of system services that manage the Kubernetes cluster. The master nodes are sometimes called heads or head nodes, and most often simply masters. Collectively, they represent the control plane. While it is possible to execute user workloads on the master node, this is generally not recommended. This approach frees up the master nodes' resources to be exclusively used for cluster management activities.

HA Master Nodes

The recommended configuration includes 3 or 5 replicated masters.

Control Plane System Services

API Server

All components (internal system components and external user components) communicate exclusively via the API Server and use the same API. The most common operation is to POST a manifest as part of a REST API invocation - once the invocation is authenticated and authorized, the manifest content is validated, then persisted into the cluster store and various controllers kick in to insure that the cluster state matches the desired state expressed in the manifest.

Cluster Store

The cluster store is the service that persistently stores the entire configuration and state of the cluster. The cluster store is the only stateful part of the control plane, and the single source of truth for the cluster. The current implementation is based on etcd. Productions deployments run in a HA configuration, with 3 - 5 replicas. etcd prefers consistence over availability, and it will halt updates to the cluster in split brain situations to maintain consistency. However, if etcd becomes unavailable, the applications running on the cluster will continue to work.

Controller Manager

The controller manager implements multiple independent control loops (it is a controller of controllers, and includes a node controller) that monitor the state of the cluster and respond to events. The controller manager is shipped as a monolithic binary.

Scheduler

Cloud Controller Manager

Data Plane

The data plane is the cluster's set of worker nodes.

Worker Node

A worker node, most often referred simply as "node" (as opposite to master), is where the application services run. Collectively, the worker nodes make up the data plane. A worker node constantly watches for new work assignments.