Bootstrapping a Cluster with kubeadm

Learn how kubeadm automates the complex PKI and static-pod setup required to stand up a production-grade control plane, then join worker nodes using bootstrap tokens.

intermediate5 hoursRead → Lab → Quiz → Practice

🧠 Brain Warm-Up

🧠 Brain Warm-Up: Before Kubernetes existed, administrators had to manually generate TLS certificates for every control plane component, configure systemd units, and wire static files by hand. What would break first if the etcd CA and the apiserver CA were different root certificates? Think about it before reading below.

kubeadm: Automated Cluster Bootstrap

kubeadm is the official Kubernetes cluster bootstrap tool. It handles the hard parts: generating a PKI from scratch, writing static pod manifests, and producing kubeconfig files so each control-plane component can authenticate to the API server.

The kubeadm init Workflow

kubeadm init runs through six well-defined phases. Each phase can be run individually with kubeadm init phase for debugging:

kubeadm init
    │
    ├─ 1. Preflight Checks ──── swap disabled? kernel params? required binaries?
    │                            ports available? container runtime responding?
    │
    ├─ 2. Certificates ─────── generate /etc/kubernetes/pki/
    │                            ca.crt, apiserver.crt, apiserver-etcd-client.crt,
    │                            front-proxy-ca.crt, etcd/ca.crt, sa.key/sa.pub
    │
    ├─ 3. Kubeconfigs ──────── admin.conf, controller-manager.conf,
    │                            scheduler.conf, kubelet.conf
    │
    ├─ 4. Control Plane ────── write static pod manifests to
    │      Static Pods          /etc/kubernetes/manifests/
    │                            kube-apiserver.yaml, kube-controller-manager.yaml,
    │                            kube-scheduler.yaml, etcd.yaml
    │                            (kubelet auto-starts them as "mirror pods")
    │
    ├─ 5. Bootstrap Token ──── generate short-lived token (format: abcdef.0123456789abcdef)
    │                            used by workers to authenticate during join
    │
    └─ 6. Kubelet Config ───── write /var/lib/kubelet/config.yaml and
                                /etc/kubernetes/kubelet.conf
                                then restart kubelet

Post-init: CNI Plugin

After init, the control plane is running but the CoreDNS pods will remain Pending until a CNI plugin is installed. Without a CNI, there is no overlay network for pod-to-pod traffic across nodes.

Without CNI:
  node-1 Pod ──X──▶ node-2 Pod   (no route)

With Flannel (VXLAN):
  node-1 Pod ──▶ flannel0 ──▶ VXLAN encap ──▶ eth0 ──▶ node-2 eth0 ──▶ VXLAN decap ──▶ flannel0 ──▶ node-2 Pod

Worker Join Flow

The worker node uses the bootstrap token to authenticate a one-time TLS handshake:

Worker Node
    │
    ├─ kubeadm join <control-plane-ip>:6443
    │      --token <bootstrap-token>
    │      --discovery-token-ca-cert-hash sha256:<hash>
    │
    ├─ Contacts API server with token ──▶ API server validates token
    ├─ Downloads cluster CA cert ──▶ verifies against provided hash
    ├─ Generates kubelet client cert (TLS bootstrap) ──▶ signed by cluster CA
    └─ kubelet starts with permanent certificate → node appears Ready

kubeadm vs. Manual Setup

Aspect	Manual	kubeadm
PKI generation	openssl commands by hand	Automated with sane defaults
Static pods	Write YAML by hand	Generated from version-aware templates
Kubelet config	Manual systemd unit	Written by kubeadm, restarted automatically
Upgrade path	Fully manual	`kubeadm upgrade apply`
Bootstrap tokens	N/A	Auto-generated with 24h TTL

kubeadm does not manage the underlying infrastructure (VMs, network) — it only configures the Kubernetes layer on top of an already-running OS.

←

CKAD: Certified Kubernetes Application Developer

etcd — Backup, Restore & Health

→