LXC контейнеры для отдельных сервисов

[KRom]

Я уже отвечал на данный вопрос тут: LXC vs VM для докера и не только

Если кратко, то особой разницы нет, но есть несколько, моментов

Внимание! Дальше идет лонгрид:

Вот мой кластер с 42 запущенными LXC контейнерами и еще 15 потушенными

Начнем с того, что 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 тут не особо то и нужен уже

Я бы расставил рейтинг следующим образом

1. много Alpine LXC без докера
2. 1 ubuntu/alpine LXC + много docker
3. много alpine LXC + docker
4. много 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 хочется добавить несколько моментов

1. musl вместо glibc имеет свои тонкости
2. плохо работает с cgroups2
3. Воловина консоли на busybox

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