Добавление физического сервера в кластер Kubernetes раньше было цепочкой ручных действий: SSH, установка пакетов, настройка kubelet, добавление секретов, проверка, что узел появился

Добавление физического сервера в кластер Kubernetes раньше было цепочкой ручных действий: SSH, установка пакетов, настройка kubelet, добавление секретов, проверка, что узел появился. Теперь в Managed Service for Kubernetes появилась возможность подключать BareMetal-серверы одной кнопкой. В интерфейсе выбора группы узлов рядом с облачными и внешними группами появился пункт «BareMetal группа узлов». Это значит, что один кластер может объединять виртуальные машины, внешние серверы и физические серверы Yandex BareMetal. Такой гибридный подход закрывает сценарии, где виртуализация даёт слишком много ограничений, а полностью переезжать на «железо» нецелесообразно.

Kubernetes по своей сути — слой абстракции над инфраструктурой. Приложение работает с подами, запросами ресурсов и планировщиком, и ему в общем случае всё равно, где исполняется узел: на VM или на физическом сервере. Проблемы начинаются там, где важны физические свойства узла: задержка при обращении к диску, стабильность этой задержки, реальная NUMA-топология, прямой доступ к устройству. Для большинства типовых задач виртуальные машины остаются самым удобным и экономичным способом запускать Kubernetes. VM создаётся за минуты и так же быстро удаляется, на этом строится работа Cluster Autoscaler: узлы добавляются при всплеске трафика и сокращаются при снижении. Сбойный узел проще пересоздать, чем диагностировать: cordon, drain, delete — и через несколько минут в группе появляется новый из того же образа. Обновление Kubernetes в node group работает по тому же принципу.

Виртуальная машина позволяет подобрать размер узла под конкретную задачу, а не делить физический сервер на сто ядер между командами. Отказ узла в такой модели — штатное событие: платформа может перенести VM на другой хост, а если нет, Kubernetes перепланирует поды. Для CPU-bound-нагрузок накладные расходы аппаратной виртуализации составляют всего несколько процентов. Однако есть нюансы. Операции ввода-вывода и частые переключения контекста обходятся дороже, сетевой пакет или дисковый запрос проходят через дополнительные уровни обработки. Это может быть незаметно по средней пропускной способности, но проявляется в p99 и p99.9. Кроме того, VM делит с «шумными соседями» по хосту кеш последнего уровня, каналы памяти, PCIe и пропускную способность сетевой карты. Гипервизор не может полностью исключить влияние одной нагрузки на другую, поэтому p99 иногда меняется по причинам, которых нет в метриках самой VM.

Даже без конкуренции приложение не всегда видит реальную топологию оборудования. VM работает с NUMA-топологией, которую предоставляет гипервизор. СУБД и инференс-рантаймы, умеющие закреплять потоки за ядрами и размещать память с учётом NUMA, могут работать хуже ожидаемого. Хранилище в облаке обычно сетевое — данные не привязаны к конкретному хосту, том можно подключить к другой VM, но по профилю задержек он отличается от локального NVMe. Для обычного stateless-сервиса на Go или JVM эти эффекты часто несущественны, но при жёстких требованиях к задержкам или стабильности производительности их нужно учитывать.

Эластичность VM незаменима при неравномерной нагрузке и для временных сред: публичные сервисы с сезонными пиками, окружения для пулл-реквестов, CI, нагрузочные тесты. Это же удобно для компаний с большим числом автономных сервисов, где у разных команд разные требования к версиям ПО, размерам узлов и правам доступа. Если нет экспертизы по эксплуатации физических серверов — планированию ёмкости, обслуживанию, замене при отказах, — VM могут оказаться выгоднее по совокупной стоимости даже при более высокой цене vCPU.

BareMetal выбирают ради конкретных свойств оборудования: прямого доступа к устройствам, локальных дисков, стабильных задержек, высокой постоянной загрузки или изоляции на уровне хоста. GPU для обучения и инференса, FPGA, высокоскоростные NVMe, специализированные сетевые адаптеры можно использовать и в виртуальной среде, но конфигурация зависит от модели оборудования, драйверов и механизма проброса. Это усложняет миграцию VM, а часть возможностей устройства может быть недоступна. На физическом сервере драйвер работает с устройством напрямую, Kubernetes получает его через device plugin. Проще использовать RDMA, аппаратные функции сетевой карты и топологию соединений между ускорителями. То же касается нестандартного или сертифицированного оборудования, которого нет среди типов VM.

Распределённые СУБД — YDB, ClickHouse, Kafka, OpenSearch — обычно сами реплицируют данные, и им важнее быстрый локальный диск, чем дополнительный слой отказоустойчивости под системой. Локальный NVMe даёт высокие IOPS и низкую задержку, потому что нет сетевого пути до удалённого хранилища. Замена узла с терабайтами данных запускает ребалансировку и передачу данных между репликами, поэтому стабильный состав серверов позволяет делать это реже. Важно помнить: локальные диски не отменяют репликацию и резервное копирование, они ускоряют работу, но не заменяют план восстановления.

Для высоконагруженных Redis, Valkey, Memcached и CPU-bound-инференса критичен p99. На результат влияют процессорный кеш, NUMA-топология, конкуренция за ядра и обработка прерываний. На физическом сервере можно закреплять поды за ядрами, использовать статическую политику CPU Manager и hugepages, изолировать системные задачи и настраивать прерывания сетевой карты. В VM часть механизмов тоже доступна, но эффект зависит от того, как гипервизор представил гостевой ОС процессоры, память и NUMA-группы. Поэтому если в SLO есть p99 или p99.9, сравнивать VM и BareMetal лучше на реальном профиле запросов, а не по средней задержке.

BareMetal может быть дешевле при стабильной высокой загрузке. Базовую нагрузку, которая сохраняется ночью и в выходные, разумно разместить на физических серверах, а переменную часть оставить на VM. В расчёте нужно учитывать не только цену CPU и памяти, но и лицензии, эксплуатацию оборудования и системные компоненты Kubernetes — на небольших VM они занимают заметную долю ресурсов, на крупном сервере меньшую. Регуляторные требования или внутренняя политика безопасности иногда запрещают совместное размещение разных классов нагрузки на одном хосте, и BareMetal даёт выделенный сервер без соседних арендаторов. Но физическая изоляция не заменяет изоляцию внутри кластера: если один сервер используют несколько команд, всё равно нужны отдельные группы узлов, taints и tolerations, RBAC, NetworkPolicy и контроль доступа к секретам.

Попытка свести всю нагрузку к одному типу инфраструктуры означает переплату либо за постоянно простаивающие физические ресурсы, либо за облачную эластичность там, где она не нужна. Гибридный кластер решает эту дилемму. Физические серверы закрывают минимальный объём трафика и сохраняют высокую утилизацию, а облачная группа узлов с автомасштабированием берёт на себя кратковременные пики — распродажи, эфиры, массовые рассылки. Чтобы направлять поды в нужные группы, используют node affinity, taints и tolerations, приоритеты подов и правила размещения. Например, ClickHouse, Kafka или YDB работают на серверах с локальными NVMe, а API-шлюзы, воркеры предобработки, cron-задачи и дашборды — на виртуальных машинах. По тому же принципу строят инференс: GPU-серверы обслуживают модель, а очередь, валидация запросов, кеш и постобработка не занимают ускорители.

Гибридный подход удобен для постепенного переноса сервисов в облако. Собственные серверы компании включаются в общий Kubernetes-контур: существующие нагрузки остаются на железе, новые запускаются на облачных узлах. Это проще, чем переезжать всем одновременно и перестраивать процессы эксплуатации. Тот же принцип работает для сред: тестовые — на VM, рабочие — на физических серверах. Версия Kubernetes, манифесты и системные компоненты остаются общими, различаются только типы групп узлов и правила размещения.

Важно понимать: гибридный кластер не распределяет поды между VM и BareMetal автоматически. Нужно использовать обычные механизмы Kubernetes. Сначала группы узлов размечают по значимым признакам: тип инфраструктуры, наличие локальных NVMe, модель GPU, зона доступности. Схему меток лучше определить заранее — на неё будут опираться правила планирования. Дефицитные ресурсы защищают через taints: узлы с GPU, локальными дисками или специализированными сетевыми картами получают taint, чтобы Kubernetes не разместил там обычный сервис из-за свободных CPU и памяти. Для рабочих нагрузок требования задают через affinity и anti-affinity: одному поду нужен узел с локальным NVMe, реплики базы не должны оказаться на одном сервере. Это особенно важно для крупных физических узлов — один такой сервер может нести нагрузку нескольких VM, поэтому распределение реплик и допустимое число одновременно недоступных подов задают явно через topology spread и PodDisruptionBudget.

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

Гибридный кластер — это не способ сэкономить на всём сразу, а возможность выбрать правильный инструмент для каждой части системы. Там, где нужна эластичность, — виртуальные машины. Там, где критичны задержки, прямой доступ к оборудованию или изоляция, — физические серверы. А одна кнопка для подключения BareMetal убирает ручную рутину и позволяет строить такую архитектуру без боли.

Какие сценарии в вашей инфраструктуре вы бы перевели на гибридную схему — или уже используете похожий подход? Поделитесь опытом в комментариях.

Телеграм: t.me/ainewsline

Источник: vk.com

Комментарии: