9.5 Deployment With kubeadm - Introduction

Abstract

kubeadm is a Kubernetes bootstrap tool used to create production-style Kubernetes clusters by installing and configuring the required control plane and worker node components.

It simplifies cluster setup by handling certificates, control plane initialization, and worker node joining steps.

What is kubeadm?

kubeadm is a command-line tool used to bootstrap Kubernetes clusters.

It helps set up a cluster following Kubernetes best practices without manually configuring every component.

Without kubeadm, you must manually configure:

kube-apiserver
etcd
controller manager
scheduler
kubelet
certificates
kubeconfig files
cluster networking
worker node joining

Tip

kubeadm does not provision machines for you. You must create the servers or virtual machines first.

kubeadm Cluster Architecture

A basic kubeadm cluster usually contains:

Node Type	Main Components
Control Plane / Master	kube-apiserver, etcd, controllers, scheduler
Worker Node	kubelet, container runtime
All Nodes	kubeadm, kubelet, kubectl, container runtime

Example layout:

Control Plane Node
  ├── kube-apiserver
  ├── etcd
  ├── controller-manager
  ├── scheduler
  ├── kubelet
  └── container runtime

Worker Node 1
  ├── kubelet
  └── container runtime

Worker Node 2
  ├── kubelet
  └── container runtime

Note

The control plane manages the cluster. Worker nodes run application workloads.

Why Use kubeadm?

kubeadm is useful because it:

initializes the control plane
generates required certificates
creates kubeconfig files
configures control plane components
generates worker join commands
supports multi-node clusters
follows Kubernetes recommended setup patterns

Success

kubeadm is commonly used for learning, labs, self-managed clusters, and production-style cluster bootstrapping.

What kubeadm Does Not Do

kubeadm does not:

create virtual machines
install the operating system
configure cloud infrastructure
install a CNI plugin automatically
manage external load balancers
manage node OS patching
provide managed Kubernetes upgrades like EKS, GKE, or AKS

Warning

kubeadm bootstraps Kubernetes, but infrastructure preparation is still your responsibility.

High-Level Deployment Steps

The kubeadm setup process follows this flow:

1. Provision nodes
2. Install container runtime
3. Install kubeadm, kubelet, and kubectl
4. Initialize control plane
5. Configure kubectl access
6. Install pod network plugin
7. Join worker nodes
8. Validate cluster

Step 1 — Provision Nodes

Create multiple Linux machines or virtual machines.

Minimum lab setup:

Role	Example
Master	1 control plane node
Worker	1 or more worker nodes

Production setup:

Role	Recommendation
Control Plane	3 or more nodes for HA
Workers	Based on workload requirements
Load Balancer	Required for HA API server endpoint

Tip

Each node should have a unique hostname, unique MAC address, and stable IP address.

Step 2 — Install Container Runtime

Kubernetes needs a container runtime to run containers.

Common runtime:

containerd

Install the container runtime on all nodes.

sudo apt-get update
sudo apt-get install -y containerd

Note

kubeadm does not run containers directly. The kubelet talks to the container runtime.

Step 3 — Install kubeadm, kubelet, and kubectl

Install Kubernetes tools on all nodes.

Tool	Purpose
kubeadm	Bootstraps the cluster
kubelet	Runs on every node and manages pods
kubectl	CLI used to interact with the cluster

sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

Tip

Holding package versions prevents accidental Kubernetes upgrades.

Step 4 — Initialize Control Plane

Run this only on the master/control plane node.

sudo kubeadm init

For a specific pod network CIDR:

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

For HA clusters, use a control plane endpoint:

sudo kubeadm init \
  --control-plane-endpoint "LOAD_BALANCER_DNS_OR_IP:6443" \
  --pod-network-cidr=10.244.0.0/16

Warning

The pod network CIDR must match the CNI plugin requirements.

Step 5 — Configure kubectl Access

After kubeadm init, configure kubectl for the admin user.

mkdir -p $HOME/.kube

sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

sudo chown $(id -u):$(id -g) $HOME/.kube/config

Test access:

kubectl get nodes

Note

At this stage, nodes may show NotReady until a pod network plugin is installed.

Step 6 — Install Pod Network

Normal node network connectivity is not enough.

Kubernetes requires a pod network so pods can communicate across nodes.

Examples of CNI plugins:

Calico
Flannel
Cilium
Weave Net

kubectl apply -f <cni-plugin-manifest.yaml>

Warning

Without a CNI plugin, CoreDNS and application pods may stay in Pending or ContainerCreating state.

Step 7 — Join Worker Nodes

After control plane initialization, kubeadm prints a join command.

Run it on each worker node.

sudo kubeadm join <control-plane-ip>:6443 \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash>

If the join command is lost, generate a new one from the control plane node:

kubeadm token create --print-join-command

Tip

Worker nodes must be able to reach the control plane API server on port 6443.

Step 8 — Validate Cluster

Check nodes:

kubectl get nodes

Check system pods:

kubectl get pods -n kube-system

Check cluster information:

kubectl cluster-info

Expected result:

NAME            STATUS   ROLES           AGE   VERSION
master          Ready    control-plane   10m   v1.x.x
worker-node-1   Ready    <none>          8m    v1.x.x
worker-node-2   Ready    <none>          8m    v1.x.x

Success

The cluster is ready when all nodes show Ready and core system pods are running.

kubeadm Setup Flow

Master Node
  1. Install containerd
  2. Install kubeadm, kubelet, kubectl
  3. Run kubeadm init
  4. Configure kubectl
  5. Install pod network

Worker Nodes
  1. Install containerd
  2. Install kubeadm, kubelet, kubectl
  3. Run kubeadm join

Important Ports

Component	Port	Direction	Purpose
kube-apiserver	6443	Inbound	Kubernetes API
etcd client	2379	Inbound	API server to etcd
etcd peer	2380	Inbound	etcd member communication
kubelet	10250	Inbound	kubelet API
kube-scheduler	10259	Inbound	scheduler health/API
kube-controller-manager	10257	Inbound	controller health/API
NodePort Services	30000-32767	Inbound	External service access

Warning

Firewalls, security groups, or host-based rules must allow required Kubernetes ports.

Production Best Practices

Recommended

Use at least 3 control plane nodes for production HA
Place the API server behind a load balancer
Use stable node hostnames and IPs
Use containerd as the container runtime
Install a supported CNI plugin immediately after kubeadm init
Use dedicated control plane nodes for cluster management
Keep Kubernetes package versions pinned
Take etcd backups regularly
Use automation tools for repeatable setup
Validate node, pod, DNS, and service networking after installation

Do's

Prepare all nodes before running kubeadm
Disable swap before initializing the cluster
Install container runtime on every node
Install kubeadm and kubelet on every node
Run kubeadm init only on the control plane node
Run kubeadm join only on worker nodes
Install a CNI plugin after initialization
Verify all system pods in kube-system
Document the pod CIDR, service CIDR, and CNI used

Don'ts

Don't run kubeadm init on every node
Don't skip the pod network installation
Don't use overlapping pod and service CIDRs
Don't expose the API server publicly without proper security
Don't use one control plane node for critical production clusters
Don't ignore certificate expiry
Don't upgrade Kubernetes packages randomly
Don't run workloads on control plane nodes in production unless intentionally designed

Danger

A kubeadm cluster can be created quickly, but production reliability depends on correct networking, HA design, security, backups, and monitoring.

Common Troubleshooting

Node is NotReady

Check node status:

kubectl describe node <node-name>

Check CNI pods:

kubectl get pods -n kube-system

Common cause:

CNI plugin not installed or not running

Worker Node Cannot Join

Check:

ping <control-plane-ip>
nc -zv <control-plane-ip> 6443

Regenerate join command:

kubeadm token create --print-join-command

kubelet Not Running

systemctl status kubelet
journalctl -u kubelet -xe

View kubeadm Configuration

kubectl get configmap kubeadm-config -n kube-system -o yaml

kubeadm vs Managed Kubernetes

Area	kubeadm	Managed Kubernetes
Infrastructure	You manage	Provider manages
Control plane	You manage	Provider manages
Flexibility	High	Medium
Operational effort	High	Lower
HA setup	Manual	Usually built-in
Best for	Self-managed clusters, labs, custom environments	Production cloud workloads

Tip

Use kubeadm when you need control and learning depth. Use managed Kubernetes when you want reduced operational overhead.

Exam and Practical Notes

CKA Focus

For CKA-style tasks, understand:

installing kubeadm, kubelet, kubectl
initializing a cluster
joining worker nodes
installing a CNI plugin
checking node readiness
troubleshooting kubelet and CNI issues

Useful Commands

Task	Command
Initialize control plane	`kubeadm init`
Print join command	`kubeadm token create --print-join-command`
Join worker node	`kubeadm join ...`
Check nodes	`kubectl get nodes`
Check system pods	`kubectl get pods -n kube-system`
Check kubelet	`systemctl status kubelet`
View kubelet logs	`journalctl -u kubelet -xe`
Reset node	`kubeadm reset`

Summary

Quote

kubeadm bootstraps Kubernetes clusters
It reduces manual setup of control plane components, certificates, and node joining
Install container runtime, kubeadm, kubelet, and kubectl before initialization
Run kubeadm init on the control plane node
Install a pod network before expecting nodes to become Ready
Run kubeadm join on worker nodes
For production, design for HA, backups, monitoring, and secure networking