Management Plane vs Control Plane vs Data Plane

The 3 Planes in distributed systems / clouds:

Management Plane

• manage and push configs to the Control Plane and Data Plane.
• directly used by admins, either through code (e.g. check in config files to Git repo to be picked up by CI/CD) or UI (e.g. modify configs in cloud console web UI), or CLI / API.
• slow rate of change.

Control Plane

• input: configs from the Management Plane and signals from the Data Plane.
  • state transition initiated by events:
    • dataplane signals.
    • config change triggered by the user (from the Management Plane).
    • time-triggered jobs, e.g. backups.
• output: control instructions to the Data Plane.
  • determine which path the data plane will take.
  • ensures the data plane is operating with correct state as provided by the management plane (the configs) or a dynamic control algorithm (like network routing protocol).
• medium rate of change.

Data Plane

• the actual services, databases etc.
• controlled by the Control Plane.
• fast rate of change.

Availability Requirements

Data Plane > Control Plane > Management Plane.

In Kubernetes

Kubernetes only mentions control plane nodes (control plane) and worker nodes (data plane). If you must add a management plane, the you can distinguish management plane and control plane by whether admin users can directly modify.

• Management Plane: the APIs (Custom Objects) that are exposed to the admin users.
• Control Plane: read from management plane objects and trigger changes in services / deployments / storage.
• Data Plane: services consumed by external users.