Installing with kubeadm
kubeadm is the official tool for bootstrapping a conformant Kubernetes cluster by hand. It sets up the control plane and joins nodes, handling the fiddly parts — certificates, static Pod manifests, kubelet configuration — while deliberately leaving other choices to you.
Most people will run a managed cluster and never touch kubeadm. But building one cluster by hand teaches what the managed providers do for you, and what "the control plane" actually consists of.
What kubeadm Does
kubeadm init bootstraps the control plane on the first node: it generates the cluster's certificate authority and certificates, writes static Pod manifests for the API server, controller-manager, and scheduler, brings up etcd (stacked on the control-plane node by default, or external), and configures the kubelet. The result is a running, conformant control plane and an admin kubeconfig — the minimum from which a cluster grows.
What It Leaves to You
kubeadm is deliberately unopinionated about pluggable pieces. It does not install a CNI plugin — so immediately after init, nodes are NotReady and Pods stay Pending until you install one (Topic 22). It does not pick your storage, ingress, or monitoring. This is by design: kubeadm bootstraps the core and expects you to choose the rest. The "my fresh cluster doesn't work" surprise is almost always the missing CNI.
Joining Nodes and HA
kubeadm join adds nodes using a bootstrap token and the CA's hash to establish trust. A single-control-plane cluster is fine for learning but is a single point of failure; a highly available setup runs multiple control-plane nodes (three for etcd quorum) behind a load balancer for the API server. Production self-managed clusters always run HA control planes — a single control-plane node losing its disk loses the cluster.
kubeadm init --pod-network-cidr=10.244.0.0/16 # 1. set up kubectl access (copy admin.conf) # 2. install a CNI plugin — until then nodes are NotReady kubeadm join <cp-endpoint> --token <token> \ --discovery-token-ca-cert-hash sha256:<hash>
Certificates and Alternatives
kubeadm-issued certificates expire (one year by default), and a cluster whose certs silently expired is a classic outage — renewal is part of upgrades and must be tracked. For provisioning many clusters, higher-level tools build on or around kubeadm: kops and Cluster API manage cluster lifecycle declaratively, treating clusters themselves as reconciled resources. But the honest default remains: unless you have a specific reason to self-manage (on-prem, air-gapped, edge), a managed control plane (Part 11) removes all of this work.
kubeadm self-managed — you run and maintain the control plane, etcd, certs, and upgrades. Full control, real ongoing work.
Managed (EKS/GKE/AKS) — the provider runs the control plane and etcd. Far less to operate; the usual choice (Part 11).
- Expecting a freshly
init'd cluster to work before installing a CNI plugin — nodes stay NotReady. - Running a single control-plane node in production, making etcd and the API a single point of failure.
- Letting kubeadm certificates expire silently, causing a control-plane outage.
- Treating kubeadm as a full platform — it bootstraps the core; storage, ingress, monitoring are yours.
- Self-managing with kubeadm without a concrete reason when a managed control plane would do.
- Install a CNI plugin immediately after
kubeadm init; it is step two, not optional. - Run an HA control plane (three etcd members behind an API load balancer) for anything production.
- Track and renew certificates as part of regular upgrade maintenance.
- Use Cluster API or kops when managing many self-hosted clusters declaratively.
- Choose a managed control plane unless on-prem, air-gapped, or edge constraints force self-hosting.
Knowledge Check
Why are nodes NotReady immediately after kubeadm init?
- kubeadm does not install a CNI plugin; until one is installed, Pod networking can't be set up
- The API server static Pod has not finished starting, so the nodes cannot register as Ready yet
- etcd needs a separate license key activated first
- The kubelet binary must be compiled from source on each node
What does kubeadm set up that you should not have to assemble by hand?
- The control-plane components, CA and certificates, etcd, and kubelet config
- The CNI network plugin and a default ingress controller
- A full monitoring and centralized logging stack wired up across every namespace
- Your application Deployments and Services
What is a classic cause of a self-managed control-plane outage over time?
- kubeadm certificates expiring silently without renewal
- Defining too many Services across the cluster's namespaces
- Using a third-party CNI plugin for Pod networking
- Running a highly available stacked control plane
You got correct