Understanding Kubernetes Components: Control Plane, Nodes, and Addons

Kubernetes Components Overview

Kubernetes clusters consist of control‑plane components and a set of machines called nodes.

After the initial deployment a functional cluster contains a set of core components that cooperate to provide scheduling, state storage, networking, and runtime services.

Control Plane Components

The control plane makes global decisions (e.g., scheduling) and reacts to cluster events such as an unsatisfied replicas field in a Deployment. In many single‑node installations all control‑plane binaries run on the same host, which does not host user workloads.

kube-apiserver

The API server is the front‑end of the control plane. It validates and configures REST requests, enforces authentication and authorization, and serves the cluster’s state via the Kubernetes API. The binary kube-apiserver is stateless and can be horizontally scaled; multiple instances are typically placed behind a load balancer.

etcd

etcd is a strongly consistent, highly available key‑value store that persists all cluster configuration and state. A typical production setup runs an odd number of etcd members (3, 5, or 7) with TLS encryption. Regular snapshots are essential; for example:

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /var/backups/etcd-$(date +%Y%m%d%H%M%S).db

kube-scheduler

The scheduler watches newly created Pods that have no node assignment and selects an appropriate node based on:

CPU, memory, and extended resource requests.

Node selectors, taints & tolerations.

Affinity/anti‑affinity rules.

Data locality (e.g., PersistentVolume topology).

Inter‑workload interference and QoS classes.

Pod deadlines (activeDeadlineSeconds).

kube-controller-manager

This binary runs a collection of controllers, each responsible for a specific control loop:

Node controller – monitors node health.

Replication controller – ensures the desired number of pod replicas.

Deployment controller – manages rollout strategies.

Service account & token controllers – handle credential issuance.

Endpoint controller – populates Service endpoints.

Although each controller could be a separate process, they are compiled into a single binary for simplicity.

Node‑Level Components

kubelet

The kubelet runs on every node as an agent that:

Registers the node with the API server.

Watches the API for PodSpecs assigned to the node.

Creates, starts, and monitors containers via the configured container runtime.

Performs liveness and readiness probes, reporting status back to the control plane.

Executes the pod lifecycle (pre‑stop hooks, graceful termination).

kube-proxy

kube-proxy implements the Service abstraction by programming network rules on each node. It supports two primary modes:

iptables – creates NAT and filter rules directly in the Linux kernel.

IPVS – uses the Linux IP Virtual Server for higher‑performance load balancing.

If the operating system provides a packet‑filtering layer (e.g., eBPF), kube-proxy can leverage it; otherwise it falls back to simple traffic forwarding.

Container Runtime

Kubernetes interacts with container runtimes through the Container Runtime Interface (CRI). Supported runtimes include:

Docker (legacy, deprecated in newer releases).

containerd – a lightweight daemon that directly implements CRI.

CRI‑O – a minimal runtime focused on OCI‑compatible containers.

Any third‑party implementation that conforms to the CRI specification.

Addons (Cluster‑Level Extensions)

Addons are deployed as regular Kubernetes resources in the kube-system namespace and extend cluster functionality.

Cluster DNS

Most clusters run a DNS service (commonly CoreDNS) that provides DNS records for Services and creates .svc.cluster.local entries. Pods automatically include the cluster DNS server in their /etc/resolv.conf search list, enabling service discovery via name.

Dashboard (Web UI)

The Kubernetes Dashboard is a general‑purpose, web‑based UI that allows users to inspect resources, view logs, and perform basic CRUD operations. It runs as a Deployment in kube-system and is typically exposed through a secure kubectl proxy or an Ingress.

Metrics Server / Container Resource Monitoring

Metrics Server aggregates resource usage (CPU, memory) from the kubelet’s /stats/summary endpoint and stores the data in the metrics.k8s.io API. This data powers the kubectl top command and Horizontal Pod Autoscaler (HPA) decisions.

Cluster‑Level Logging

Logging addons collect container stdout/stderr streams and forward them to a centralized store (e.g., Elasticsearch, Loki). A typical stack includes a Fluentd/Fluent Bit DaemonSet, a log aggregation backend, and a UI such as Kibana or Grafana for search and visualization.