Встановлення Kubernetes на Ubuntu 24.04

Kubernetes на Ubuntu 24.04 має сенс ставити не як набір випадкових команд, а як передбачуваний базовий кластер з чіткими ролями вузлів, коректним container runtime, мережею для Pod-ів і нормальним шляхом подальшого розширення. Більшість проблем починається не на етапі `kubeadm init`, а раніше: swap не вимкнено, `br_netfilter` не завантажений, container runtime працює з невідповідним cgroup driver, а правила firewall не підготовлені під керуючу ноду та worker-вузли. Через це команда формально виконує інсталяцію, але вже на першому запуску отримує `NotReady`, `CrashLoopBackOff` або мережеві збої між Pod-ами.

У цьому матеріалі розглянемо практичне встановлення Kubernetes на Ubuntu 24.04 через `kubeadm` з `containerd`, підготовкою системи, базовою ініціалізацією control plane, підключенням worker-вузлів і перевіркою мережевого плагіна. Такий сценарій зручний для лабораторного контуру, staging-середовища або для старту операційної платформи, яку далі можна підсилювати через DevOps послуги. Паралельно важливо одразу думати про оновлення, CI/CD і спосіб повторюваного розгортання, тому в кінці також зв'яжемо інсталяцію з процесами на кшталт побудови та оптимізації CI/CD і з уже опублікованим матеріалом про CI/CD: як автоматизація зменшує помилки в релізах.

Передумови і підготовка Ubuntu 24.04

Перед початком варто визначити мінімальну схему кластера. Для тестового контуру можна стартувати з однієї control-plane ноди та однієї worker-ноди. Для більш стійкого сценарію краще мати щонайменше три control-plane вузли і окрему групу worker-ів, але для першого встановлення це не обов'язково.

Базові вимоги до кожного вузла:

- Ubuntu 24.04 LTS - 2 vCPU і 4 GB RAM як мінімум для невеликого стенду - унікальний hostname - стабільна взаємна мережна доступність між вузлами - вимкнений swap - відкриті порти для Kubernetes API, kubelet і overlay-мережі

Корисно також одразу підготувати DNS або хоча б записи в `/etc/hosts`, щоб вузли бачили одне одного по стабільних іменах.

sudo hostnamectl set-hostname k8s-master-01
cat <<'EOF' | sudo tee -a /etc/hosts
10.10.10.11 k8s-master-01
10.10.10.12 k8s-worker-01
EOF

Якщо цього не зробити, на ранньому етапі легко отримати помилки при join або плутанину в сертифікатах і логах.

Системна підготовка

Перший крок це оновлення пакетів, вимкнення swap, завантаження потрібних kernel-модулів і sysctl-параметрів для коректної маршрутизації трафіку контейнерів.

sudo apt update
sudo apt upgrade -y

sudo swapoff -a
sudo sed -i.bak '/\sswap\s/s/^/#/' /etc/fstab

cat <<'EOF' | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

cat <<'EOF' | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF

sudo sysctl --system

Після цього має сенс перевірити, що swap дійсно вимкнений, а параметри ядра застосовані:

swapon --show
sysctl net.ipv4.ip_forward
lsmod | grep br_netfilter

Порожній вивід `swapon --show` означає, що swap вимкнено. Якщо запис лишився, `kubelet` майже гарантовано не пройде валідацію.

Встановлення containerd та Kubernetes пакетів

Для Ubuntu 24.04 практичний вибір це `containerd`. Він стабільно працює з сучасними версіями Kubernetes і не потребує зайвого Docker-шару для базової інсталяції. Спочатку ставимо runtime, генеруємо конфіг і переводимо його на `SystemdCgroup = true`.

sudo apt install -y ca-certificates curl gnupg apt-transport-https

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

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

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

sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml >/dev/null
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml

sudo systemctl restart containerd
sudo systemctl enable containerd kubelet

На цьому етапі варто переконатися, що `containerd` стартував без помилок:

sudo systemctl status containerd --no-pager
sudo crictl info

Якщо `crictl` не встановлено, його можна додати окремо, але для базової інсталяції критичніше бачити, що `containerd` активний і не падає після перезапуску.

Ініціалізація control plane через kubeadm

Перед `kubeadm init` потрібно визначити Pod CIDR, сумісний з обраним CNI. Для прикладу нижче використаємо Calico та діапазон `192.168.0.0/16`.

sudo kubeadm init \
  --pod-network-cidr=192.168.0.0/16 \
  --apiserver-advertise-address=10.10.10.11 \
  --control-plane-endpoint=k8s-master-01

Після успішної ініціалізації `kubeadm` виведе команду `kubeadm join`. Її потрібно зберегти, тому що вона знадобиться для worker-вузлів. Далі налаштовуємо доступ до кластера для поточного користувача:

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

kubectl get nodes

На цьому етапі control-plane вузол зазвичай ще має статус `NotReady`, тому що мережевий плагін не встановлений. Це очікувана поведінка, а не причина одразу перезапускати `kubelet`.

Встановлення CNI, підключення worker-вузлів і базова перевірка

Без CNI Kubernetes не забезпечить нормальну взаємодію Pod-ів. Один з найпоширеніших варіантів це Calico.

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.1/manifests/calico.yaml
kubectl get pods -n kube-system

Коли Pod-и Calico перейдуть у `Running`, можна додавати worker-ноди. На кожному worker-вузлі повторюється та сама системна підготовка, встановлення `containerd`, `kubelet`, `kubeadm`, а потім виконується команда `kubeadm join`, яку згенерував control plane.

sudo kubeadm join k8s-master-01:6443 \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash>

Після підключення вузлів перевірка виглядає так:

kubectl get nodes -o wide
kubectl get pods -A

Після встановлення не варто зупинятися на команді `kubectl get nodes`. Потрібно перевірити, що кластер реально здатен запускати навантаження. Для цього достатньо зробити простий тестовий deployment і service.

kubectl create deployment nginx --image=nginx:1.27
kubectl expose deployment nginx --port=80 --type=ClusterIP
kubectl get deployment,pod,service

Потім зручно виконати port-forward і переконатися, що Pod відповідає:

kubectl port-forward service/nginx 8080:80
curl http://127.0.0.1:8080

Якщо `curl` повертає стандартну сторінку Nginx, значить контейнер стартує, service працює, а DNS і мережа в кластері не зламані на базовому рівні.

Що зробити одразу після першого успішного запуску

Початково встановлений кластер ще не готовий до нормальної експлуатації. Варто одразу:

- увімкнути збір логів і метрик - визначити політику оновлень для `kubeadm`, `kubelet` і CNI - обмежити доступ до `admin.conf` - додати окремі namespace для застосунків - зафіксувати маніфести в git

Без цього інфраструктура працюватиме, але керованість швидко втратиться вже після кількох змін.

Типові помилки

Найчастіша помилка це невимкнений swap. Друга це `containerd` з неправильним cgroup driver, через що `kubelet` не може стабільно працювати з runtime. Третя це запуск `kubeadm init` без продуманого Pod CIDR, а потім спроба накотити CNI, який очікує інший діапазон. Четверта проблема це відсутність відкритих портів між вузлами або фільтрація трафіку з боку cloud firewall. П'ята це надто ранній висновок, що кластер "не працює", хоча control plane просто ще не отримав CNI і тому лишається у `NotReady`.

Окремо часто помиляються з очікуваннями. Kubernetes сам по собі не вирішує хаос з релізами, доступами чи конфігураціями. Якщо після інсталяції продовжити все змінювати вручну, без pipeline, описаних маніфестів і контрольованого процесу, платформа швидко стане важкою в підтримці.

Висновок

Встановлення Kubernetes на Ubuntu 24.04 складається з кількох критичних шарів: правильно підготовлена ОС, стабільний `containerd`, акуратна ініціалізація через `kubeadm`, сумісний CNI і базова перевірка реального навантаження. Якщо пройти ці кроки послідовно, уже на першому циклі можна отримати робочий кластер без типових помилок, які зазвичай з'являються через пропущену системну підготовку.

Практичний наступний крок після інсталяції це не "ще один ручний деплой", а стандартизація всього, що йде поверх кластера: namespace, секрети, ingress, моніторинг, резервні копії й автоматизація розгортань. Саме тоді Kubernetes перестає бути експериментом і стає керованою платформою для команди та сервісів.