Использовать отдельно контейнеры под каждый сервис или все сервисы закинуть в один конейнер или ВМ с докером - тут каждый решает для себя сам. Что удобнее и привычнее то и использует.
Хочу разобраться именно в производительности.
Есть ли разница в производительности между сервисом установленым в отдельном контейнере без докера, с докером специально под этот сервис и с докером со всеми сервисами сразу?
Например, некоторые сервисы в скриптах Proxmox helper scripts устанавливаются именно в докере.
Понимаю что для домашних сервисов с 3-5 пользователями вообще нет никакой разницы как и где устанавливать все.
Вопрос сугубо спортивный.
Начнем с того, что Proxmox не рекомендует LXC как таковые, обоснование почитать по ссылке выше
По ресурсам
CPU - современные системы контейнеризации и паравиртуализации практически не накладывают доп. нагрузки, особенно, если основное вычисление происходит в юзерспейсе с минимальным количеством системных вызовов
ФИЧИ CPU и Ядра - тут надо учитывать, что не все можно запихнуть нормально в матрешку (PVE → LXC → DOCKER) например, Podman у меня не захотел работать без привилегированного режима. Поэтому, 1 вариант самый надежный, 3 может потребовать снижения безопасности, 2 посерединке - можно отключать точечно.
RAM - в целом, я бы не сказал, что сильно влияет, особенно если это не VM, то оверхеда и резервирования нет практически
Сеть - docker-proxy снижает производительность, насколько, + проблемы с мультикастом + с IPv6, перевод traefik и consul на network_mode: host сразу решило все мои проблемы, далее кластеризируемые сервисы типа openbao я сразу запускал в этом режиме. OST вот с такими результатами на 1 Ядре с проксированием выдал 32% CPU, с network_mode: host 25%, но это на 2.5 гигабитах
HDD - сложный вопрос, я бы не сказал, что имеет значение, но испортить при желании можно. Там и с LXC уже слоеный пирог, а если добавить докер, то добавляется немного, но в Linux работает довольно таки быстро, в MacOS очень долго работало из рук вон плохо, сейчас вроде обещают на уровне Windows, т.е. на 2 головы хуже, чем в Linux
Гостевая OS - надо понимать, что она LXC контейнер не работает сам по себе, там есть куцая, но система, пусть и без ядра, но init все равно работает, в 1 и 2 варианте при большом количестве сервисов это может иметь место, например переезд с Ubuntu на Alpine для одного из моих сервисов позволило
CPU в простое 2% → 0.2%
RAM 350MB → 120MB
HDD 3.5ГБ → 1.5ГБ
По типам развертывания
Отдельные контейнеры без докера
В теории производительность на уровне 99-100%, но обслуживать сложнее в плане разворачивания и обновления, в репозиториях не всегда есть актуальные версии, если ставить руками, то надо обновлять как-то, тот же Proxmox-Helper-Scripts это самостоятельно делает, но что если скрипт упадет? Что он делает там? Где когфиги? Откуда и куда качает?
Надо понимать, что сам LXC контейнер что-то да и весит, я лично пока перешел на alpine как раз таки для минимального оверхеда, пытался еще уйти с docker на podman еще для снижения издержек, но не завелось
Отдельные контейнеры с докером
При использовании alpine оверхед минимальный, производительность чуть ниже, за счет дополнительных слоев контейнеризации
Удобно управлять средствами самого Proxmox, есть тулзы типа Pulse
Не используется переиспользование системных файлов и слоев в docker, это значит, что если используется ubuntu:latest, в качестве базового образа то тут она будет скачана каждый раз, а в 3 случае только 1
Можно использовать network: host
Один LXC контейнер с кучей докеров
Оверхед операционки контейнера минимальный
Переиспользование слоев докера
Легко добавлять новые сервисы
Без кубера и подобных сложно разворачивать на нескольких серверах
Proxmox тут не особо то и нужен уже
Я бы расставил рейтинг следующим образом
много Alpine LXC без докера
1 ubuntu/alpine LXC + много docker
много alpine LXC + docker
много ubuntu LXC + docker
Итого
Высоконагруженные сетевые и дисковые лучше на хосте или в одном LXC без докера, типовые приложения в докере будут терять меньше фоновой нагрузки самой операционки
Qbittorrent я развернул в LXC + Alpine (alpine еще хороша тем, что там как правило, самый свежий софт, особенно в edge + ее очень легко обновлять), не не скажу в числах, но больше стал раздавать.
Основную доп. нагрузку при множестве LXC контейнеров будет иметь сама операционка внутри LXC контейнера, она может быть более существенной, нежели потери при “обматрешкивании” самого приложения
Множество LXC контейнеров надо как-то поддерживать, у меня для этого используется связка Ansible (Semaphore UI) и Komodo поверх Forgejo (GIT репозиторий), однозначно с 1 контейнером и кучей docker управлять будет проще
Если выбирать 3 вариант, то можно посмотреть в сторону runtpi или приложений внутри самого TrueNas
Актуальные версии софта чаще всего есть в docker, далее идет alpine, потом ubuntu и замыкает debian, ну можно еще федору рассмотреть, но меня тошнит от центоса и федоры.
Я топлю за Alpine еще и потому, что там сам оверхед очень маленький и обновление с одной версии на другую очень быстро происходит, есть и rolling версия. С кучей LXC контейнеров на ubuntu тот еще гемог обновлять с одгого LTS релиза на другой - время обновления выше, а шанс словить проблему больше.
UPD:
По поводу alpine linux хочется добавить несколько моментов
musl вместо glibc имеет свои тонкости
плохо работает с cgroups2
Воловина консоли на busybox
В итоге podman у меня не завелся, внутри контейнера большая часть программ не показывает ограничения ресурсов самого контейнера, а показывает ресурсы хоста.