kubeadm's Job
kubeadm's Job
kubeadm bootstraps the minimum viable control plane. It deliberately does not install a container runtime, configure kubelet beyond a default, or deploy a CNI — those choices stay yours.
Two commands cover most use:
sudo kubeadm init --pod-network-cidr=10.244.0.0/16 \
--control-plane-endpoint=lb.internal:6443
kubeadm join lb.internal:6443 \
--token 9a0fj.0123456789abcdef \
--discovery-token-ca-cert-hash sha256:<hash>
init generates the CA, writes static pod manifests for etcd, apiserver, scheduler, and controller-manager under /etc/kubernetes/manifests, and emits an admin kubeconfig. join trusts the CA, obtains a serving certificate for the new kubelet, and registers the node.
CNI, Workers, and Certificates
CNI, Workers, and Certificates
Until a CNI runs, nodes report NotReady and no pod receives an IP. Install one immediately after init:
kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml
kubectl get nodes
Add workers with the plain join command; add control-plane members with kubeadm join phase controlplane-prepare against the same endpoint (or stacked etcd joins for HA). Certificates live in /etc/kubernetes/pki — check kubeadm certs check-expiration, renew with kubeadm certs renew all, then restart the static pods. Bootstrap tokens expire after 24 hours; mint fresh ones with kubeadm token create --print-join-command.
Pitfalls and Recovery
Pitfalls and Recovery
Pitfall 1 — skipping the CNI. kubeadm init reports success while CoreDNS stays Pending; beginners then debug DNS instead of networking. The init output warns you for exactly this reason.
Pitfall 2 — a single control-plane endpoint. Without a load balancer or multiple stacked-etcd members, the API server is one failure away from downtime. For HA use --control-plane-endpoint plus kubeadm join --control-plane on additional masters for a quorum of 3.
Interview-ready: recite init → CNI → join, name the artifacts kubeadm creates (CA keys, static manifests, kubeconfigs), and walk recovery: etcd member loss restores from etcdctl snapshot (or is removed and re-added); expired certificates renew then restart the control-plane static pods.
Quiz
1. Why do nodes stay NotReady right after kubeadm init?
2. What is the default lifetime of a kubeadm bootstrap token?
3. Which directory holds the control plane static pod manifests?
Flashcards
Question
What kubeadm does NOT install
Click to reveal answer
Answer
Container runtime, CNI plugin, and application workloads — only the control plane bootstrap.
Question
pod-network-cidr flag
Click to reveal answer
Answer
Sets the pod CIDR the controller-manager delegates to kubelets/CNI for pod IP allocation.
Question
Certificate lifecycle
Click to reveal answer
Answer
kubeadm certs check-expiration / renew all, then restart static pods to load new certs.
Question
etcd recovery tool
Click to reveal answer
Answer
etcdctl snapshot save/status/restore on a healthy member before or during failure.
Revision Notes
Key Takeaways
- 1. kubeadm init → CNI apply → kubeadm join is the canonical bootstrap
- 2. Tokens and certificates both expire; know their renewal commands
- 3. HA needs a stable control-plane endpoint and an odd etcd quorum
Interview Tips
- • Walk the bootstrap sequence and name the files kubeadm generates
- • Answer failure questions with the exact recovery command, not general advice
Cheat Sheet
kubeadm init (control plane) → apply CNI → kubeadm join (workers). Tokens 24h; certs via kubeadm certs renew; etcd via snapshot save/restore.