Kubernetes - Components

Last Updated: 2023-02-16

Kubernetes out-of-box components.

Control Plane Components

("master" components)

  • kube-apiserver: API Server
  • controllers:
    • kube-controller-manager: Controller Manager of the built-in controllers.
    • cloud-controller-manager: embeds cloud-specific control logic.
  • kube-scheduler: Scheduler
  • etcd: Most of the kubernetes components are stateless and state of each component comes from the etcd db files.
  • add-ons:
    • kube-dns, dashboard, monitoring, cluster-level logging
    • keepalived & haproxy: The battle tested duo will provide the control plane discovery and load balancing out of the box.

Worker Node Components

(virtual or physical machines, managed by the control plane and contains the services necessary to run Pods.)

  • kubelet: Talks to API Server.
  • kube-proxy
  • Container Runtime: e.g. containerd, a daemon on worker nodes. Manages the container lifecycle.
  • monitoring / logging: supervisord, fluentd

The Pod Lifecycle Event Generator or PLEG is a daemon on each node that ensures the cluster's current state matches the desired state of the cluster. This might mean restarting containers or scaling the number of replicas but its possible for it to encounter issues.

The kubelet monitors resources like memory, disk space, and filesystem inodes on your cluster's nodes.


Clients use kubectl cli to interact with the cluster.

Containerized or not

  • Containerized (can be found in kubectl get service -A): kube-apiserver, kube-scheduler, kube-proxy, etcd, etc.
  • Not containerized (run as systemd services): kubelet, containerd, docker.

API Server

API Server clients: CLI (kubectl), CI/CD (Jenkins), Dashboard / UI, kubelet, control plane components (controller-manager, scheduler, etc)

  • clients wihin Control Plane: controllers, scheduler, etcd.
  • between API Server and developers: kubectl, kubeadm, REST API, client libraries (https://github.com/kubernetes-client)
  • between API Server and Nodes: kubelet

Access management:

authentication -> authorization -> admission control ("mutating" / "validating" admission controllerss)

the API server implements a push-based notification stream of state changes (events), also known as Watch

One of the reasons why watches are so efficient is because they’re implemented via the gRPC streaming APIs.


The scheduler is a kind of controller. why separate from controler manager? big enough; easy to use an alternative scheduler.

Life of a deployment (Put everything together)

  • user submit a deployment.yaml to API Server.
  • deployment.yaml is stored in etcd; only API Server can access etcd.
  • controller-manager sees the deloyment.yaml from the API Server and create corresponding pods.
  • scheduler: assigns a pod to a node.
  • kubelet talks to the API Server and read the schedule, runs the pods.
  • end-users calls the running pods through kube-proxy (kube-proxy calls API Server to get services).