+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Непривилегированный LXC-контейнер в конечном итоге блокирует процессы хоста PVE., Proxmox Виртуальная Среда

timdonovan

Guest

20.04.2022 12:20:00

Я запускаю 2 непривилегированных LXC-контейнера на proxmox-ve 7.1-1 (ядро: 5.13.19-3-pve). Оба LXC работают с Docker. Единственное "экзотичное" в этом — использование Fuse для файловой системы Docker. У них включены nesting,keyctl,fuse,mknod =1. Они работают нормально несколько часов, иногда дней, но через время весь хост уходит "в оффлайн" (читайте дальше..): на узле pve/LXC появляется серый вопросительный знак, Shell-доступ (через веб-интерфейс) недоступен, но ssh все еще доступен для Shell-доступа PVE хоста и для LXC-контейнеров. В конечном итоге узел становится красным (иногда это занимает часы). Система отказывается перезагружаться или выключаться, если я не использую принудительный "magic SysRq sysproc". Я предполагаю, что когда я выполняю выключение, pve зависает, пытаясь выполнить корректное завершение работы LXC-контейнеров. Я пытался убить процессы и демоны LXC, но ничего не происходит. Я пробовал перезапустить различные демоны pve, но это не изменяет состояние хоста. В конечном итоге что-то зависает (на несколько часов), и хост PVE перезагружается, возвращая состояние узла в зеленое. Хотелось бы найти решение, но меня также беспокоит, ведь я думал, что смысл LXC в том, что они изолированы от хоста? Действительно, вся суть Proxmox и виртуальных машин, и контейнеров — это изоляция гостей. Если непривилегированный LXC-контейнер сумел навести шорох на весь хост PVE, это ставит под сомнение всю природу LXC, не так ли? Я пока оставил узел в покое, так что если нужна какая-то информация для отладки, дайте знать, так как я все еще могу получить доступ ко всему через ssh. Спасибо! Редактировать: приложен лог dmesg. Я не могу прикрепить journalctl, потому что он в архиве 1.1 МБ, и это, видимо, слишком большой файл.

alchemydc

Guest

22.10.2022 16:14:00

Привет, Тим. Я столкнулся с такой же проблемой. Гипервизор: pve-manager/7.2-11/b76d3178, ядро Linux 5.15.53-1-pve #1 SMP PVE 5.15.53-1, libzfs4linux 2.1.5-pve1. LXC: debian11, fuse=1, nesting=1, keyctl=1, корневой том — это ZFS subvol, docker-ce 5:20.10.17~3-0~debian-bullseye, fuse-overlayfs 1.4.0-1. Я вижу такое же поведение, как и ты: стек работает нормально какое-то время (дням, неделям), но затем смонтированный docker-LXC зависает, что приводит к сбою компонентов интерфейса PVE гипервизора. Однако я замечаю, что другие рабочие нагрузки на этом гипервизоре продолжают функционировать, как и кластерные возможности гипервизора. Я также заметил, как и ты, что гипервизор не может перезапуститься чисто (вероятно, зависает, пытаясь корректно остановить процессы LXC). Обрати внимание, что выполнение `kill -9 $(pidof lxc-start -n $CONTAINER_ID)` завершит зависший контейнер, и интерфейс PVE сразу начнет работать снова — серый вопросительный знак исчезает и т.д. Не углубляясь в религиозные вопросы о том, разумно ли запускать docker внутри LXC с fuse на ZFS, я хочу понять, что происходит. Одно, что я замечаю, это то, что некоторые из этих 'экзотических' рабочих нагрузок в порядке, а другие зависают время от времени. Посмотрю на снимки / репликацию как на вероятного виновника, но буду признателен за любые подсказки / отзывы от людей с аналогичным опытом.

timdonovan

Guest

28.10.2022 11:56:00

Я отказался от запуска Docker в LXC с ZFS. В итоге вы приходите к компромиссу (стабильность или потеря функций снимков/репликации PVE). Я все еще надеюсь, что это когда-нибудь решится. Я перевел большинство своих приложений, работающих в контейнерах Docker на VM, в LXC, изучив их dockerfile, но для некоторых это просто невозможно сделать без особых усилий. Думаю, моя проблема с зависанием LXC в этой ветке была связана с истощением ресурсов. Почему это вызывает такое поведение хоста PVE, я не уверен... На мой взгляд, это проблематично, что LXC может так плохо влиять на хост PVE. Но что поделаешь...

qcasey

Guest

08.04.2023 06:44:00

У меня тоже такая ситуация была с сервером, полные зависания и приходилось принудительно выключать узел. Это всегда происходит после создания снимка резервной копии LXC с `fuse=1`. Скорее всего, в момент бэкапа ресурсы системы были ограничены. В журнале резервного копирования есть несколько таких записей: ``` failed to open /var/lib/docker/fuse-overlayfs/b9578d3641af3c1df80254296225e96fcb20591f822d0efb473c857868b682a3/merged: Permission denied ``` Я тоже собираюсь отказаться от Docker в LXC. Пара блогов привлекли мое внимание к этому Frankenstein, но он оказался не очень надежным.

prmxyuza

Guest

08.04.2023 06:59:00

У меня уже около недели Docker работает в непривилегированном LXC, бэкапы еще не делал, но пока без проблем. Docker использует overlay2, а LXC на ZFS — последние обновления в Docker (или LXC/ядре?) похоже, исправили проблему с тем, что Docker не использовал overlay2. (Не пришлось использовать обходные решения с ext4 или fuse) Также у меня включен `keyctl=1` на LXC (в документации Proxmox говорится, что это разобьет systemd-networkd, но это было исправлено в systemd около 5 лет назад..) Единственная проблема, с которой я столкнулся, возникла при попытке загрузить образ docker, у которого были очень высокие права пользователя/группы на некоторых файлах внутри, что потерпело неудачу в непривилегированном контейнере — я обошел это, просто собрав образ docker в самом LXC. Хост: Ядро 6.2.6-1-pve LXC: Arch Linux, версия Docker 23.0.2 сборка 569dd73db1, systemctl 253 (253.2-1-arch) вывод из `docker info`: Версия сервера: 23.0.2 Драйвер хранилища: overlay2 Поддерживаемая файловая система: zfs Поддерживает d_type: true Использует метакопирование: false Нативное изменение наложения: false userxattr: true Ваши версии актуальны? Может, стоит попробовать еще раз, чтобы посмотреть, работает ли драйвер overlay2 для вас сейчас.

alchemydc

Guest

21.06.2023 17:14:00

Обновил до ядра 6.x и последнего Docker несколько недель назад, и пока не столкнулся с какими-либо зависаниями при запуске Docker в LXC на ZFS. Хост: 6.2.11-2-pve LXC: Debian 12, версия Docker: 5:24.0.2-1~debian.12~bookworm, версия сервера: 24.0.2, драйвер хранения: overlay2, файловая система: zfs, поддержка d_type: true, использование metacopy: false, native overlay diff: false, userxattr: true. Спасибо за совет!

ikus060

Guest

25.08.2023 22:16:00

У меня есть очень похожая проблема с контейнером с периодической репликацией. > Файловая система: zfs. Я вижу, что вы используете ZFS в качестве хранилища? Я думал, что это не поддерживается. Вы сделали что-то особенное, чтобы это заработало? В настоящее время я использую fuse-overlayfs в качестве драйвера хранилища.

ikus060 Guest	#8 0 26.08.2023 15:57:00 Я пытался создать новый контейнер с помощью Docker, не используя fuse-overlayfs и принуждая использовать overlay2 с zfs на бэкенде. Демон Docker запустился, но когда я пытался загрузить образ, возникла ошибка в ядре хоста: Код: upper fs не поддерживает RENAME_WHITEOUT. fs на '/var/lib/docker/overlay2/l/2NZ4KT2DGDVPBTYUYUEGIAFJVC' не поддерживает файловые дескрипторы, переходит на xino=off. Код: # docker pull docker.elastic.co/elasticsearch/elasticsearch-oss:7.10.2 7.10.2: Загрузка из elasticsearch/elasticsearch-oss ddf49b9115d7: Загрузка завершена a752d85b289a: Извлечение [==================================================>] 25.12MB/25.12MB 57c9a166c575: Загрузка завершена 44fabf20c8a1: Загрузка завершена 45ea1d560ab5: Загрузка завершена 0dc15e54b214: Загрузка завершена cf11b2a25e23: Загрузка завершена 3a66822889ec: Загрузка завершена be7444f2e9d6: Загрузка завершена не удалось зарегистрировать слой: unlinkat /usr/lib/.build-id/29: невалидный аргумент

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры