LXD и KVM: где контейнеризация выигрывает, а где проигрывает виртуализация

LXD и KVM: не гонка вооружений, а разделение труда

LXD вырывается вперёд там, где нужна скорость и плотность. На сервере с 16 ГБ RAM он запускает 536 контейнеров против 37 виртуальных машин KVM — и стартуют они в 16 раз быстрее. Но эта победа измеряется в секундах и мегабайтах. Как только нагрузка перестаёт быть лёгкой, разница тает, а вместе с ней исчезает и иллюзия универсального выбора.

Как работает LXD — и где его механизм даёт сбой

LXD — продукт от Canonical — работает на уровне ядра Linux. Вместо эмуляции железа, как в KVM, он использует cgroups для ограничения ресурсов и namespaces для изоляции процессов. Контейнеры делят ядро хоста, но не видят друг друга — по крайней мере, на первый взгляд.

Чтобы корректно отображать /proc и /sys внутри контейнера, LXD полагается на FUSE-файловую систему lxcfs. Без неё контейнер получает данные хоста вместо своих собственных. Живая миграция тоже не тривиальна: требуются заранее настроенные общие хранилища (например, ZFS или Ceph) и корректные сетевые мосты. Иначе контейнер «зависает» на середине процесса, и администратору приходится перезапускать его вручную.

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

Плотность против предсказуемости: где LXD начинает «спотыкаться»

В тестах Canonical 2015 года на сервере Intel с 16 ГБ RAM и Ubuntu 14.04 LTS разница в задержках достигала 57% в пользу LXD (бенчмарк с 0MQ). Но эти цифры получены в лаборатории.

В реальных условиях, когда один контейнер начинает жадно потреблять память или CPU, остальные остаются без ресурсов. В сценариях с тяжёлыми нагрузками — например, с базами данных — разница в плотности сокращается до 2–3 раз, а задержки сближаются. Хостинг-провайдеры, которые массово запускают клиентские окружения на LXD, сталкиваются с тем, что система «падает» под неравномерной нагрузкой.

Решение — ручная настройка limits.cpu и limits.memory при запуске каждого контейнера. Но это уже не автоматизация, а подгонка под каждую ВМ вручную. LXD выигрывает в плотности, но проигрывает в предсказуемости.

KVM: когда железная изоляция всё ещё нужна

KVM — аппаратный гипервизор (Type-1). Он эмулирует полное железо и запускает независимые ОС с собственными ядрами. Каждая виртуальная машина изолирована на уровне гипервизора, а не делит ядро с хостом.

Это критично для смешанных нагрузок. Например, если в инфраструктуре сосуществуют Windows-приложения, старые сервисы и новые микросервисы на Linux, KVM справляется с этим лучше, чем LXD. Последний работает только с Linux-гостями.

В тестах Ericsson 2015 года разница в производительности CPU между LXD и KVM для тяжёлых нагрузок составляла ~60% в пользу KVM. Здесь контейнеризация проигрывает: отсутствие аппаратной изоляции даёт о себе знать.

Что общего у LXD и KVM — и почему это важно

Оба инструмента интегрируются с OpenStack: LXD как платформа для контейнеров, KVM — для полноценных ВМ. Canonical позиционирует LXD как «гипервизор», но это упрощение. На самом деле LXD — контейнерный гипервизор (Type-0.5), который работает на другом уровне абстракции, чем классический Type-1.

Такое позиционирование создаёт путаницу. Одни команды используют LXD для «лёгких» задач, другие пытаются запихнуть в него тяжёлые нагрузки — и получают нестабильность и накладные расходы. Выбор инструмента здесь не вопрос «лучше или хуже», а вопрос архитектуры.

Практическое правило: когда ставить LXD, а когда — KVM

Используйте LXD, если:

• Вам нужна высокая плотность: сотни изолированных окружений на сервере.
• Ваши нагрузки лёгкие: веб-серверы, микросервисы, тестовые стенды.
• Важна скорость развёртывания и низкие задержки.

Используйте KVM, если:

• Вам нужна аппаратная изоляция: например, для Windows или сложных приложений.
• Ваши нагрузки ресурсоёмкие: базы данных, heavy-compute.
• Вы не уверены в безопасности общей инфраструктуры: уязвимость ядра хоста в LXD бьёт по всем контейнерам сразу.

KVM не подходит для нагрузок с высоким потреблением RAM или не-Linux ОС. LXD, в свою очередь, не выдержит нагрузки базы данных или графического рендеринга без серьёзных доработок.

Что остаётся за кадром: неочевидные риски

Общая уязвимость ядра хоста — ахиллесова пята LXD. Если в ядре находится критическая уязвимость, она распространяется на все контейнеры. В KVM каждая ВМ изолирована на уровне гипервизора, а значит, риск ограничен одной машиной.