Вирутализация: когда не рекомендуюется использовать контейнеры, а рекомендуют VM

Когда уровень изоляции контейнера недостаточен или нужно другое ядро.

И тогда не понятно

Из определения «виртуальной машины» и «контейнера» понятно же.

Виртуальная машина - это эмуляция платформы, а контейнер - изоляция пространства пользователя.

Когда уровень изоляции контейнера недостаточен или нужно другое ядро.

Практический пример можно?

Виртуальная машина - это эмуляция платформы, а контейнер - изоляция пространства пользователя.

Отлично.

В каких случаях мне может понадобиться разрабатывать такой софт, которому бы не подошло «изоляция пространства пользователя», а требовалось бы именно «эмуляция платформы»?

Насколько подробный? Ну k8s, например. Технически оно может работать хоть в докере (см. kind), но в продакшене это так себе идея. Оно активно использует сетевой стек и неймспейсы, может загружать нужные модули ядра.

В каких случаях противопоказано использовать контейнеры, а следует использовать именно виртуальные машины?

Например при запуске в ВМ Windows, MacOS или что-нибудь ещё более маргинальное.

Это какой-то перевёрнутый подход.

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

UPD. Опять же надо учитывать требуемый уровень изоляции, особенности развёртывания, отказоустойчивости и т.п.

Вот выше, k8s, наверное хороший пример.

Ну k8s, например. Технически оно может работать хоть в докере (см. kind), но в продакшене это так себе идея. Оно активно использует сетевой стек и неймспейсы, может загружать нужные модули ядра.

Это был еще один мой (невысказанный) вопрос.

Почему бы k8s не поставить на голое железо? Зачем его в виртуалке разворачивать?

Например при запуске в ВМ Windows, MacOS или что-нибудь ещё более маргинальное.

А в Enterprise это может понадобиться?

Вы софт разрабатываете, а как его запускать зависит от того, что же ему в итоге требуется для работы - либо контейнер, как изолированное пространство с минимум необходимого для запуска приложения, либо вм, как полноценная ОС

Не совсем так.

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

Почему бы k8s не поставить на голое железо? Зачем его в виртуалке разворачивать?

Проще деплоить ноды. А если продавать его как managed, то и вариантов нет. А так, у себя, конечно, можно ставить как больше нравится.

Проще деплоить ноды

Можно поподробней здесь? Как выглядит процесс на голом железе, как при виртуализации?

А если продавать его как managed, то и вариантов нет

И здесь поподробней, если можно: что нельзя реализовать на bare metal? Kubernetes multitenancy не умеет?

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

Я не совсем уверен, но ничего, если что поправят.

Как выглядит процесс на голом железе, как при виртуализации?

Я не занимаюсь кубером, если что :) На железе не в курсе, но вариантов миллион, начиная с обычного kubeadm руками. А виртуальные машины дают возможность использовать шаблоны и удобные средства вроде terraform, а потом ansible. Не то чтобы подобного terraform принципиально не было для железа, но оно точно менее на слуху.

Kubernetes multitenancy не умеет?

Я сейчас вспомнил, что гугл вроде как использует сам k8s для хостинга k8s (то есть кластер в кластере). Используется ли у них при этом полноценная виртуализация — не знаю.

Когда нужна безопасность или разграничение доступа.

Например, проэкслуатировав уязвимость в ядре Линукса из контейнера, можно поиметь весь хост.

Или когда нужно поставить Oracle DB.

Вашему ПО или ОС нужно загрузить особый модуль ядра — контейнеры не позволят это сделать.

Вы хотите установить ОС, отличную от хостовой — контейнеры не позволят это сделать.

Вам нужно модифицированное ядро, или просто новее, чем есть на хосте — контейнеры не позволят это сделать.

Вашему ПО или ОС нужно загрузить особый модуль ядра — контейнеры не позволят это сделать.

Я видел Docker-контейнер Wireguard, который это делает. Но это такой трэш, что я не понимаю, нафига там вообще контейнер. На мой взгляд, если докеру нужен параметр --privileged, то это явно задача для полной виртуализации.

В каких случаях мне может понадобиться разрабатывать такой софт, которому бы не подошло «изоляция пространства пользователя», а требовалось бы именно «эмуляция платформы»?

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

Практический пример

Нувотянапример тестирую модули ядра. Для сборки контейнеры годятся, для запуска - нет.

Некоторые считают, что главная разница вовсе не в ядре, а в том, что у контейнеров есть правильное применение™. Согласно им контейнер, используемый «как виртуалка» - неправильный и его автору следует выпить йаду.

Например, проэкслуатировав уязвимость в ядре Линукса из контейнера, можно поиметь весь хост.

Конкретный пример можно?

Или когда нужно поставить Oracle DB.

Здесь поподробней, пожалуйста: почему Oracle DB не становится в контейнер?

А можно от общих концепций к конкретным примерам?

Вашему ПО или ОС нужно загрузить особый модуль ядра — контейнеры не позволят это сделать.

Например?

Мне приходит в голову только DPDK, где нужны параметры модуля ядра, чтобы это заработало.

FPGA: там нужны спец. модули?

Может что-то еще?

Вы хотите установить ОС, отличную от хостовой — контейнеры не позволят это сделать.

Поиграться дома - да, кейс понятен.

А в энтерпрайсе: можно конкретный пример, где без Windows, MacOS не обойтись?

Вам нужно модифицированное ядро,

Что такого может быть в ядре, что обычно не включено в дефолту, и что может сильно понадобиться моему софту? Можно пример, пожалуйста?

В каких случаях мне может понадобиться разрабатывать такой софт, которому бы не подошло «изоляция пространства пользователя», а требовалось бы именно «эмуляция платформы»?

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

Этот кейс понятен, да.

Ок, +1.

Спасибо.

Хотелось бы ещё.

где без Windows, MacOS не обойтись?

AD. Даже в Apple для этого используют Windows, а не какие-то альтернативы типа LDAP.

Нувотянапример тестирую модули ядра. Для сборки контейнеры годятся, для запуска - нет.

Это очень особенный кейс.

Некоторые считают, что главная разница вовсе не в ядре, а в том, что у контейнеров есть правильное применение™. Согласно им контейнер, используемый «как виртуалка» - неправильный и его автору следует выпить йаду.

Вот проблема в том, что в Интернете вот таких концептуальных утверждений много. А вот конкретных кейсов, чтобы было явно видно что контейнеры здесь не подходят, - нету.

P. S. А вообще контейнеры считаются частным случаем виртуализации. Так что что есть «виртуалка» - большой вопрос.

AD. Даже в Apple для этого используют Windows, а не какие-то альтернативы типа LDAP.

Хороший кейс. Спасибо.

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

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

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

Лучше наоборот, обосновывать чем контейнеры лучше. Я вот эти чруты отчаяния не понимаю.

Лучше чего?

ВМ

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

или ты про lxc?

а идея контейнера в том, что он дает один сервис

Чтобы давать сервис, никакие контейнеры не нужны.

Чтобы давать сервис, никакие контейнеры не нужны.

можно более развернуто? я не очень догадлив

Что именно тут непонятно? Прога, запущеная в контейнере и прога, просто запущеная, по функционалу не отличаются. Контейнер не нужен.

? Прога, запущеная в контейнере и прога, просто запущеная, по функционалу не отличаются.

это да. но есть одно но. держать по виртуалке для каждой любой проге накладно, так никто не делает. в вируталку ставят несколько приложений. проблемы наступают когда: виртуалок у тебя больше 500/1000 , когда тебе надо откусить кусок от вируталки( перенести прогу в другое место), когда надо делать апгреды оси. все это можно делать, но все это стоит денег. когда твой сервис в докере, ты просто деплоишь его куда тебе надо и все. а с кубами так и еще легче.

вопрос можно было бы поставить и так, что а зачем виртуалки, можно же ставить ось на бареметал и запускать там сервис. ответ на этот вопрос можно экстраполировать и на вопрос автора поста.

Да причём тут виртуалка? Просто запущеная прога. Безо всяких виртуалок, контейнеров и прочих обёрток.

Если ей нужны кастомные библиотеки, кладёшь рядом и прописываешь LD_LIBRARY_PATH.

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

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

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

И? Изоляции-то нет, гламурный чрут.

И? Изоляции-то нет, гламурный чрут.

Контейнер - это не чрут. Точнее не только чрут. Свои девайсы, свои PID’ы (в плоть до того, что свой init), свои mount-point’ы, свой сетевой стек (IP адреса, ARP таблицы, таблицы маршрутизации и т. п.), лимиты на использование CPU, памяти, сети и т. п. Только ядро общее. Короче это полноценная виртуализация. Просто механизы другие.

Изоляция там нормальная. Да, есть разница если сравнивать с VM, но если только ты не строишь систему для Пентагона, тебе её хватит.

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

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

Минуточку, а кто мешает взять docker image с целой операционкой? Например, Debian целиком в контейнере запустить, ммм? Все это docker прекрасно умеет, на самом деле, не вводите в заблуждение людей, пожалуйста.

Во-первых, Docker и не предназначен, и не умеет запускать полноценные дистрибутивы (docker и systemd несовместимы).

Во-вторых, речь шла не про Docker, а про контейнеризацию в целом.

Под ОС имелись в виду системы не на ядре Linux.

А что, в Docker hub «неполноценные» дистрибутивы предлагаются? В чем их неполноценность?

И да, я только про docker и говорю, если что.

«docker и systemd несовместимы» ой вей типа опытный притворился спецом , а опыт поддельный. Вам реально кто платит даунам ? Если в ядре есть поддержка докера то почему это не сможет

пользуй юникернелы, ломай систему

бюджет

Ну вот и пришли к тому что я писал

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

Да, так делают повсеместно, но не надо считать, что это хорошая организация работы.

А что, в Docker hub «неполноценные» дистрибутивы предлагаются?

Да, особо адаптированные под Docker, не такие, какие в стандартном ISO или для ПО системной контейнеризации (lxc/lxd).

В чем их неполноценность?

Они предназначены для контейнеризации приложений, через Docker в частности: в них либо нет init-системы, либо он заменён на какой-то самый простой. Стандартные системные демоны не запускаются (cron, например), логгирование внутри контейнера не осуществляется (отдавая его полностью docker), и т.п.

Разные подходы и идеология — docker для контейнеризации приложений, lxc/lxd/virtuozzo — для контейнеризации системы.