Постоянная нагрузка остаётся на своих серверах, а пиковая уходит в облако. На схеме всё просто. В закупке первым ограничением окажется не процессор, а сеть между площадками.

Deckhouse Kubernetes Platform умеет расширять статический кластер узлами OpenStack, Yandex Cloud и VMware vCloud Director. Но серверы, облако и сеть придётся считать как одну систему. Иначе локальное железо пройдёт проверку по CPU и памяти, а облачные узлы не войдут в кластер.

Соглашение между X‑Com и Deckhouse в доступных материалах не подтверждено. Не описаны ни состав предложения, ни ответственность сторон. Поэтому ниже — техническая часть проекта по документации Deckhouse, а не условия партнёрства.

Что здесь называют гибридным кластером

Базовую нагрузку несут статические узлы на локальных серверах. Когда вычислительной мощности не хватает, Deckhouse добавляет облачные узлы и управляет ими вместе с локальными.

Платформа поддерживает автоскейлинг, наблюдаемость и средства безопасности. Это сокращает различия между двумя площадками на уровне Kubernetes, но не отменяет различий в сети, хранении и правах доступа.

Само железо — лишь часть закупки. До запроса коммерческого предложения нужно связать стойки, питание, IP-адреса и сетевые подключения. Такой предварительный учёт разобран в материале о том, как проверить размещение и подключения сервера до закупки.

Облачную площадку выбирают вместе с сетью

Для OpenStack и VMware vCloud Director документация Deckhouse требует L2-связность между узлами. Они должны находиться в одном канальном сегменте, даже если физически стоят на разных площадках.

Yandex Cloud допускает связь на уровне L2 или L3. Во втором случае потребуются доступ между сетями, открытые порты и VXLAN — наложенная сеть между узлами Kubernetes. Если служба безопасности не пропустит нужный трафик, смена серверов проблему не исправит.

У каждого варианта остаются свои условия:

В OpenStack заранее выбирают тип облачных томов и соответствующий StorageClass. Тип хранилища влияет на то, где окажутся постоянные данные облачных узлов.
В Yandex Cloud задают подсети, маршруты и диапазон адресов узлов. Сервисному аккаунту нужны роли editor и vpc.admin.
В VMware vCloud Director арендатору выделяют вычислительные ресурсы, сеть с DHCP и профиль хранения. Для управления требуется учётная запись с правами администратора VCD.

Поэтому в предложении интегратора должны быть не только CPU, память и диски. Нужны схема L2/L3, постоянные IP-адреса, доступ master-узлов к NTP, маршрут к registry.deckhouse.io или его зеркалу, облачные квоты и права сервисных аккаунтов.

Нижняя граница локальной части — 36 CPU и 84 ГБ памяти

Для предварительного расчёта возьмём производственный каркас из трёх master-узлов и трёх worker-узлов. Ресурсы бизнес-приложений пока не учитываем.

Руководство Deckhouse по подбору ресурсов задаёт для производственного master-узла 8 CPU, 16 ГБ памяти и диск 60 ГБ. Worker-узлу нужны 4 CPU, 12 ГБ и такой же диск.

Получается:

master-узлы: 3 × 8 CPU = 24 CPU, 3 × 16 ГБ = 48 ГБ;
worker-узлы: 3 × 4 CPU = 12 CPU, 3 × 12 ГБ = 36 ГБ;
всего: 36 CPU, 84 ГБ памяти и 6 × 60 ГБ = 360 ГБ дискового пространства.

Это ресурсы платформы, а не всей системы. Базы данных, очереди, веб-сервисы и другие приложения добавляются сверху. Сюда же нужно добавить резерв на отказ физического хоста и расходы гипервизора, если узлы работают в виртуальных машинах.

Все узлы должны использовать архитектуру x86_64 и постоянные IP-адреса. Документация Deckhouse требует от дисков не менее 400 IOPS. Узлы одного типа должны иметь одинаковую аппаратную конфигурацию.

Одноузловая установка требует не менее 16 CPU, 32 ГБ памяти и диска 100 ГБ. Для стенда этого достаточно. Производственную управляющую часть из трёх master-узлов такой сервер не заменяет.

Спецификация под задачу

Соберём стартовую локальную платформу на трёх физических серверах. Допущение такое: на каждом хосте работает один master и один worker. Нагрузку приложений разложим позже, когда появятся её замеры.

Без резерва один хост потребляет 12 CPU и 28 ГБ памяти. Чтобы после отказа одного сервера два оставшихся приняли все шесть узлов, каждому нужно по 18 CPU и 42 ГБ. Добавим на каждом хосте 4 ядра и 8 ГБ для гипервизора: нижняя граница вырастет до 22 физических ядер и 50 ГБ памяти.

Для предварительного расчёта поставщику можно отдать такую конфигурацию:

Компонент	Стартовая спецификация	Почему столько
Серверы	3 одинаковых узла	На каждом размещаем один master и один worker; три master соответствуют типовой схеме Deckhouse
Процессор	24 физических ядра x86_64 на узел	18 ядер покрывают платформу после отказа одного хоста, 4 оставляем гипервизору, ещё 2 — небольшой запас
Частота	Не фиксировать до расчёта приложений	Deckhouse задаёт число CPU, но не нижнюю частоту; её определит профиль бизнес-нагрузки
Память	64 ГБ ECC RDIMM на узел	После отказа одного хоста нужно 42 ГБ платформе и 8 ГБ гипервизору; остаётся 14 ГБ запаса
Системные диски	2 SSD по 480 ГБ в RAID1	На один хост приходится минимум 120 ГБ под два узла; зеркало переживёт отказ одного диска
Производительность дисков	От 400 IOPS для каждого узла	Это нижнее требование руководства Deckhouse; проверять нужно на собранном массиве
Сеть	2 порта 10 Гбит/с на узел	Это проектное допущение: один путь можно выделить под служебный трафик, второй оставить для резерва или данных
Питание	2 блока питания на сервер	Проектное требование для обслуживания одного ввода без остановки хоста
Корпус	2U, не меньше двух отсеков под SSD и свободные слоты PCIe	Такой формат оставляет место для сетевых карт и дальнейшего расширения

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

Если приложения требуют ещё 24 CPU и 96 ГБ памяти, эти ресурсы тоже нужно сохранить после отказа хоста. Тогда на каждый из трёх серверов приходится добавить по 12 CPU и 48 ГБ: два оставшихся узла совместно дадут нужные 24 CPU и 96 ГБ. Стартовая конфигурация вырастет до 36 физических ядер и 128 ГБ ECC на сервер.

Диски приложений лучше считать отдельно от системных. Если виртуальные машины должны хранить данные на локальных накопителях нескольких хостов, пригодится разбор виртуальных СХД для гипервизора: там выбор зависит не только от объёма, но и от отказоустойчивости и записи между узлами.

Компромисс у схемы прямой. Три сервера с запасом под отказ стоят дороже двух. Зато при остановке одного хоста кластер не требует срочной разгрузки. Два сервера дешевле, но вывод одного из них сразу превращает плановое обслуживание в работу без резерва.

Что должно быть в предложении X‑Com

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

В расчёте должны стоять две независимые строки: ресурсы Deckhouse и ресурсы приложений. Если поставщик свёл их в одну сумму, проверить запас после отказа хоста не получится.

Попроси зафиксировать выбранную интеграцию:

OpenStack или vCloud Director — с L2-связностью, типом облачного хранения и выделенными ресурсами;
Yandex Cloud — с L2- либо L3-связностью, VXLAN, подсетями, портами и правами сервисного аккаунта.

Нужен и документ с границами ответственности: кто поставляет серверы, проектирует сеть, выдаёт подписку Deckhouse EE, переносит нагрузки и принимает обращения после запуска. Доступные материалы этого не раскрывают. До пресс-релиза X‑Com или Deckhouse приписывать эти обязанности одной из компаний нельзя.

На предварительный расчёт уже можно передать три сервера по 24 физических ядра, 64 ГБ ECC и два SSD по 480 ГБ в RAID1. Но в закупку такую спецификацию отправляют лишь после двух проверок: интегратор показал связность с выбранным облаком и отдельно посчитал ресурсы приложений с сохранением нагрузки при отказе одного хоста.