Ноды висят в NotReady из-за CNI
CNI поднимается, но не получает IP из подсети. Обычно дело в конфликте CIDR между pod-network и host-интерфейсом. Сравниваем диапазоны и убираем пересечение.
Практическое руководство по сборке и настройке кластера Kubernetes. Разбираем полный цикл — от проверки железа и сети до типовых ловушек, которые ловят 90% команд на первых неделях эксплуатации.
Этот гид написан как живой документ: мы описываем ровно тот путь, по которому сама редакция SyncTly поднимает тестовые и боевые кластеры. Никакой магии и «а теперь просто доверьтесь». Каждый шаг проверяем на чистой среде, фиксируем версии и показываем, на чём именно всё ломается.
Перед вами три блока: пререквизиты, пошаговая инсталляция и список типичных ошибок. Рекомендую пройти их по порядку — так вы не потеряетесь на середине и не упрётесь в проблему, решение которой уже описано ниже.
Прежде чем запускать kubeadm init, убедитесь, что фундамент в порядке. Почти половина «странного поведения» кластера на самом деле — это проблемы, которые затащили сюда ещё до установки.
Операционная система и ядро. Мы работаем на Ubuntu 22.04 LTS с ядром не старше 5.15. Отключите swap — Kubernetes по умолчанию отказывается поднимать ноды, если он включён. Проверьте, что модули br_netfilter и overlay загружены в ядро, иначе не запустится CNI.
Сеть и DNS. Для каждого узла должен быть резолвящийся hostname. Убедитесь, что на всех нодах одинаково настроено NTP — рассинхрон часов на несколько секунд ломает TLS-руки и приводит к циклу пересоздания сертификатов. Проверьте доступность портов 6443 (API), 10250 (kubelet) и диапазона подсетей под контейнеры.
Версии и инструменты. Зафиксируйте одну версию Kubernetes для всех узлов — мы держим 1.29.x. Установите kubeadm, kubelet и kubectl одной версии, чтобы не ловить ошибки несовместимости. Настройте локальный реестр или доступ к image, иначе pull-запросы будут тянуться к публичным хостам и тормозить деплой.
Собираем кластер через kubeadm в три акта: инициализация контроллера, подключение воркеров и установка CNI. Ниже — точные команды и что проверить после каждого этапа.
1. Инициализация контроллера. Запустите kubeadm init --control-plane-endpoint с явным IP или доменом балансировщика. Укажите --pod-network-cidr под выбранный CNI (для Calico — 192.168.0.0/16). После завершения скопируйте строку kubectl config из вывода и сохраните её в ~/.kube/config.
2. Установка CNI. Не переходите к следующему шагу, пока kubectl get nodes не покажет статус NotReady из-за отсутствия сети — это нормально. Примените манифест Calico или Cilium. Через 30–60 секунд ноды должны переключиться в Ready.
3. Подключение воркеров. На каждом рабочем узле выполните kubeadm join с токеном из шага инициализации. Проверьте, что kubelet подхватил конфиг и что kubectl describe node показывает корректные capacity и allocatable ресурсы.
4. Базовая наблюдаемость. Установите метрики-агент и настройте Ingress-контроллер. Без Ingress у вас нет единой точки входа для сервисов, а без метрик — понимания, что происходит под нагрузкой. Это минимальный набор, с которого мы всегда стартуем.
Собрать кластер — это половина дела. Ниже — те места, где команды чаще всего теряют дни отладки. Каждая карточка — реальная ситуация из практики.
CNI поднимается, но не получает IP из подсети. Обычно дело в конфликте CIDR между pod-network и host-интерфейсом. Сравниваем диапазоны и убираем пересечение.
API-сервер бесконечно переиздаёт сертификаты из-за рассинхрона NTP. Проверяем drift часов на всех нодах и фиксируем источник времени на одном NTP-сервере.
Контейнер падает на старте. 90% — неверные limits/requests или отсутствие ConfigMap. Читаем kubectl describe pod и логи событий, а не гадает вслепую.
ServiceAccount получает cluster-admin «чтобы заработало». Разбираем принцип минимальных привилегий и как сузить роли без остановки продакшена.
Pod не может получить томовый том, потому что StorageClass не определён или provisioner не установлен. Проверяем классы и права на создание томов.
Под нагрузкой кластер начинает «глотать» запросы. Разбираем, как выстроить приоритеты, настроить QoS и не допустить деградации из-за жёстких limits.
Подпишитесь, и мы будем присылать новые гиды и постмортемы из мира Kubernetes и облачной архитектуры. Без спама, отписка в один клик.