Kubernetes на Rocky Linux — пошаговый гайд

Логотип Kubernetes и схема развёртывания кластера

О чём эта инструкция

Это практическое руководство предназначено для системных администраторов и инженеров DevOps, которые хотят развернуть кластер Kubernetes (k8s) на Rocky Linux. Пошаговые команды и пояснения помогут подготовить систему, установить runtime containerd, развернуть контрольную плоскость через kubeadm, подключить рабочие узлы и настроить сетевой плагин Flannel.

Кому подходит: инженеры, администраторы и обучающиеся, у которых есть минимум три сервера Rocky Linux и доступ с правами root или sudo.

Краткие цели инструкции:

Подготовить ОС (hosts, SELinux, модуль ядра, SWAP)
Открыть нужные порты в firewalld
Установить containerd и настроить systemd cgroup
Установить kubelet, kubeadm, kubectl
Инициализировать контрольную плоскость и подключить воркеры
Развернуть Flannel CNI

Важно: команды в примерах выполняются с правами sudo. Перед запуском команд убедитесь, что IP‑адреса и hostnames соответствуют вашей сети.

Содержание

Требования
Подготовка систем
Настройка /etc/hosts и hostname
Правила firewalld для control-plane и worker
SELinux, модули ядра, sysctl и отключение SWAP
Установка containerd и его конфигурация
Установка пакетов Kubernetes (kubeadm, kubelet, kubectl)
Установка Flannel
Инициализация control-plane
Подключение worker‑узлов
Проверки и тесты
Критерии приёмки
Чек‑листы по ролям
Отладка распространённых ошибок и план отката
Рекомендации по безопасности и совместимости
Сводка

Требования

Минимальные требования для этой инструкции:

Три или более серверов Rocky Linux (можно использовать виртуальные машины).
Пользователь с правами root или sudo на всех серверах.
Необходимые порты должны быть доступны между узлами (см. раздел с firewalld).
Доступ в интернет для скачивания пакетов и образов (или локальный mirror).

Совет: для тестовой среды можно использовать 1 CPU, 1–2 ГБ RAM на каждом узле, но для рабочих нагрузок нужно больше ресурсов. Здесь даются команды без привязки к конкретным версиям; при работе в production проверьте совместимости версий Kubernetes, containerd и ядра.

Подготовка систем

Перед установкой Kubernetes нужно стандартно подготовить ОС.

Основные шаги:

Настроить /etc/hosts или DNS, чтобы все hostnames разрешались в нужные IP.
Установить и настроить firewalld (рекомендуется в production).
Перевести SELinux в permissive (или настроить для работы). Для простоты примера — permissive.
Включить модули ядра overlay и br_netfilter.
Отключить SWAP (обязательное требование kubelet).

Важно: kubelet не будет работать корректно при включенном SWAP — отключайте его на всех узлах.

Настройка /etc/hosts и hostname

Для демонстрации в руководстве используются следующие имена и IP:

Hostname              IP Address        Used as
-------------------------------------------------------
kube-master           192.168.5.10      control-plane
kube-worker1          192.168.5.15      worker node
kube-worker2          192.168.5.16      worker node

Установите hostname на каждом сервере:

sudo hostnamectl set-hostname kube-master

На рабочих узлах:

# setup hostname kube-worker1
sudo hostnamectl set-hostname kube-worker1

# setup hostname kube-worker2
sudo hostnamectl set-hostname kube-worker2

Отредактируйте /etc/hosts на всех серверах (добавьте строки ниже):

192.168.5.10 kube-master
192.168.5.15 kube-worker1
192.168.5.16 kube-worker2

Проверьте разрешение имён:

ping kube-master -c3
ping kube-worker1 -c3
ping kube-worker2 -c3

Настройка firewalld

Kubernetes использует несколько портов для API, etcd, kubelet и сервисов NodePort. В RHEL‑совместимых дистрибутивах по умолчанию используется firewalld. Ниже — рекомендуемые правила.

Порты для control-plane (на узле kube-master):

TCP Inbound 6443      Kubernetes API server
TCP Inbound 2379-2380 etcd server client API
TCP Inbound 10250     Kubelet API
TCP Inbound 10259     kube-scheduler
TCP Inbound 10257     kube-controller-manager

На control-plane выполните:

sudo firewall-cmd --add-port=6443/tcp --permanent
sudo firewall-cmd --add-port=2379-2380/tcp --permanent
sudo firewall-cmd --add-port=10250/tcp --permanent
sudo firewall-cmd --add-port=10259/tcp --permanent
sudo firewall-cmd --add-port=10257/tcp --permanent

sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Настройка firewalld на контрольной ноде Kubernetes

Порты для рабочих узлов:

TCP Inbound 10250    Kubelet API
TCP Inbound 30000-32767 NodePort сервисы

На worker‑узлах выполните:

sudo firewall-cmd --add-port=10250/tcp --permanent
sudo firewall-cmd --add-port=30000-32767/tcp --permanent

sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Настройка firewalld на рабочей ноде Kubernetes

Примечание: в некоторых корпоративных сетях политика управления сетью может запрещать открытие портов — в этом случае согласуйте изменения с командой сети.

SELinux, модули ядра, sysctl и отключение SWAP

Kubernetes требует определённых настроек ядра и сетевого стека. Также kubelet требует отключённого SWAP.

SELinux

Для простоты примера переводим SELinux в permissive:

sudo setenforce 0
sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

sestatus

Переключение SELinux в режим permissive

Важно: перевод SELinux в permissive снижает жесткость контроля. В production рекомендуется настраивать политики SELinux правильно или тестировать режим permissive перед переводом в enforcing.

Включение модулей ядра

Kubernetes требует модулей overlay и br_netfilter:

sudo modprobe overlay
sudo modprobe br_netfilter

Сделаем загрузку модулей постоянной:

cat <

`sysctl параметры`

Включим параметры сетевого стека, чтобы iptables видел bridged traffic и включим форвардинг:

cat <

`Отключение SWAP`

Отключите swap и закомментируйте соответствующую строку в /etc/fstab, чтобы swap не включался после перезагрузки:

sudo sed -i '/ swap / s/^\\(.*\\\)$/#\1/g' /etc/fstab
# или редактирование вручную
sudo nano /etc/fstab

sudo swapoff -a
free -m

После выполнения free -m столбец Swap должен показывать 0.

Ошибка: если swap снова активируется после перезагрузки — проверьте, нет ли записей в /etc/crypttab или других механизмов, восстанавливающих swap.

`Установка контейнерного рантайма: containerd`

Kubernetes поддерживает разные CRI‑runtime. В этой инструкции используется containerd.

Установите утилиты для управления репозиториями:

sudo dnf install dnf-utils

Добавьте репозиторий Docker (в качестве удобного источника сборки containerd):

sudo yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo

Проверьте репозитории и кэш:

sudo dnf repolist
sudo dnf makecache

Установите containerd:

sudo dnf install containerd.io

Во время установки вам предложат подтвердить импорт GPG‑ключа — согласитесь.

Сгенерируйте конфигурацию containerd и настройте systemd cgroup:

sudo mv /etc/containerd/config.toml /etc/containerd/config.toml.orig
sudo containerd config default > /etc/containerd/config.toml

# Отредактируйте /etc/containerd/config.toml и в секции runc options установите
# SystemdCgroup = true

Например, найдите блок и измените:

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

Включите и запустите сервис:

sudo systemctl enable --now containerd

sudo systemctl is-enabled containerd
sudo systemctl status containerd

Проверка: containerd должен быть запущен и не выдавать ошибок в журнале (journalctl -u containerd).

`Установка пакетов Kubernetes`

Добавим репозиторий Kubernetes и установим kubeadm, kubelet и kubectl.

Создайте файл репозитория:

cat <

Обновите кэш:

sudo dnf repolist
sudo dnf makecache

Установите пакеты:

sudo dnf install kubelet kubeadm kubectl --disableexcludes=kubernetes

После установки включите и запустите kubelet (он будет ожидать команд от kubeadm):

sudo systemctl enable --now kubelet

kubelet — основной компонент, который управляет Pods на каждом узле. Пока кластер не инициализирован, kubelet может показывать статус ожидания.

`Установка CNI плагина: Flannel`

В качестве сетевого плагина для Pod сети используем Flannel. Flannel прост и надёжен для учебных и небольших production сред.

Скачайте бинарник flanneld в /opt/bin:

mkdir -p /opt/bin/
sudo curl -fsSLo /opt/bin/flanneld https://github.com/flannel-io/flannel/releases/download/v0.19.0/flanneld-amd64
sudo chmod +x /opt/bin/flanneld

При применении манифеста kube‑flannel.yml Kubernetes создаст DaemonSet для flanneld и настроит сеть Pods на CIDR, который вы укажете при init (в нашем примере 10.244.0.0/16).

Примечание: версия Flannel и метод установки могут отличаться. Можно использовать манифест из репозитория flannel или Helm chart.

`Инициализация контрольной плоскости`

Перед инициализацией убедитесь, что modprobe br_netfilter вернул модуль:

lsmod | grep br_netfilter

Загрузите образы, необходимые kubeadm:

sudo kubeadm config images pull

Запустите kubeadm init, указывая pod-network-cidr соответствующий Flannel (10.244.0.0/16) и advertise address контроллера:

sudo kubeadm init --pod-network-cidr=10.244.0.0/16 \
--apiserver-advertise-address=192.168.5.10 \
--cri-socket=unix:///run/containerd/containerd.sock

Пояснения:

–pod-network-cidr=10.244.0.0/16 — диапазон для Pod сети (Flannel по умолчанию использует этот CIDR).
–apiserver-advertise-address — IP, на котором API Server будет доступен внутри кластера.
–cri-socket — путь до сокета containerd. Если не указывать, kubeadm попытается обнаружить его автоматически.

После успешной инициализации вы увидите подсказки для копирования kubeconfig и команду join для воркеров.

Скопируйте креденшелы в домашний kubeconfig, чтобы использовать kubectl под вашим пользователем:

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

Проверьте состояние кластера:

kubectl cluster-info
kubectl get nodes -o wide

Если control-plane запущен, вы увидите соответствующий узел с ролью control-plane.

`Развертывание Flannel`

Примените манифест Flannel (официальный или подходящую версию):

kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

Проверьте поды:

kubectl get pods --all-namespaces

Подсказка: если flannel‑поды долго в статусе ContainerCreating, проверьте логи kubelet, containerd и статус сетевых интерфейсов.

`Подключение рабочих узлов`

При инициализации kubeadm выдаёт команду kubeadm join с токеном и sha256 хэшем CA. Если вы пропустили команду, её можно сгенерировать заново на master:

# получить команду join
kubeadm token create --print-join-command

Выполните полученную команду на каждом рабочем узле (пример):

kubeadm join 192.168.5.10:6443 --token wlg23u.r5x2nxw2vdu95dvp \
        --discovery-token-ca-cert-hash sha256:71fd28ac2b8108a3d493648a9c702acd2e39a8a0e7efc07326d7b0384c929066

После успешного выполнения на master вы увидите подключение новых узлов:

kubectl get nodes -o wide

Проверьте снова поды во всех namespace, чтобы удостовериться, что kube-proxy, coredns и flannel запущены на всех узлах:

kubectl get pods --all-namespaces

`Проверки и базовые тесты`

После развёртывания выполните следующие проверки:

kubectl get nodes — все узлы в Ready состоянии
kubectl get pods –all-namespaces — важные системные поды Running
kubectl get cs (componentstatuses) — при необходимости
Запуск простого приложения: nginx Deployment и Service

Пример теста приложения:

kubectl create deployment nginx --image=nginx
kubectl expose deployment nginx --port=80 --type=ClusterIP
kubectl get pods
kubectl get svc

Проверьте сетевую связь между подами (kubectl exec или netcat внутри pod):

kubectl run -i --tty --rm debug --image=busybox -- sh
# внутри контейнера
wget -qO- http://

Если pod-to-pod связь работает — сеть настроена верно.

`Критерии приёмки`

Кластер считается корректно развёрнутым, если выполнены пункты:

На master: kube-apiserver, kube-controller-manager, kube-scheduler, etcd работают и Ready.
На всех узлах: kubelet работает и узлы в состоянии Ready.
Flannel и coredns запущены и работают.
Простой Deployment и Service могут быть успешно созданы и отвечают.
Отсутствие ошибок в логах kubelet и containerd, связанных с CRI, cgroup или networking.

`Чек‑лист для ролей`

Чек‑лист администратора control-plane:

Проверить /etc/hosts и hostname
Настроить firewalld (открыть порты control-plane)
Установить containerd и включить SystemdCgroup
Установить kubeadm/kubelet/kubectl
Запустить kubeadm init и сохранить kubeconfig
Применить CNI (Flannel)
Проверить состояние pod и node

Чек‑лист оператора worker:

Настроить hostname и /etc/hosts
Настроить firewalld для worker портов
Установить containerd и kubelet
Отключить swap и включить требуемые модули ядра
Выполнить kubeadm join
Проверить статус узла на master

Чек‑лист разработчика/Dev:

Проверить доступ kubectl к кластеру
Запустить тестовое приложение
Протестировать доступность сервисов и сетевые политики

`План отката и инцидентный плейбук`

Если инициализация прошла некорректно или нужно откатиться на узле, используйте kubeadm reset и очистку артефактов.

Шаги для отката на узле:

# на узле выполняйте с осторожностью
sudo kubeadm reset -f
sudo systemctl stop kubelet
sudo systemctl stop containerd
sudo rm -rf /var/lib/cni/ /var/lib/kubelet/* /etc/cni/ /etc/kubernetes/ /var/lib/etcd
sudo systemctl start containerd
sudo systemctl start kubelet

После этого можно повторять установку с чистого листа. Для control-plane требуется также восстановление etcd (если данные важны) — в production обязательно иметь бэкапы etcd.

Инцидентный сценарий: если worker не присоединяется

Проверьте соединение до 192.168.5.10:6443 (telnet/nc)
Проверьте токен: на master выполните kubeadm token list
Сгенерируйте команду join: kubeadm token create –print-join-command
Проверьте соответствие CA hash: kubeadm init выводит discovery-token-ca-cert-hash
Смотреть логи: journalctl -u kubelet -f на worker

`Отладка распространённых ошибок`

Типичные причины проблем и пути решения:

SWAP включён — отключите swap и закомментируйте запись в /etc/fstab.
br_netfilter не загружен — modprobe br_netfilter и запись в /etc/modules-load.d.
cgroup driver mismatch — убедитесь, что containerd использует SystemdCgroup = true и kubelet настроен на systemd cgroup.
CRI socket не найден — проверьте путь /run/containerd/containerd.sock и опцию –cri-socket в kubeadm.
Образы не скачиваются — проверьте доступ в интернет или настройте локальный registry/mirror.
Pod в CrashLoopBackOff — смотрите логи pod: kubectl logs -n .
Проблемы сети Flannel — проверить логи flanneld и состояние интерфейсов, убедиться, что pod-network-cidr совпадает с конфигурацией Flannel.

Полезные команды для диагностики:

journalctl -u kubelet -b --no-pager | tail -n 200
journalctl -u containerd -b --no-pager | tail -n 200
kubectl describe pod  -n 
kubectl logs  -n 
ip a
ss -lntu | grep 6443

`Альтернативные подходы и заметки`

Container runtime: помимо containerd можно использовать CRI‑O или Docker (с cri‑dockerd). Выбор зависит от политики поддержки и совместимости.
CNI плагины: вместо Flannel можно использовать Calico, Cilium или другие (Calico даёт NetworkPolicy и более гибкую маршрутизацию).
HA control-plane: для production рекомендуется минимум 3 control-plane узла с внешним etcd (или stacked etcd) и балансировщиком.

Пример структуры для HA: у вас может быть отдельный L4/LB перед API‑серверами, и при отказе одного control‑plane трафик перенаправится на другие.

`Модель мышления и полезные эвристики`

Разделяйте подготовку ОС и установку Kubernetes: сначала стандартизируйте все узлы.
Всегда начните с проверки сетевой связности (ping, nc) между узлами.
Для поиска причин — логика: сервис не запущен → журналы systemd → логи компонента → конфигурации.
При ошибках join чаще всего проблема в токене/CA hash/порт 6443 или в неработающем containerd/kubelet.

`Сводка ключевых фактов`

API сервер Kubernetes слушает по TCP порт 6443.
По умолчанию Flannel использует pod network 10.244.0.0/16 (можно менять, но нужно согласовать с CNI).
kubeadm init генерирует токен для присоединения рабочих узлов; его можно воссоздать командой kubeadm token create –print-join-command.
SWAP должен быть отключён на всех узлах.

`Рекомендации по безопасности`

Храните /etc/kubernetes/admin.conf в защищённом месте; он содержит credentials для управления кластером.
В production включайте SELinux и адаптируйте политики, вместо постоянного permissive.
Настройте RBAC и используйте отдельные сервисные аккаунты с минимальными правами.
Ограничьте доступ к API серверу через firewall/WHITELIST и используйте сертификаты и TLS.
Регулярно обновляйте образы и применяйте сканирование уязвимостей в контейнерах.

`Совместимость и миграции`

Эта инструкция ориентирована на RHEL‑совместимые дистрибутивы (Rocky Linux). При миграции с CentOS или AlmaLinux отличия минимальны, но репозитории и пакеты проверяйте заранее.
При обновлении Kubernetes следуйте официальной матрице совместимости API и версий kubeadm/kubelet.

`Примерный план запуска в продакшен (высокоуровневый)`

Подготовить минимальный образ ОС и автоматизировать подготовку /etc/hosts, sysctl, отключение SWAP.
Настроить CI/CD для конфигурации контейнерного рантайма и Kubernetes пакетов.
Развернуть HA control-plane (3 узла) и настроить etcd бэкапы.
Настроить мониторинг и логирование (Prometheus, Grafana, EFK).
Включить политики безопасности (PodSecurity, NetworkPolicy, RBAC).

`Decision flowchart (простое решение Join или Init)`

flowchart TD
  A[Начало] --> B{Существующий кластер?}
  B -- Нет --> C[Инициализировать контрольную плоскость 'kubeadm init']
  B -- Да --> D[Получить команду join 'kubeadm token create --print-join-command']
  D --> E[Запустить kubeadm join на worker]
  C --> F[Скопировать kubeconfig и применить CNI]
  F --> E
  E --> G[Проверить узлы и поды]
  G --> H[Успех]

`Тестовые сценарии и критерии приёмки`

Проверка готовности узлов: kubectl get nodes — все Ready.
Создание nginx Deployment: pod запущен, service отвечает внутри кластера.
Проверка сетевой связанности между подами: запрос из pod в pod проходит.
Проверка resilience: перезапуск kubelet на worker не приводит к потере состояния pod (если сохранено на Volume).

`Короткое объявление для команды (100–200 слов)`

Мы развернули базовый Kubernetes кластер на Rocky Linux: один контрольный узел и два рабочих. В кластере используется runtime containerd и сетевой плагин Flannel. В ходе настройки выполнены: подготовка ОС (hosts, SELinux permissive, sysctl, отключение swap), установка runtime и kube пакетов, инициализация control-plane и подключение воркеров. Для проверки созданы системные pod (coredns, kube-proxy, flannel). Следующие шаги — настроить мониторинг, RBAC и выполнять развёртывание тестовых приложений. Инструкция содержит чек‑листы, план отката и рекомендации по безопасности.

`Заключение`

Вы развернули Kubernetes кластер на Rocky Linux с контейнерным рантаймом containerd и сетевым плагином Flannel. В руководстве представлены пошаговые команды, проверки, чек‑листы по ролям, типичные ошибки и план отката. Для production рекомендуется настроить HA control-plane, включить политики безопасности и внедрить мониторинг и бэкапы etcd.

Если нужна помощь с переходом на другой CNI, HA конфигурацией control-plane или с написанием Ansible playbook для автоматизации — могу помочь составить пошаговый план и шаблоны.

Развёртывание Kubernetes на Rocky Linux — пошаговый гайд