Контейнер или виртуальная машина: различие в одной фразе и четыре его следствия

Вы собираетесь запустить на Proxmox что-то новое, и есть два варианта. Оба запускают Linux, оба стоят в панели рядом, оба будто делают одну и ту же работу.

Выбор обычно делают по привычке к ресурсам: «контейнер легче». Верно, но решать должно не это.

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

Первое следствие: где проходит граница

Границу виртуальной машины чертит оборудование. Границу контейнера чертит ядро сервера.

Это не значит, что контейнер «слабый»; это говорит, где проходит граница. Если сбой в программе внутри контейнера захочет добраться до сервера, ему придётся пройти мимо собственного ядра сервера. В виртуальной машине ему придётся пройти мимо стены на уровне оборудования.

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

Второе следствие: не всё работает в контейнере

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

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

Третье следствие: обслуживание касается их по-разному

Это наименее известное следствие и то, которое вероятнее всего причинит боль.

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

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

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

Четвёртое следствие: свобода перемещения

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

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

Практическое правило

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

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

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

Что делает Atlas

Atlas несёт это различие не как лозунг, а как поведение.

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

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

То есть продукт не подаёт эти два как «две разновидности одного и того же». Они ведут себя по-разному, поэтому и описываются по-разному.