Cloud Parts

kubeadm

The official tool for turning Linux machines you already have into a Kubernetes cluster: kubeadm init, then kubeadm join.

What it is
Container orchestration
Part of
Tool for Kubernetes
Type
Open source
Made by
Cloud Native Computing Foundation
License
Apache 2.0
Facts checked
6 October 2026
Website Source code

What it is

kubeadm is the Kubernetes project’s own cluster bootstrapper, maintained by SIG Cluster Lifecycle. On the first machine, kubeadm init runs preflight checks, creates a certificate authority and the certificates and kubeconfig files each component needs, and writes static Pod manifests for the API server, controller manager, scheduler and a local etcd. The kubelet, which you install yourself, starts those Pods. kubeadm then prints a kubeadm join command with a bootstrap token (valid for 24 hours by default) and a hash of the CA’s public key, so a new node can check it is joining the right cluster.

Its scope is deliberately narrow. kubeadm doesn’t create machines, install the kubelet or a container runtime, or pick a Pod network: until you apply a CNI network plugin of your choice, CoreDNS won’t start. Monitoring, dashboards and cloud integrations are out of scope too. What it does cover is the cluster’s lifecycle after creation: kubeadm upgrade moves the control plane one minor version at a time, renewing certificates as it goes, and kubeadm join --control-plane adds control plane nodes behind a load balancer for high availability. That narrowness is why other tools build on it: when kubeadm went GA in 2018, minikube already ran it inside its VM, and SIG Cluster Lifecycle’s Cluster API covers the machine provisioning that kubeadm leaves out.

Why teams pick it

  • Produces a plain upstream cluster that follows Certified Kubernetes guidelines, with secure defaults such as TLS for all etcd traffic and token-based node joining
  • Works on any Linux machines: bare metal, VMs on any cloud, or a Raspberry Pi
  • A composable building block: phases (kubeadm init phase ...) and a config file API let higher-level tools reuse its steps
  • Handles in-place control plane upgrades, including etcd, and renews certificates during them

Watch out for

  • Only the bootstrap: you still provision machines, install the runtime and kubelet, choose a CNI and add a load balancer for HA
  • A default cluster has one control plane node and one etcd; if it fails you can lose the cluster, so HA needs at least three control plane nodes
  • Client certificates expire after one year; a cluster that isn’t upgraded at least yearly needs a manual kubeadm certs renew
  • Upgrades can’t skip minor versions, and each node’s kubelet has to be drained and upgraded separately

More of the Kubernetes family

What all container orchestration have in common →
RancherOpen sourceToolsSUSE’s open-source control plane for fleets of Kubernetes clusters: one place to create, import, secure and upgrade them.Amazon EKSAWSManaged servicesAWS runs the Kubernetes control plane for you; you choose how much of the worker side to hand over too.Azure Kubernetes ServiceAzureManaged servicesMicrosoft’s managed Kubernetes: a control plane that can be free, node pools of Azure VMs, and an Automatic mode that runs the nodes too.Google Kubernetes EngineGoogle CloudManaged servicesGoogle’s managed Kubernetes, the oldest one: Google runs the control plane, and in Autopilot mode the nodes too.K3sOpen sourceDistributionsA certified Kubernetes distribution in one small binary, built for edge, IoT and other places where a full cluster is too heavy, with SQLite or embedded etcd for state.MicroK8sOpen sourceDistributionsCanonical’s Kubernetes in one snap package: installs with one command on Linux, forms a highly available cluster by itself at three nodes, and adds features as addons.Red Hat OpenShiftCommercialDistributionsRed Hat’s Kubernetes platform: Kubernetes plus its own OS, operators that install and upgrade everything, and stricter security defaults, sold by subscription.RKE2Open sourceDistributionsSUSE’s security-focused Kubernetes distribution: one binary per node, hardened defaults, FIPS-validated crypto and close alignment with upstream.Talos LinuxOpen sourceDistributionsA Linux distribution that only runs Kubernetes: immutable, minimal, with no shell or SSH, and managed entirely through an API.kindOpen sourceFor local developmentKubernetes IN Docker: each cluster node is a container, so a conformant multi-node cluster starts and disappears inside a CI job.minikubeOpen sourceFor local developmentA local Kubernetes cluster for developers on Linux, macOS or Windows, in a container, a VM or on the host itself, with laptop-friendly extras.AgonesOpen sourceBuilt on itRuns dedicated multiplayer game servers on Kubernetes: keeps a fleet of them warm, hands one to each match, and never kills a server while players are on it.KlutchOpen sourceBuilt on itA young open-source control plane, built on Crossplane, that lets many application clusters order databases from one central Kubernetes cluster.

How it fits with other technologies

Bootstrap a control plane, install a Pod network, join a worker · bash

# on the first control plane node (behind a load balancer if you plan HA)
sudo kubeadm init --control-plane-endpoint k8s-api.example.com:6443 \
  --pod-network-cidr 10.244.0.0/16 --upload-certs

# kubeadm installs no network: apply a CNI plugin of your choice
kubectl apply -f <your-cni-plugin.yaml>

# on each worker, using the command init printed
sudo kubeadm join k8s-api.example.com:6443 --token abcdef.0123456789abcdef \
  --discovery-token-ca-cert-hash sha256:<hash>

# later: upgrade the control plane one minor version at a time
sudo kubeadm upgrade plan && sudo kubeadm upgrade apply v1.37.x

Two ways to make the control plane highly available#

Both need a TCP load balancer in front of the API servers on port 6443. kubeadm bootstraps etcd statically, so you plan the members up front.

Stacked etcd

default

Each control plane node runs an API server, controller manager, scheduler and its own etcd member, created by kubeadm init and kubeadm join --control-plane. Simpler to run, but losing a node loses an etcd member and a control plane instance together, so run at least three.

External etcd

more machines

etcd runs on its own hosts, separate from the control plane nodes. Losing a control plane node doesn’t touch etcd, at the cost of twice as many machines to manage.

See it in a real stack

No architecture uses kubeadm yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2016–2026

In 2016, users told the Kubernetes community that installing it was harder than it should be. A cluster needed machines, then Kubernetes installed on them with certificates configured, then add-ons such as DNS, monitoring and a Pod network. SIG Cluster Lifecycle split the job into three stages (provisioning machines, bootstrapping Kubernetes on them, and installing add-ons) and decided to own only the middle one.

kubeadm arrived as an alpha in Kubernetes 1.4 on September 26, 2016, reducing bootstrap to two commands. It was a cross-company effort: Ilya Dmitrichenko of Weaveworks wrote most of the early code, CoreOS built the TLS bootstrapping it relied on, and Red Hat contributed the discovery service. Rather than poke settings into place from outside, the team changed Kubernetes itself so that it would be easy to install.

kubeadm reached general availability in Kubernetes 1.13 in December 2018, with stable commands, a versioned configuration file and fully supported upgrades. Automated high-availability control planes reached beta in 1.15 in 2019. Several community installers adopted it as their base layer instead of reinventing the bootstrap.

Why it’s built this way

Don’t provision machines
Users created machines with Terraform, CloudFormation, Chef, Puppet, Ansible or PXE boot, on clouds, bare metal or Raspberry Pis. Assuming only “some computers running Linux” let kubeadm work everywhere and fit into any of those tools.
Run the control plane as static Pods
kubeadm writes manifest files and the kubelet, which every node runs anyway, starts the API server, scheduler, controller manager and etcd from them. The GA announcement listed this among the methods that “shouldn’t change any time soon”.
Bootstrap tokens plus CA pinning for joining
A short-lived shared token lets a new node authenticate, and the CA public key hash lets the node check it is talking to the right control plane, without copying certificates around by hand.
Leave networking and add-ons to the user
Every team prefers a different Pod network and monitoring stack. Keeping them out kept kubeadm lean, vendor neutral and easy to embed in higher-level tools.

Timeline

  1. 2016

    Alpha in Kubernetes 1.4, September 26

  2. 2018

    Generally available in Kubernetes 1.13, December

  3. 2019

    Automated HA control planes reach beta in 1.15

  4. 2026

    Ships with Kubernetes 1.37 in August

Sources11 · facts checked 6 October 2026

Improve this page on GitHub