Kubernetes Installation with kubeadm

TL;DR

• kubeadm is the reference tool for bootstrapping conformant Kubernetes clusters; understanding its phases matters far more than memorizing exact flags
• Every node requires: swap disabled (both immediate and permanent via /etc/fstab), required kernel modules loaded, container runtime installed, kubeadm/kubelet/kubectl installed
• kubeadm init on the control-plane node bootstraps the cluster but does NOT install a CNI plugin; a NotReady control-plane node almost always means missing CNI
• --control-plane-endpoint must be specified at first init if planning HA; it’s baked into certificates and kubeconfigs at bootstrap time and cannot be easily changed later
• Bootstrap tokens expire after 24 hours by default; generate fresh tokens for workers joining after that window
• Use --upload-certs on init to upload control-plane certificates to a secret, allowing additional control-plane nodes to join without manual certificate copying
• Reset a failed bootstrap attempt cleanly with kubeadm reset -f followed by CNI and iptables cleanup

Core Concepts

The kubeadm Workflow

kubeadm follows a predictable phases-based workflow: preflight checks, certificate generation, API server/scheduler/controller-manager/etcd startup on the control-plane, kubelet configuration, and addon setup. The CKA exam frequently asks diagnostics questions about which phase failed, making understanding this workflow more important than memorizing flags.

Prerequisites on Every Node

Before running kubeadm on any node:

1. Disable swap: swapoff -a (immediate) and comment out swap in /etc/fstab (persistent)
2. Load required kernel modules: overlay and br_netfilter
3. Install and start a container runtime (Docker, containerd, CRI-O)
4. Install kubeadm, kubelet, and kubectl packages from official repositories
5. Start and enable kubelet systemd service

Control-Plane Initialization

kubeadm init on the control-plane bootstraps:

• Generates certificates and keys
• Stands up etcd, API server, scheduler, and controller-manager as static pods
• Creates a kubeconfig file for kubectl access
• Generates bootstrap tokens for worker nodes

Critical: This process does not install a CNI plugin. The node reports NotReady until a CNI manifest is applied, because pod networking is not available until then.

Planning for HA

If high availability is the goal, --control-plane-endpoint must be specified during the very first kubeadm init. This parameter is baked directly into:

• Certificate Subject Alternative Names (SANs)
• Every generated kubeconfig file
• Component startup configurations

Retrofitting this later requires regenerating and redistributing every certificate and kubeconfig across all nodes — a highly disruptive and error-prone process. Specify it correctly on day one, even for clusters that start with a single control-plane node.

Bootstrap Tokens

kubeadm automatically creates a bootstrap token during init for worker nodes to join. Tokens are short-lived (24 hours by default) and are intended for the initial cluster setup window. If the join window passes, generate a fresh token with kubeadm token create --print-join-command rather than waiting for the initial token to become usable again.

Multi-Control-Plane Setup

For HA clusters, use the --upload-certs flag on init to upload control-plane certificates to a secret. This allows additional control-plane nodes to join without manually copying certificates from the first node. Each additional control-plane join command will include a --certificate-key flag to retrieve the certificates from that secret.

Worker Node Joining

Worker nodes join using the bootstrap token and control-plane endpoint. The join process:

1. Contacts the API server to retrieve TLS bootstrap configuration
2. Generates a certificate signing request (CSR)
3. The control-plane signs the worker’s certificate
4. kubelet starts and registers the node

Comparison Table

Phase	Component	When Ready	What to Check
Prerequisites	All nodes	Before init/join	Swap off, kernel modules, container runtime, kubeadm installed
Control-plane Init	API server, etcd, scheduler, controller-manager	After kubeadm init	Pods running in kube-system
CNI Installation	Pod networking	After CNI manifest applied	Nodes transition to Ready status
Worker Join	kubelet	After worker joins	Nodes show up in kubectl get nodes
HA Setup	Certificate replication	Parallel with CP init	use –upload-certs flag

Command Reference

Initialize a control-plane node (single-master):

kubeadm init --pod-network-cidr=10.244.0.0/16

Initialize a control-plane node with HA endpoint:

kubeadm init \
  --control-plane-endpoint=loadbalancer.example.com:6443 \
  --upload-certs \
  --pod-network-cidr=10.244.0.0/16

Disable swap on a node (temporary):

swapoff -a

Disable swap permanently via fstab:

sed -i '/ swap / s/^/#/' /etc/fstab

Load required kernel modules:

modprobe overlay
modprobe br_netfilter

Generate a fresh bootstrap token for worker nodes:

kubeadm token create --print-join-command

List active bootstrap tokens:

kubeadm token list

Join a worker node to the cluster (example):

kubeadm join 192.168.1.100:6443 --token abc123.defghi --discovery-token-ca-cert-hash sha256:...

Verify cluster health after installation:

kubectl get nodes
kubectl get pods -n kube-system

Reset a failed bootstrap attempt cleanly:

kubeadm reset -f
rm -rf /etc/cni/net.d
iptables -F && iptables -t nat -F

Apply a CNI plugin manifest (example: Flannel):

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

Common Pitfalls

Pitfall — NotReady Control-Plane Node After kubeadm init After kubeadm init completes successfully, the control-plane node shows NotReady status and stays that way indefinitely.

• Why: kubeadm init intentionally does not install a CNI plugin; CNI choice is deployment-specific. Without CNI, the kubelet cannot assign pod IPs, so the Ready condition stays false and CoreDNS pods remain Pending.
• Fix: Apply a CNI manifest (Calico, Cilium, Flannel, etc.) immediately after init to enable pod networking.

Pitfall — Swap Re-enables After Reboot Swap is disabled with swapoff -a, but after the next system reboot, kubelet fails to start or behaves mysteriously.

• Why: swapoff -a only affects the current boot session; the swap entry in /etc/fstab re-enables it at reboot.
• Fix: After running swapoff -a, also comment out or remove the swap entry in /etc/fstab to make the change permanent.

Pitfall — Changing Control-Plane Endpoint After Initial Cluster Attempting to add a second control-plane node to a cluster initialized without --control-plane-endpoint set.

• Why: The endpoint is baked into every certificate SAN and kubeconfig at init time; changing it requires regenerating all certificates and kubeconfigs across all nodes.
• Fix: Specify --control-plane-endpoint during the very first kubeadm init, even for single-master clusters that may go HA later.

Pitfall — Bootstrap Token Expiry A worker node fails to join with “token has expired” error, and retrying the original join command from init doesn’t work.

• Why: kubeadm bootstrap tokens expire after 24 hours by default; the window for joining is limited.
• Fix: Generate a fresh token using kubeadm token create --print-join-command and use that new join command on the worker.

Interview Questions

Q: After kubeadm init completes successfully, the control-plane node shows NotReady. What is the most likely cause and how do you fix it?

Q: Why must --control-plane-endpoint be specified during the first kubeadm init if planning high availability?

Q: Walk through the steps required to set up a two-node HA control-plane using kubeadm with the --upload-certs flag.

Q: Explain why swapoff -a must be paired with an /etc/fstab edit to be effective.

Q: A worker node fails to join with “token has expired” after 25 hours. How do you resolve this?

Q: What is the difference between kubeadm init and kubeadm join? What does each phase accomplish?

Q: Design a kubeadm bootstrap process for a cluster that will run on three control-plane nodes from the start.

Q: List five essential prerequisite checks that must be satisfied on every node before kubeadm can be run.