Одна «кнопка» для гибридного Kubernetes: рассказываем, для каких сценариев она нужна

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

Привет, Хабр! Меня зовут Андрей Волков, я руководитель SRE в команде Managed Service for Kubernetes в Yandex Cloud. Мы добавили возможность подключать BareMetal-серверы в кластер Kubernetes одной кнопкой.

С точки зрения интерфейса новая фича выглядит так: в выпадающем списке c пунктами «облачная группа узлов» и «внешняя группа узлов» появился ещё один — «BareMetal группа узлов». Теперь кластеры Kubernetes в Yandex Cloud могут состоять из виртуальных машин, внешних серверов и серверов Yandex BareMetal. В статье расскажу, для каких сценариев лучше использовать виртуальные машины, а для каких — физические серверы. 

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

Ограничения проявляются, когда для приложения важны физические свойства узла: задержка при обращении к диску, её стабильность между запросами, реальная NUMA-топология, прямой доступ к устройству без виртуального слоя.

При отсутствии таких требований Kubernetes обычно проще и выгоднее развернуть на виртуальных машинах. Но для части нагрузок виртуализация добавляет слишком много ограничений или накладных расходов. Тогда разработчики выбирают между BareMetal и гибридной схемой.

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

Что даёт виртуализация и какая цена её использования

Начнём с преимуществ виртуальных машин. Хотя дальше речь пойдёт о физических серверах, для большинства задач VM остаются основным и наиболее удобным способом запускать Kubernetes.

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

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

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

Цена этой гибкости

Для типичных вычислительных задач накладные расходы виртуализации невысокие: аппаратная виртуализация добавляет лишь несколько процентов к CPU-bound-нагрузке. Однако влияние распределено неравномерно. Операции ввода-вывода и частые переключения контекста обходятся дороже, чем вычисления в памяти. Сетевой пакет или дисковый запрос проходят через дополнительные уровни обработки. Это может быть незаметно по средней пропускной способности, но может проявиться в p99 и p99.9 задержки.

Дополнительные уровни обработки не единственная причина роста задержек. Виртуальная машина делит с «шумными соседями» по хосту кеш последнего уровня, каналы памяти, PCIe и пропускную способность сетевой карты. Гипервизор распределяет процессорное время, но не может полностью исключить влияние одной нагрузки на кеш и память другой. Поэтому p99 иногда меняется по причинам, которых нет в метриках самой VM.

Но даже при отсутствии заметной конкуренции приложение не всегда видит устройство узла таким, какое оно есть. Виртуальная машина работает с NUMA-топологией, которую предоставляет гипервизор. СУБД и некоторые инференс-рантаймы умеют закреплять потоки за ядрами и размещать память с учётом NUMA. Когда виртуальная топология отличается от физической, оптимизации могут работать хуже ожидаемого.

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

Для обычного stateless-сервиса на Go или JVM перечисленные эффекты часто остаются ниже порога чувствительности. Но их важно учитывать, когда у нагрузки жёсткие требования к задержкам, стабильности производительности или прямому доступу к оборудованию.

Когда виртуальные машины — правильный выбор

Эластичность VM полезна при неравномерной нагрузке и для временных сред. Это публичные сервисы с сезонными пиками, окружения для пулл-реквестов, CI и нагрузочных тестов. Их можно быстро развернуть, а после работы удалить. Та же логика действует для stateless-сервисов: при проблемах узел проще заменить, чем ремонтировать.

Виртуальные машины удобны для компаний с большим числом автономных сервисов. У разных команд могут отличаться требования к версиям ПО, размеру узлов, процессорам и правам доступа. Группы виртуальных машин позволяют разделить такие нагрузки без закрепления отдельного физического сервера за каждой командой.

Выбор зависит и от того, кто будет эксплуатировать инфраструктуру. Физические серверы нужно планировать по ёмкости, обслуживать и заменять при отказах. Когда нужной экспертизы нет, VM могут оказаться выгоднее по совокупной стоимости, даже при более высокой цене vCPU.

Когда нужны физические серверы

BareMetal используют ради конкретных свойств оборудования: прямого доступа к устройствам, локальных дисков, стабильных задержек, высокой постоянной загрузки или изоляции на уровне хоста.

Прямой доступ к устройствам

GPU для обучения и инференса, FPGA, высокоскоростные NVMe и специализированные сетевые адаптеры можно использовать и в виртуальной среде. Но конфигурация зависит от модели оборудования, драйверов и механизма проброса. Она усложняет миграцию VM, а отдельные возможности устройства могут потребовать дополнительной настройки или оказаться недоступными.

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

Stateful-системы с локальными NVMe

YDB, ClickHouse, Kafka, OpenSearch и другие распределённые СУБД обычно сами реплицируют данные. Им часто важнее быстрый локальный диск, чем дополнительный слой отказоустойчивости под системой.

Локальный NVMe даёт высокие IOPS и низкую задержку: при обращении к данным нет сетевого пути до удалённого блочного хранилища. Кроме того, замена узла с терабайтами данных запускает ребалансировку и передачу данных между репликами. Стабильный состав серверов позволяет делать это реже.

Локальные диски не отменяют репликацию и резервное копирование. Они ускоряют работу с данными, но не заменяют план восстановления после отказа узла или площадки.

Низкие и стабильные задержки

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

На физическом сервере можно закреплять поды за ядрами, использовать статическую политику CPU Manager и hugepages, изолировать системные задачи и настроить прерывания сетевой карты. Эти настройки работают лучше, когда ОС видит реальную топологию оборудования. В VM часть механизмов тоже доступна, но эффект зависит от того, как гипервизор представил гостевой ОС процессоры, память и NUMA-группы.

Если в SLO есть p99 или p99.9, сравнивать VM и BareMetal лучше на реальном профиле запросов, а не по средней задержке и пропускной способности.

Постоянная нагрузка

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

В расчёте стоит учитывать не только цену CPU и памяти. На стоимость влияют лицензии, эксплуатация оборудования и системные компоненты Kubernetes. На небольших VM они занимают заметную долю ресурсов, на крупном сервере меньшую.

Изоляция на уровне хоста

Регуляторные требования, договорные условия или внутренняя политика безопасности иногда могут запрещать совместное размещение разных классов нагрузки на одном хосте. BareMetal же даёт выделенный сервер без соседних арендаторов.

При этом физическая изоляция не заменяет изоляцию внутри кластера. Если один сервер используют несколько команд или сред, всё равно нужны отдельные группы узлов, taints и tolerations, RBAC, NetworkPolicy, политики безопасности и контроль доступа к секретам.

Гибридный кластер: разделить нагрузки по требованиям

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

Постоянная нагрузка на BareMetal, пики на VM 

Физические серверы закрывают минимальный объём трафика и сохраняют высокую утилизацию. Облачная группа узлов с автомасштабированием берёт на себя кратковременные пики: во время распродаж, эфиров или массовых рассылок. Чтобы направить поды в нужную группу, используют node affinity, taints и tolerations, приоритеты подов и правила размещения.

Stateful- и GPU-нагрузки на BareMetal, обвязка на VM

ClickHouse, Kafka или YDB могут работать на серверах с локальными NVMe, а API-шлюзы, воркеры предобработки, cron-задачи и дашборды — на виртуальных машинах. По тому же принципу строят инференс: GPU-серверы обслуживают модель, а очередь, валидация запросов, кеш и постобработка не занимают ускорители.

Постепенная миграция в облако и разделение сред

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

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

Как размещать нагрузки в гибридном кластере

Гибридный кластер не распределяет поды между VM и BareMetal автоматически. Для этого используют обычные механизмы Kubernetes: метки, taints и tolerations, affinity, правила распределения реплик и StorageClass.

Сначала группы узлов размечают по значимым признакам: тип инфраструктуры, наличие локальных NVMe, модель GPU, зона доступности. Схему меток лучше определить заранее: на эти метки будут опираться правила планирования. 

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

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

Что касается автомасштабирования, то число облачных узлов меняется по нагрузке, а BareMetal формирует заранее рассчитанную ёмкость.. Нагрузку, которая должна быстро расти по метрикам, не стоит жёстко закреплять за физическими узлами.

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

Что меняется с BareMetal-группами узлов

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

Но ручные операции приводят к расхождениям в конфигурации между узлами. Через несколько месяцев узлы, которые в разное время подключали разные инженеры, начинают различаться настройками. Рано или поздно одно из таких различий проявляется инцидентом, который воспроизводится только на одном сервере. Дальше — обновление версии Kubernetes и повторение всего цикла вручную с тем же результатом.

Ключевое отличие нового подхода, реализованного, как BareMetal Extend: Managed Service for Kubernetes® — автоматическая настройка. Теперь физический сервер добавляется в кластер так же, как добавляется группа виртуальных машин: выбором пункта в выпадающем списке. BareMetal-группа узлов становится обычным объектом управления вместе с облачной и внешней группами. Кластер получает один пульт управления на всю разнородную инфраструктуру: одна версия Kubernetes на кластер, централизованные обновления, единый способ создавать и выводить узлы независимо от того, виртуальные они или физические.

Клиенты, использующие гибридный IaC, раньше поддерживали два процесса: отдельную структуру управления для on-premises-инфраструктуры и облачный контур. Интеграция в managed Kubernetes позволяет управлять железом как обычной группой узлов — жизненный цикл берёт на себя control plane. В итоге появляется единый уровень инфраструктурной абстракции для гибридных нагрузок и возможность постепенной миграции.

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

Ограничения гибридного кластера

Гибридный кластер снимает часть проблем, но добавляет новые. Их немного, но лучше знать о них заранее.

Ёмкость физических серверов нельзя нарастить так же быстро, как облачных. Её нужно заранее рассчитывать с учётом сезонности, ожидаемого роста и резерва на отказ. «Дозакажем, когда упрёмся» здесь не работает. Отчасти поэтому отказ физического узла заметнее, чем отказ VM, потому что обычно он крупнее и несёт больше нагрузки. Нужны либо резервная ёмкость в пуле BareMetal, либо заранее подготовленный перенос нагрузки на облачные узлы. Во втором случае облачная часть кластера становится резервом для совместимых сервисов. При обслуживании такого узла drain занимает больше времени, а доступная ёмкость заметно снижается. Отсюда внимание к бюджетам недоступности и к распределению реплик.

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

Преимущество BareMetal почти всегда относится к конкретной части системы, а не ко всему кластеру. Удачный бенчмарк не означает, что на физические серверы стоит переносить все сервисы. Stateless-компоненты редко получают от этого заметную выгоду, но теряют эластичность. Мощности под пиковую нагрузку придётся держать постоянно.

Вместо заключения

Новая фича сводится к одному пункту в выпадающем списке. За ним скрываются подготовка сервера и его жизненный цикл в кластере, но пользователю достаточно выбрать нужный тип группы узлов.

Выбор между виртуальными машинами и BareMetal остаётся: универсального варианта нет. Но теперь не нужно выбирать один тип инфраструктуры для всего кластера. Каждую группу узлов можно подобрать под требования конкретной нагрузки.

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