Как подготовить bare metal к установке Kubernetes-платформы

Готовая Kubernetes-платформа с managed PostgreSQL, Kafka, ClickHouse и мониторингом заметно сокращает объём ручной сборки. Но на собственных серверах основная сложность остаётся в фундаменте: адресации, DNS, доступе в сеть, времени и дисках. Ошибка в одном из этих слоёв часто проявляется только в середине установки — когда контроллеры и системные сервисы уже пытаются общаться друг с другом.

Ниже — последовательность подготовки кластера из трёх combined-узлов, где control plane и рабочая нагрузка живут на одних машинах. Подход подходит для закрытого контура или арендованного bare metal и помогает заранее проверить самые уязвимые места.

Сначала определить границы платформы

Такой кластер оправдан, когда приложения и данные должны остаться в собственном периметре, а команде нужны типовые сервисы поверх Kubernetes. Минимальная конфигурация из трёх узлов даёт отказоустойчивый control plane и позволяет разместить распределённое хранилище.

Для combined-узла стоит закладывать 32 vCPU, 64 ГБ памяти и два SSD ёмкостью от 100 ГБ. Для тестового стенда процессор и память иногда можно уменьшить, однако второй диск нужен и там: установочный диск и диск данных выполняют разные роли. Отдельно потребуется небольшой бастион с Ubuntu, доступный администраторам и кластеру.

До начала работ составьте таблицу с адресами, MAC-адресами и назначением всех машин. Она понадобится при описании хостов и заметно снижает риск перепутать интерфейсы во время загрузки по ISO.

Разделить сеть до установки

Нодам требуется L2-связность в приватной подсети. Удобный вариант — выделить отдельный VRF и сеть /24, а затем заранее разложить её на диапазоны:

• первую половину адресов отдать хостам, бастиону и служебному VIP Kubernetes API;
• вторую половину зарезервировать для LoadBalancer в режиме Cilium L2;
• Pod CIDR и Service CIDR вынести в непересекающиеся приватные диапазоны.

Например, в сети 10.0.0.0/24 узлы могут занять адреса 10.0.0.4–10.0.0.6, бастион — 10.0.0.3, а API VIP — 10.0.0.127. Диапазон 10.0.0.128/25 остаётся свободным для сервисных IP балансировщика. Пересечение адреса ноды с пулом LoadBalancer приведёт к труднообъяснимым сетевым сбоям уже после запуска кластера.

Бастиону нужен выход в интернет и доступ к приватной сети, а узлам публичные адреса обычно не требуются. Он становится точкой входа для VPN, запуска установщика, DNS и синхронизации времени. Для исходящего трафика нод на нём настраивается NAT, например правилом MASQUERADE для подсети кластера.

DNS и время — часть критического пути

Внутренний DNS лучше поднять на бастионе до загрузки первой ноды. Он должен отвечать за имена хостов, домен кластера и записи сервисов хранилища. В BIND для этого задают зону с именами нод и отдельные A-записи для ydb-storage-0, ydb-storage-1 и ydb-storage-2.

Одних имён node1, node2 и node3 недостаточно. Компоненты платформы обращаются к сервисным именам хранилища; если они не резолвятся, установка может остановиться на запуске IAM или YDB. Перед install стоит проверить ответы напрямую:

dig @10.0.0.3 node1.baremetal.internal
dig @10.0.0.3 ydb-storage-0.baremetal.internal

В правилах межсетевого экрана нужно разрешить DNS не только сети узлов, но и Pod CIDR. Иначе CoreDNS не сможет обратиться к BIND, хотя проверка с бастиона будет успешной. Типичный симптом — тайм-аут подключения к 53-му порту в логах DNS и зависшие задания хранилища.

На том же бастионе настройте Chrony. Узлам разрешается синхронизировать время с его адресом, а этот адрес затем указывается в параметрах timeservers. Единое время важно для сертификатов, журналов и корректной работы распределённых компонентов.

Подготовить носители и загрузку нод

Каждый сервер загружается с ISO платформы через IPMI или iKVM. До этого полезно проверить модель и порядок дисков в консоли обслуживания: на bare metal это обычно /dev/sda и /dev/sdb, тогда как конфигурации виртуальных машин нередко используют /dev/vda.

В конфигурации кластера явно задаются оба устройства: installDisk для системы и dataDisk для данных. Отсутствующий или ошибочно выбранный data-диск не даст поднять storage pool; в диагностике могут появиться ошибки загрузки storage-компонентов.

При первичной загрузке каждой ноды задаются hostname, IP, шлюз и интерфейс. MAC-адрес интерфейса надо сохранить в списке хостов: установщик сможет сопоставить описание узла с реальной машиной. На время установки полезно держать открытыми iKVM-консоли всех трёх серверов — сетевые проблемы Talos инициализируются раньше, чем станут доступны привычные средства Kubernetes.

Описать кластер и проверить конфигурацию

В конфигурации понадобятся четыре группы параметров:

1. Сеть хостов, Pod CIDR, Service CIDR и пул LoadBalancer.
2. VIP адрес Kubernetes API и базовый домен кластера.
3. Резолвер и сервер времени на бастионе.
4. Роли узлов, MAC-адреса, IP и два физических диска.

Адрес шлюза для нод может указывать на бастион, если именно он выполняет NAT. В файл с секретами не следует помещать его в Git: лицензии, пароли и ключи должны храниться отдельно от описания инфраструктуры.

Перед установкой конфигурацию необходимо валидировать штатной командой дистрибутива. Это подходящий момент, чтобы исправить синтаксис YAML, дубли IP и имена интерфейсов, не тратя время на откат частично установленного кластера.

Контролировать установку по слоям

После запуска install порядок проверок важнее ожидания фиксированного времени. Сначала убедитесь, что доступны все три ноды. Затем проверьте kubeconfig, внутреннее DNS-имя системного сервиса и метрики узлов. Когда kubectl get nodes показывает три состояния Ready, в Grafana есть метрики всех серверов, а компоненты платформы имеют статус Ready, базовая установка завершена.

Если развертывание остановилось на IAM или storage, диагностику стоит начинать с трёх вопросов:

• резолвятся ли ydb-storage-* с DNS-бастиона;
• разрешён ли трафик Pod CIDR к 53-му порту;
• задан ли доступный второй диск данных.

Логи CoreDNS и storage-подов быстро покажут, в каком из этих слоёв возник разрыв. Проверка DNS до запуска и явная разметка дисков устраняют большую часть таких инцидентов.

Что даёт эта подготовка

После успешной установки платформа предоставляет Kubernetes, ingress, мониторинг, журналы, управление секретами, политики и L2-балансировщик. Поверх этой основы можно создавать managed-кластеры PostgreSQL, Kafka или ClickHouse с параметрами ресурсов, репликации и хранилища из консоли.

Надёжность здесь начинается до первого запуска установщика. Изолированная сеть, корректный NAT, доступный DNS для pod-сети, синхронизация времени и выделенный data-диск превращают установку из долгого поиска причин в воспроизводимую процедуру.