Skip to main content
Components

What every Kubernetes binary does.

A field guide to the binaries that make up a Kubernetes cluster — the ones you download here, plus the runtime and add-ons that live alongside them.

Control plane

The brains of the cluster. Runs on dedicated nodes and serves the Kubernetes API, stores cluster state, and drives reconciliation.

  • kube-apiserver

    binary on this site
    API frontend of the control plane
    port 6443Docs

    The kube-apiserver exposes the Kubernetes HTTP API. Every kubectl command, every controller, and every node talks to the cluster through it. It is horizontally scalable — production clusters run multiple replicas behind a load balancer.

  • etcd

    Consistent and highly-available key-value store
    port 2379Docs

    Kubernetes stores all of its cluster state in etcd: every Pod, Secret, ConfigMap, Deployment, and event. etcd is operated independently from Kubernetes; production clusters run a 3- or 5-node etcd cluster for high availability.

  • kube-scheduler

    binary on this site
    Decides where Pods run
    Docs

    Watches for newly created Pods with no assigned node and selects a node for them to run on. It considers resource requests, hardware constraints, affinity rules, taints and tolerations, data locality, and inter-workload interference.

  • kube-controller-manager

    binary on this site
    Runs the cluster control loops
    Docs

    A single binary that runs all the Kubernetes controllers: the Node controller, ReplicaSet controller, Endpoints controller, ServiceAccount controller, and many more. Each controller watches the cluster state via the API server and drives the system toward the desired state.

  • cloud-controller-manager

    Cloud-provider-specific controllers
    Docs

    Embeds cloud-provider-specific logic so the rest of Kubernetes can stay cloud-agnostic. Runs the Node, Route, and Service controllers when the cluster is hosted on a cloud (AWS, GCP, Azure, OpenStack, etc.). Not present on bare-metal clusters.

Node components

Runs on every worker node. Manages Pods, exposes the container runtime, and implements Service networking.

  • kubelet

    binary on this site
    Agent that runs on every node
    port 10250Docs

    The kubelet receives PodSpecs from the API server and ensures the containers described are running and healthy. It interacts with the container runtime via the CRI, reports node and pod status, and runs liveness/readiness probes.

  • kube-proxy

    binary on this site
    Network rules for Services
    Docs

    Runs on every node and maintains the iptables / IPVS / nftables rules that implement Kubernetes Services. Watches Services and Endpoints, then programs the kernel to route traffic to the right Pods.

  • Container runtime

    Runs containers (containerd, CRI-O, …)
    Docs

    Kubernetes does not run containers directly — it talks to a CRI-compliant runtime such as containerd or CRI-O on every node. The runtime pulls images, creates containers, and manages their lifecycle. As of Kubernetes 1.24, dockershim has been removed.

Add-ons

Pluggable components installed alongside Kubernetes — DNS, networking, ingress, metrics. The default add-ons most clusters expect.

  • CoreDNS

    In-cluster DNS
    Docs

    Provides DNS records for Services and Pods so workloads can address each other by name. Runs as a Deployment in kube-system and is the default DNS provider since Kubernetes 1.13.

  • CNI plugin

    Cluster networking (Calico, Cilium, Flannel, …)
    Docs

    Kubernetes networking is provided by a Container Network Interface plugin chosen at cluster install time. Popular choices include Calico, Cilium, and Flannel. The CNI plugin gives every Pod its own IP and implements NetworkPolicies.