Install a Cluster with kubeadm

Why this matters

Every CKA troubleshooting question assumes you know what a healthy cluster looks like. kubeadm builds clusters the same way every time: etcd for state, kube-apiserver as the front door, kube-controller-manager and kube-scheduler as the loops, kubelet plus a container runtime on every node, and kube-proxy for service traffic. When a component fails later, you already know which log to open first because you watched each piece start.

Concepts

kubeadm init boots the control plane on one machine: it writes certificates, starts the static-pod manifests for etcd plus apiserver plus controller-manager plus scheduler, uploads the cluster configuration, and prints the join command. kubeadm join runs that command on each worker, which registers the node and starts its kubelet. The cluster network (CNI plugin) is a separate install step after init; pods stay Pending until it lands, which is itself a favorite exam symptom.

A single control plane is a single point of failure, so production runs three control-plane nodes. The common shape is stacked etcd: each control-plane node runs its own etcd member alongside the apiserver, and kubeadm joins the extra control-plane nodes with kubeadm join --control-plane. The alternative is external etcd, which survives losing any one node differently but adds machines you must operate. For the exam, know the trade: stacked is fewer machines and the etcd quorum still needs two of three members healthy.

The admin kubeconfig at /etc/kubernetes/admin.conf is full cluster-admin access. Copy it to your own ~/.kube/config to use the cluster, and treat that file like a root password: anyone holding it owns every namespace.

Worked example

A two-machine lab, control plus worker, Ubuntu LTS on both:

# control plane node
sudo kubeadm init --pod-network-cidr=10.244.0.0/16
mkdir -p $HOME/.kube
sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config
kubectl apply -f <cni-plugin-manifest>
# worker node (command printed by init)
sudo kubeadm join <control-ip>:6443 --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash>
kubectl get nodes

The last line must show both nodes Ready. If the worker stays NotReady, check the CNI install before anything else: no network plugin means no pod networking, and kubelet reports it honestly.

Exam notes

The pod CIDR flag must match the CNI plugin you install; a mismatch leaves CoreDNS pending forever. Token expiry (24 hours by default) breaks joins the next day, which is a classic gotcha when a lab spans two sittings. And kubeadm init preflight errors are usually swap, missing kernel modules, or a container runtime that is not running: read the error, fix the host, rerun.