Установка отказоустойчивого кластера Kubernetes на Ubuntu

Обзор архитектуры

Для обеспечения непрерывной работы приложений в продакшене часто выбирают кластер с несколькими управляющими узлами (master) и отдельными рабочими (worker). В рассматриваемом варианте используется три master‑ноды и три worker‑ноды, что позволяет выдержать отказ любого отдельного сервера без потери доступа к API‑серверу и к хранилищу etcd. Управление кластером осуществляется утилитой kubeadm, а в качестве контейнерного рантайма — containerd, который уже включён в Ubuntu 24.04.

Требования к окружению

Параметр	Значение
ОС	Ubuntu 24.04 LTS (64‑бит)
CPU	минимум 2 ядра на узел
RAM	≥ 4 ГБ (master — 8 ГБ рекомендуется)
Диск	SSD, минимум 30 ГБ, отдельный раздел для etcd (для master)
Сеть	статические IP‑адреса, открытые порты 6443, 2379‑2380, 10250, 10251, 10252, 30000‑32767
Пользователь	root или пользователь с правами sudo

Все узлы должны иметь одинаковый часовой пояс и синхронизированное время (chrony).

Подготовка узлов

Обновление системы
```
sudo apt update && sudo apt upgrade -y
```
Отключение swap (Kubernetes требует отключённый swap).
```
sudo swapoff -a
sudo sed -i '/ swap / s/^/#/' /etc/fstab
```

Настройка ядра – включаем необходимые модули и параметры sysctl:

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/k8s.conf
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF

sudo sysctl --system

Установка контейнерного рантайма (containerd)

sudo apt install -y containerd
sudo systemctl enable --now containerd

Проверяем, что containerd использует cgroup v2 (по умолчанию в Ubuntu 24.04). При необходимости в /etc/containerd/config.toml задаём:

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
  SystemdCgroup = true

Перезапускаем сервис:

sudo systemctl restart containerd

Установка kubeadm, kubelet и kubectl

Добавляем официальный репозиторий Kubernetes:

sudo apt install -y apt-transport-https ca-certificates curl
curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/kubernetes-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

Устанавливаем компоненты фиксированной версии 1.35.0:

sudo apt update
sudo apt install -y kubeadm=1.35.0-00 kubelet=1.35.0-00 kubectl=1.35.0-00
sudo apt-mark hold kubeadm kubelet kubectl

Запускаем kubelet:

sudo systemctl enable --now kubelet

Инициализация первого master‑узла

Создаём конфигурационный файл kubeadm-config.yaml, где задаём HA‑параметры:

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
kubernetesVersion: v1.35.0
controlPlaneEndpoint: "k8s.example.com:6443"   # DNS‑имя или виртуальный IP
networking:
  podSubnet: "10.244.0.0/16"
  serviceSubnet: "10.96.0.0/12"
etcd:
  external:
    endpoints:
    - https://10.0.0.11:2379
    - https://10.0.0.12:2379
    - https://10.0.0.13:2379
    caFile: /etc/kubernetes/pki/etcd/ca.crt
    certFile: /etc/kubernetes/pki/etcd/peer.crt
    keyFile: /etc/kubernetes/pki/etcd/peer.key

Для простоты в этом примере используется встроенный etcd, но в продакшене рекомендуется развернуть отдельный кластер etcd с TLS‑защищёнными сертификатами.

Инициализируем кластер:

sudo kubeadm init --config=kubeadm-config.yaml --upload-certs

После завершения команда выводит kubeadm join‑строку для добавления новых master‑ и worker‑нод, а также сертификатный токен для передачи сертификатов.

Настраиваем kubectl для обычного пользователя:

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

Добавление вторых и третьих master‑нод

На каждом из оставшихся master‑узлов копируем admin.conf (можно через scp) и запускаем:

sudo kubeadm join k8s.example.com:6443 \
  --control-plane \
  --certificate-key <key-from-init-output> \
  --token <token-from-init-output> \
  --discovery-token-ca-cert-hash sha256:<hash>

Эта команда автоматически присоединит узел к текущему etcd‑кластеру и настроит его как управляющий.

Присоединение worker‑нод

На каждом worker‑узле выполняется аналогичная команда, но без флага --control-plane:

sudo kubeadm join k8s.example.com:6443 \
  --token <token-from-init-output> \
  --discovery-token-ca-cert-hash sha256:<hash>

После успешного присоединения проверяем статус:

kubectl get nodes -o wide

Все шесть узлов должны отображаться в статусе Ready.

Установка сетевого плагина

Для обеспечения межподовой коммуникации выбираем лёгкий CNI‑плагин Calico:

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.28/manifests/calico.yaml

Ожидаем, пока поды calico-system перейдут в состояние Running.

Настройка внешнего доступа к API‑серверу

Для обеспечения высокой доступности API‑сервера часто используют keepalived + HAProxy или MetalLB в режиме L2. Пример с keepalived:

Устанавливаем keepalived на всех master‑узлах:
```
sudo apt install -y keepalived
```
Создаём конфигурацию /etc/keepalived/keepalived.conf, где объявляем виртуальный IP (VIP) 10.0.0.200 и ставим state MASTER на первом узле, state BACKUP на остальных.
Перезапускаем сервис:
```
sudo systemctl enable --now keepalived
```

VIP будет автоматически перемещаться между узлами в случае сбоя, а kubeadm уже настроил controlPlaneEndpoint на это IP, поэтому клиентские запросы всегда попадают в живой API‑сервер.

Проверка работоспособности кластера

Тестовое развертывание:

kubectl create deployment nginx --image=nginx:stable
kubectl expose deployment nginx --port=80 --type=NodePort

Получение NodePort:
```
kubectl get svc nginx
```
Открываем http://<any-node-ip>:<nodePort> в браузере – должна отдаваться страница Nginx.

Проверка etcd:

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/peer.crt \
  --key=/etc/kubernetes/pki/etcd/peer.key endpoint health

Вывод должен показывать healthy для всех трёх членов.

Пост‑установочные задачи

Обновление сертификатов: настроить автоматическое продление через cert-manager или kubeadm certs renew.
Мониторинг: развернуть Prometheus‑Operator и Grafana для наблюдения за состоянием узлов, API‑сервера и etcd.
Логирование: установить EFK‑стек (Elasticsearch‑Fluentd‑Kibana) или Loki для централизации журналов.
RBAC: создать отдельные роли и сервисные аккаунты для CI/CD‑pipeline, ограничив их привилегии.
Бэкапы: настроить периодическое резервное копирование etcd (например, через etcdadm или Velero).

Эти шаги завершают создание полностью отказоустойчивого кластера Kubernetes 1.35, готового к работе в продакшене на базе Ubuntu 24.04.

Установка отказоустойчивого кластера Kubernetes 1.35 на Ubuntu 24.04 с помощью kubeadm