Привет, Хабр! Сегодня у меня для вас отличные новости. В последние несколько лет мы во «Фланте» внимательно следили за технологиями‑лидерами в cloud‑native. Но это вовсе не праздное любопытство: из них мы собрали кое‑что интересное и теперь готовы представить вам. Речь о новой системе виртуализации, которая появилась в сегодняшнем релизе Deckhouse v1.43.
Для начала давайте разберемся, зачем понадобилась ещё одна система виртуализации, когда рынок наводнен ими настолько, что порой бывает сложно сориентироваться. Дело в принципиально новом подходе. Идея гиперконвергентной виртуальной инфраструктуры на базе Kubernetes не нова, однако пока на рынке нет решений которые реализовали бы эту идею в полной мере. Такие решения оставляют за собой право так или иначе отходить от некоторых принципов, которые подарил нам Kubernetes.
Выпуская платформу виртуализации, каждый производитель ориентируется прежде всего на свои нужды. Мы — не исключение, поэтому пара слов о наших целях и потребностях:
Удобный интерфейс. В первую очередь нам хотелось предоставить максимально простой и понятный интерфейс пользователям Deckhouse.
Управление из Kubernetes. Как крупнейшие K8s adopter'ы на российском рынке, мы стремились сделать управление платформой виртуализации частью оркестратора. Другими словами, платформа виртуализации должна расширять и дополнять стандартный API Kubernetes, чтобы управление виртуальными машинами было таким же простым, как управление другими рабочими нагрузками в кластере.
Максимальная производительность при минимальном потреблении ресурсов. Перед тем, как выбирать ту или иную технологию, мы проводили нагрузочное тестирование и делились его результатами с общественностью. Выбранные технологии, на наш взгляд, — лучшие из тех, что есть на рынке, и реальные тесты это доказывают.
О каких технологиях идёт речь
Kubernetes
Сегодня Kubernetes — де‑факто стандарт доставки и развертывания рабочих нагрузок на production‑серверах. Оно и понятно: удобный и легко расширяемый API, логика контроллеров и reconcile'а, а также новомодные DevOps‑практики помогают разрабатывать приложения максимально быстро и эффективно. Kubernetes закрывает кучу проблем в области наблюдаемости (observability), обнаружения сервисов, унификации и контроля за безопасностью приложения. Не удивительно, что Kubernetes взяли в оборот и крупные вендоры, и небольшие предприятия. Он сильно упростил проектирование и управление приложениями, а также повысил стабильность их работы.
Cilium
Для сетевого взаимодействия мы решили полностью положиться на Cilium. Это мощная SDN (Software Defined Network), которая базируется на стеке eBPF — ультрабыстрой технологии в ядре Linux. Cilium может работать как распределенный сетевой балансировщик, распределенный файрвол; обеспечивает хорошую наблюдаемость (observability) и предлагает множество других полезных функций.
Наша виртуализация переиспользует возможности Cilium в полной мере. Их поддержка потребовала небольших правок в коде проекта. Жёстко завязавшись на Cilium, мы можем гарантировать исправную и стабильную работу сети и для Pod'ов, и для виртуальных машин.
У нас Cilium работает во многих кластерах; самый крупный насчитывает более 180+ узлов, 12 000+ подов и 6000+ сервисов. Опыт эксплуатации, накопленный «Флантом», говорит о надежности этого решения. Cilium прекрасно справляется с ответственными задачами в production.
LINSTOR
LINSTOR — блочное SDS (Software Defined Storage). Базируется на проверенных временем технологиях и позволяет организовать надёжное хранилище для дисков виртуальных машин. Для создания томов используется менеджер логических томов LVM или ZFS, а технология DRBD обеспечивает их репликацию между физическими серверами. Модуль DRBD уже 10 лет в составе «ванильного» Linux; он зарекомендовал себя как самое быстрое отказоустойчивое решение, работающее на уровне ядра.
Хотя LINSTOR — необязательный компонент для запуска виртуальных машин, модуль виртуализации требовал надёжного и быстрого хранилища, которое бы шло в комплекте с платформой. Мы протестировали разные виды хранилищ и поняли, что LINSTOR лучше всего подходит для нужд виртуализации. На его основе мы сделали отдельный модуль Deckhouse, который можно использовать как для виртуальных машин, так и для классических контейнеров.
У меня есть опыт развертывания больших кластеров на LINSTOR на предыдущей работе. Например, в одном из проектов было 600+ серверов (часть из них — diskless), 450 NVME и 2500+ виртуальных дисков (persistent volumes).
Libvirt/QEMU
Libvirt с QEMU/KVM — стандартный стек для запуска виртуальных машин в Linux. Эту связку можно использовать как самостоятельное решение, так и в составе различных систем виртуализации.
«Флант» управляет 189 гипервизорами; на них запущено 975 виртуальных машин у 26 клиентов. Всё это работает на классическом стеке QEMU (KVM) + Libvirtd. В некоторых ситуациях используется Proxmox как управляющий слой поверх QEMU. Мы отлично разбираемся в этом стеке.
KubeVirt
KubeVirt — безусловно, самая успешная попытка принести виртуальные машины в Kubernetes. Как и «ванильный» Kubernetes, технология KubeVirt открыта для всех желающих. Это позволило нескольким крупным вендорам объединиться для решения общих задач по организации системы виртуализации на основе Kubernetes. Теперь и мы входим в их число. Совместная работа позволяет не тратить силы на разработку общей логики по запуску виртуальных машин в Kubernetes, а сконцентрироваться на фичах, уникальных для каждой платформы.
Встречайте Deckhouse Virtualization
На базе перечисленных выше технологий мы создали систему виртуализации, которая реализует наше видение гиперконвергентной инфраструктуры. При этом мы не просто скомбинировали их вместе, а постарались «выжать» максимум из каждой.
Мы также хотели сохранить интерфейс взаимодействия максимально простым для конечного пользователя. Для этого пришлось внести несколько существенных изменений. В первую очередь было решено отказаться от API «ванильного» KubeVirt из‑за его чрезмерной сложности и непонятности.
Подчеркну, основная идея платформы Deckhouse — дружелюбность к пользователю. Пользователь, оперируя высокоуровневыми абстракциями, имеет доступ к ограниченной функциональности, но зато эти возможности тщательно протестированы и гарантировано работают в пределах платформы. При работе с примитивами Deckhouse пользователю не нужно задумываться о том, как они функционируют внутри. Платформа делает это за него.
Обратите внимание: наша система виртуализации — это не очередная попытка переиспользовать KubeVirt. Учитывая идеологию и более широкий стек технологий, мы позиционируем её как совершенно новый продукт на рынке виртуализации.
Почему не подошёл «ванильный» KubeVirt
Как и в случае «ванильного» Kubernetes, разработка KubeVirt ведётся без оглядки на конечных пользователей. Вендоры просто объединились для решения глобальных задач и создания общей кодовой базы, которая переиспользуется в их проектах. Примеры: OpenShift, Harvester, и теперь Deckhouse. Примитивы KubeVirt стали очень громоздкими и сложными из‑за необходимости удовлетворить потребности каждого вендора.
Кроме того, KubeVirt — это довольно серьёзный проект. Чтобы принести новые функции и исправления, расширяющие логику общепринятых компонентов, нужно серьёзное обоснование и поддержка со стороны крупных игроков вроде RedHat. Текущий курс проекта — миграция на механизм CNI chaining. Это сложная задача, реализация которой займет немалое время. Поэтому некоторые из наших предложений до сих пор не попали в основную ветку проекта.
Именно несогласие с концепцией организации сети в KubeVirt и собственное видение удобного API заставили нас отделиться от основной ветки проекта и принести три важных изменения в форк.
Пытаясь «выжать» максимальную производительность из сети и при этом задействовать все возможности CNI, мы реализовали поддержку MacVTap для сети Pod'ов. Это не требует дополнительных CNI‑плагинов, подключаемых через Multus. Другими словами, нам удалось достичь практически нативной производительности сети Pod'ов, но использовать её для запуска виртуальных машин. Виртуальные машины работают в той же сети, что и стандартные Pod'ы, позволяя использовать все её возможности, а именно: сетевые политики, IPAM и стандартные Kubernetes‑сервисы. Виртуальная машина задействует сетевой интерфейс Pod'а напрямую, не расходуя ресурсы на маскарадинг или сетевые мосты, что отлично видно в тестах.
-
Другое важное изменение — live‑миграция виртуальных машин с сохранением IP‑адреса. KubeVirt пока не умеет мигрировать виртуальные машины, использующие адрес Pod'а на своем сетевом интерфейсе. Эта возможность доступна, только если сеть Pod'ов подключена с использованием маскарадинга. А это накладывает ограничения: сниженная производительность и необходимость в дополнительном NAT.
Проблема была решена с помощью дополнительного IPAM (IP Address Management), который выдаёт IP‑адреса из диапазона, отведенного для виртуальных машин. Таким образом, к pod network и service network добавилась еще и vm network. Виртуальные машины получают из нее адрес и работают как обычные Pod'ы в кластере. При этом при миграции на другой узел IP‑адрес сохраняется.
Еще одно изменение коснулось томов, с которыми работают виртуальные машины. Для операций с томами в KubeVirt был введён специальный ресурс DataVolume, который описывает том с конкретными данными. Мы решили заменить его на более понятные и привычные пользователю сущности: Disk и Image. Image представляет собой образ, из которого можно создать виртуальную машину. Disk описывает диск с данными, который можно физически подключить к виртуальной машине. Вся остальная логика скрыта от конечного пользователя.
Полный список сущностей можно посмотреть в документации модуля virtualization платформы Deckhouse.
Что уже готово
Модуль активно разрабатывается и дорос до публичной альфа‑версии (PoC). Базовая функциональность уже доступна и ее можно опробовать:
Управление виртуальными машинами: создание, запуск, остановка, удаление.
Механизм резервации IP‑адресов.
Управление дисками: копирование, импорт.
Высокая доступность как для виртуальных машин, так и для компонентов платформы.
SDN с мощными сетевыми политиками на базе Cilium.
Гибкий SDS на базе LINSTOR с поддержкой снапшотов, бэкапирования, шифрования и прочего.
Встроенный мониторинг, дашборды и алерты для системных Pod'ов и вышеперечисленных модулей.
Управление доступом на основе ролей и аутентификация на базе различных источников OAuth 2.0.
Автоматическое обновление всех компонентов платформы.
Примеры создания виртуальной машины приведены в документации модуля.
В ближайшем будущем планируется:
Улучшить механизм миграции виртуальных машин между гипервизорами.
Расширить пользовательский опыт: дополнительный CLI, мониторинг событий, документация и пр.
Сделать веб‑интерфейс для управления кластером и виртуальными машинами.
Добавить поддержку VPC (virtual private cloud). Можно будет создавать отдельные изолированные VLAN'ы и подключать к ним виртуальные машины.
На всякий случай напомню, что модуль виртуализации решает исключительно задачи запуска виртуальных машин.
Сейчас у вас есть уникальная возможность повлиять на разработку. Нам очень нужны ваши мнения, идеи, советы — ведь мы хотим создать действительно полезный, удобный и жизнеспособный продукт на рынке виртуализации!
P.S.
Читайте также в нашем блоге: