Контейнеры сами по себе не очень изолированны, по этому убивая основной процесс (init) в контейнере, не факт что все остальные процессы померут - это проблема всех контейнеров, включая как LXC так docker.
Именно по этому в kubernetes как и в docker активно применяется принцип по процессу на контейнер.

Таким образом из минусов:
- Чуть менее стабильная система, т.к. каждый контейнер будет иметь не один процесс, а дерево процессов. То есть инит + всё остальное. LXC здесь выезжает на том что контейнеры как правило статичны и редко перезапускаются.
- Некоторые фишки куба работать не будут, например когда у тебя дофига мелких контейнеров и все они пишут логи в stdout, можно настроить что бы куб собирал их и складывал куда-нибудь в кибану, здесь придётся использовать syslog-server или придумывать что-то своё

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

Собираешь контейнер со всем необходимым, docker'ом запускаешь init, будь-то systemd или openrc, должно работать без проблем

для systemd немножко повозиться придётся, но тоже не проблема

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

один под - это пачка контейнеров, запущенных в одном network namespace (то есть с одним айпишником)

то есть процессы внутри пода могут общаться друг с другом через 127.0.0.1 либо через unix-сокеты

да. Все так. Именно поэтому и склоняюсь к куберу.

у меня еще более сложная задача. Запихнуть легаси. Поэтому надо будет прикручивать еще ceph rbd, ну или линсторы всякие как ты советуешь

сейчас openstack+lxc но похоже это тупиковая ветвь :(

не нужен, centos контейнеры и так неплохо себя в proxmox чувствуют, какая вам разница на хостовую систему?

если не нужна миграция контейнеров с ноды на ноду, то можно и локально хранить

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

ну как раз хочется миграцию. Одна из основных хотелок

когда падает нода с легаси - все страдают

нет, у нас у самих хостовая система - bionic с pve-ядром, а в контейнерах мы centos запускаем

тогда без сетевой хранилки не обойтись

угу.. ну да ладно.. Основной вызов как будут себя чувствовать "systemd-контейнеры" в кубере

тут либо внешний сторадж с nfs/iscsi (простой вариант)
либо ceph/linstor что-то ещё, зависит от нагрузки

Сделал PR для отключения support-tab в sunstone. В 5.8 поломали, можно сколько угодно отключать support-tab в конфигах yml, но это никак не влияет

А небула умеет в режиме работы с openvswitch работать и хостом и виртуалками по одному интерфейсу? Что-то у меня осноной интерфейс все получается в одном бридже, а виртуалки во втором и, соотвественно, пакетики не ходят