Start Kubernetes installation on Ubuntu 26.04 server

This guide starts after the Ubuntu 26.04 Server installation guide. At this point the server should boot cleanly, have SSH access available, and use a storage layout that leaves enough room for Kubernetes runtime data under /var.

Do not install Kubernetes packages before the node passes basic operating system, hostname, kernel, and container runtime checks.

Kubernetes node preparation rule

Start by checking swap. Kubernetes expects swap to be disabled unless the cluster is explicitly configured for swap-aware behavior. For a standard kubeadm-style setup, this command should print nothing.

swapon --show

# Expected result: no output

Update package metadata and apply available upgrades before adding Kubernetes or container runtime repositories. This reduces avoidable package conflicts later.

sudo apt update && \
sudo apt full-upgrade -y

Install a small base toolset for downloading repositories, editing configuration, inspecting the node, and troubleshooting networking during cluster setup.

sudo apt install -y \
  curl \
  wget \
  vim \
  git \
  htop \
  ca-certificates \
  gnupg \
  lsb-release \
  apt-transport-https \
  software-properties-common \
  net-tools \
  unzip

Before changing kernel and container runtime configuration, confirm that the node has the expected CPU capabilities, memory, and CPU topology. These checks are especially useful when the node is a virtual machine.

Virtualization support#

egrep -c '(vmx|svm)' /proc/cpuinfo

A value greater than 0 means CPU virtualization flags are exposed to the operating system. This matters when the Kubernetes node itself will run nested virtualization workloads or when you are validating VM host settings.

Memory and CPU#

free -h

lscpu

Use a stable hostname before joining the node to a cluster. Renaming a node after Kubernetes components are installed is possible, but it creates unnecessary cleanup work.

Check hostname#

hostnamectl

Change hostname if needed#

sudo hostnamectl set-hostname yourhostname

Add hostname to /etc/hosts#

sudo nano /etc/hosts

127.0.1.1 yourhostname

Kubernetes networking relies on Linux bridge filtering and overlay support. Configure the required modules so they load on boot, then load them immediately for the current session.

sudo nano /etc/modules-load.d/k8s.conf

overlay
br_netfilter

sudo modprobe overlay && \
sudo modprobe br_netfilter

Checks#

lsmod | grep overlay && \
lsmod | grep br_netfilter

Enable bridge packet visibility for iptables and IPv4 forwarding. Without these settings, pod networking and service routing can fail in ways that are hard to diagnose later.

sudo nano /etc/sysctl.d/k8s.conf

net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1

sudo sysctl --system

Check IPv4 forwarding#

sysctl net.ipv4.ip_forward

net.ipv4.ip_forward = 1

containerd is the container runtime used by the Kubernetes node. Add Docker's Ubuntu repository first, then install the packaged containerd runtime from that repository.

Add Docker repository#

sudo install -m 0755 -d /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) \
  signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo $VERSION_CODENAME) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Install containerd#

sudo apt update && \
sudo apt install -y containerd.io

containerd --version

Configure containerd to use systemd cgroups for the Kubernetes runtime. This keeps the kubelet and container runtime aligned with the cgroup manager used by the operating system.

sudo mkdir -p /etc/containerd/conf.d && \
sudo nano /etc/containerd/conf.d/k8s.toml

[plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runc]
runtime_type = 'io.containerd.runc.v2'

[plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runc.options]
SystemdCgroup = true

Restart and check containerd#

sudo systemctl restart containerd

sudo systemctl status containerd --no-pager

sudo journalctl -u containerd -n 50 --no-pager

At this point the node has the base operating system checks, kernel networking settings, and container runtime configuration needed before adding the Kubernetes package repository.

This article targets Kubernetes v1.36. Keeping the repository URL, installed tools, and held package versions aligned around one Kubernetes minor version makes the setup easier to reproduce and prevents accidental upgrades while the cluster is being configured.

Add kubernetes keyring#

sudo mkdir -p /etc/apt/keyrings && \
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.36/deb/Release.key | \
  sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

Add Kubernetes repository#

echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.36/deb/ /' | \
sudo tee /etc/apt/sources.list.d/kubernetes.list && \
sudo apt update

Install Kubernetes tools#

Install kubelet, kubeadm, and kubectl together. kubelet runs on the node, kubeadm bootstraps the cluster, and kubectl is the command-line client used to inspect and manage the cluster.

sudo apt install -y \
  kubelet \
  kubeadm \
  kubectl

Hold package versions#

Hold the Kubernetes packages after installation. Cluster upgrades should be planned and executed deliberately, not pulled in by a normal system upgrade.

sudo apt-mark hold kubelet kubeadm kubectl

Check the installed tools#

kubeadm version && \
kubectl version --client

Before initializing the control plane, pull the Kubernetes images that kubeadm needs. This is a useful checkpoint because image pull problems are easier to diagnose before kubeadm starts writing cluster state.

sudo kubeadm config images pull

Initialize the first control-plane node with kubeadm. The pod CIDR below is commonly used with Flannel. If a different CNI plugin will be installed later, use the pod network CIDR required by that plugin instead.

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

A successful initialization prints a clear confirmation message near the end of the output.

Your Kubernetes control-plane has initialized successfully!

Keep the kubeadm output. It contains the kubeconfig setup commands and, later, the join command for worker nodes.

kubeadm initialization note

After kubeadm finishes, configure kubectl for the current user. kubeadm prints these commands in the output; the standard local-admin setup usually looks like this.

mkdir -p $HOME/.kube && \
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config && \
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Check the node after configuring kubectl. At this stage the control-plane node usually appears, but it is not ready yet because a pod network add-on has not been installed.

kubectl get nodes

STATUS
NotReady

The NotReady status is normal here. The next article installs Cilium as the CNI, verifies that the node becomes Ready, and adds the first cluster checks.