LXC vs VM для докера и не только

Еще раз попробую объяснить

Если у вас дикий энтерпрайз, а именно

  1. Выделяются деньги на железо и софт
  2. Выделяются деньги на штат специалистов
  3. Имеются повышенные требования к безопасности
  4. Стоимость минуты простоя очень высокая
  5. Требуется максимальная совместимость

То однозначно следует выбирать VM т.к. она позволяет

  1. Максимально качественно разделить хост и гостевое окружение на уровне ядра, процессов, памяти (в том числе)
  2. Обеспечить паравиртуализацию ресурсов на уровне гипервизора
  3. Иметь возможность мигрировать виртуалки с машины на машину без даунтайма за счет копирования содержимого оперативной памяти
  4. Устанавливать необходимые модули ядра, монтировать SMB и NFS шары, менять ядро, тюнить его, например, менять планировщик
  5. Резервировать ресурсы (CPU и RAM) под виртуалку (на самом деле, переиспользование незанятой оперативки это целый механизм драйверов гостевой системы)
  6. Устанавливать различные версии ядра и вообще операционки, например, совмещать windows и linux
  7. Настраивать сетевые интерфейсы внутри виртуальной машины
  8. Передавать специфичные устройства типа TPU чипов, UEFI,

Если у вас самохостинг и

  1. Какой-нить мини ПК, списанный сервак или мащинист на Z99
  2. На приказ ФСТЭК №21, оценка безопасности КИИ и ГОСТ Р ИСО/МЭК 27001-2021 у вас только одна реакция
  3. Вы играючи монтируется папки с хоста PVE в ваши контейнеры
  4. Быстроподнятое упавшим не считается, а если не быстроподнятое, то можно словить"опять у тебя ничего не работает!" из соседней комнаты
  5. Вы даже не знаете какой дистрибутив развернут в LXC контейнере с immich т.к. он создавался автоматически хелпер скриптом
  6. У вас нет 6 млн рублей на покупку видеокарты с аппаратной виртуализацией и возможностью независимого проброса в виртуалки

То LXC будет однозначно предпочтительней т.к.

  1. Выдает минимальный оверхед
  2. Быстрее создается
  3. Быстрее запускается

За счет того, что LXC в отиличе от KVM

  1. Использует одно ядро ОС
  2. Использует общий файловый буфер
  3. Использует общие файлы и процессы, изоляция производится при помощи механизма cgroups, как и в docker, между прочим
  4. Ограничение доступных ресурсов RAM и CPU является скорее дополнительным функционалом (в PVE обязателен, а вот в чистом LXC/LXD при создании контейнера не требует указания RAM и CPU и даже диска т.к. может использовать общую ФС (тут у меня был прикол, когда 10 lxc контейнеров с docker исчерпали лимиты по inode хостовой файловой системы)
  5. Создает контейнер из шаблона без фактической установки операционной системы, поэтому и нет cloudinit для CT
  6. За счет пункта 3 я, например, пробросил в CT USB принтеры просто на уровне USB шины

И отличие при работе с устройствами, например, вы пробрасываете видеокарту в гостевую систему, то

  • В qemu/KVM (VM) - устройство или полностью, если не умеет, или частично, если имеет соответствущие аппаратные возможности (например, для CPU это AMD-V и VTx, которые должны быть в процессоре и включены в BIOS) убираются из хоста и передаются в бинарном виде в гостевую систему, а гостевая система при помощи драйверов работает с этим устройством
  • В LXC (CT) - процессам в группе процессов, в простонародье называемыми LXC контейнером предоставляется доступ к логическому устройству (например видеокодер /dev/dri/renderD128), при этом само устройство обслуживаеся драйверами, находящимися в ядре хоста (а ядро то и там всего одно)

Например
Alpine linux в CT ходит за информацией не туда, куда следует и команда top показывает количество CPU и RAM хоста, а не те значения, которые вы указали в настройках контейнера

1 лайк