kubeadm Lifecycle
kubeadm Lifecycle
Bootstrap the control plane, then join workers:
kubeadm init --pod-network-cidr=10.244.0.0/16 --kubernetes-version=v1.31.0
mkdir -p $HOME/.kube && cp /etc/kubernetes/admin.conf $HOME/.kube/config
kubeadm token create --print-join-command # worker join line
kubeadm init runs preflight checks, certs the API server, boots static pods (apiserver, etcd, scheduler, controller-manager) under /etc/kubernetes/manifests, and issues a bootstrap token. Workers run kubelet + kube-proxy; the CNI is applied separately (kubectl apply -f flannel.yaml) — until it lands, pods stay ContainerNetworking failure states. Cluster configuration for future upgrades comes from the kubeadm-config ConfigMap in kube-system.
etcd Backup, Restore, Certs
etcd Backup, Restore, Certs
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
snapshot save /var/tmp/etcd-$(date +%F).db
etcdctl snapshot status /var/tmp/etcd-*.db -w table
Disaster restore on a single node: stop the control-plane static pods, run etcdctl snapshot restore ... --data-dir=/var/lib/etcd2, repoint manifests, restart, then confirm API health. Certificate problems are a top exam failure: kubeadm certs check-expiration, kubeadm certs renew all (then restart static pods so new certs load), and regenerate a lost bootstrap token with kubeadm token create.
Upgrades and Pitfalls
Upgrades and Pitfalls
Control plane first, one minor version at a time:
kubeadm upgrade plan
kubeadm upgrade apply v1.32.0 # on the control-plane node
kubectl drain node2 --ignore-daemonsets --delete-emptydir-data
kubeadm upgrade node # on the worker
kubectl uncordon node2
Common failures: drain refusing without --ignore-daemonsets (or with DaemonSet-managed pods on nodes); upgrading workers before the control plane; skipping versions the upgrade path forbids; container runtime socket mismatch after a runtime change. Verify with kubectl get nodes (kubelet versions converge) and kubectl get pods -n kube-system all Running/Ready.
Quiz
1. Which command generates a ready-to-use worker join line?
2. After kubeadm certs renew all, what must you do?
3. What is the correct upgrade order for a cluster?
Flashcards
Question
kubeadm init vs join
Click to reveal answer
Answer
init bootstraps the control plane (static pods, certs, tokens); join attaches a worker with a bootstrap token.
Question
etcd snapshot command
Click to reveal answer
Answer
etcdctl snapshot save with --endpoints/--cacert/--cert/--key from /etc/kubernetes/pki/etcd — then snapshot status to verify.
Question
kubeadm certs renew all
Click to reveal answer
Answer
Renews control-plane certificates; restart static pods afterward so apiserver/etcd pick them up.
Question
Drain flags
Click to reveal answer
Answer
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data — required to evict for upgrades safely.
Revision Notes
Key Takeaways
- 1. kubeadm drives init/join/upgrade/certs; CNI is applied separately
- 2. etcd snapshots via etcdctl (never file copies) underpin control-plane DR
- 3. Upgrades: control plane → drain worker → kubeadm upgrade node → uncordon, one minor version at a time
Interview Tips
- • Recite the upgrade sequence with the reason the order matters (API version skew)
- • Walk etcd restore end-to-end, including how you verify success afterward
Cheat Sheet
kubeadm init --pod-network-cidr → CNI → join workers. DR: etcdctl snapshot save + restore. Certs: check-expiration → renew all → restart static pods. Upgrade: apply CP → drain → upgrade node.