lxcfs

LXCFS

Введение

LXCFS - это небольшая файловая система предохранителя, написанная с намерением сделать контейнеры Linux больше похожи на виртуальную машину. Это началось как боковой проект LXC , но можно использовать в любое время выполнения.

LXCFS позаботится о том, что информация, предоставленная важными файлами в procfs таких как:

 /proc/cpuinfo
/proc/diskstats
/proc/meminfo
/proc/stat
/proc/swaps
/proc/uptime
/proc/slabinfo
/sys/devices/system/cpu/online

осведомлены ли контейнер так, что отображаемые значения (например, в /proc/uptime ) действительно отражают, как долго работает контейнер, а не как долго работает хост.

Перед реализацией пространств имен CGROUP Serge Hallyn LXCFS также предоставило дерево cgroupfs контейнер. Показано позаботилось, что контейнер имел только доступ к CGROUPS под собственными CGROUPS и, таким образом, обеспечивал дополнительную безопасность. Для систем без поддержки имен CGROUP LXCFS все равно будут предоставлять эту функцию, но в основном она считается устаревшим.

Модернизация LXCFS без перезапуска

LXCFS разделен на общую библиотеку (точный модуль Libtool, liblxcfs и простой бинарный lxcfs . При обновлении до более новой версии LXCFS lxcfs Binary не будет перезапущена. Вместо этого он обнаружит, что новая версия общей библиотеки доступна и перезагрузит ее с помощью dlclose(3) и dlopen(3) . Этот дизайн был выбран так, что основной петлей предохранителя, который использует LXCFS , не потребуется перезапустить. Если бы это было, то все контейнеры с использованием LXCFS нужно было бы перезапустить, так как в противном случае они остались бы с разбитыми плавниками предохранителей.

Чтобы заставить перезагрузку общей библиотеки в следующем возможном экземпляре, просто отправьте SIGUSR1 на PID процесса работающего LXCFS . Это может быть так же просто, как и делать:

 rm /usr/lib64/lxcfs/liblxcfs.so # MUST to delete the old library file first
cp liblxcfs.so /usr/lib64/lxcfs/liblxcfs.so # to place new library file
kill -s USR1 $(pidof lxcfs) # reload

мусульманин

Для достижения плавных обновлений с помощью общих библиотечных перезагрузков LXCFS также опирается на тот факт, что когда dlclose(3) снижает последнюю ссылку на дерукторы общей библиотеки, и когда запускаются dlopen(3) конструкторы. Хотя это верно для glibc , это не верно для musl (см. Раздел, разгружающий библиотеки.). Таким образом, пользователям LXCFS на musl рекомендуется полностью перезапустить LXCFS и все контейнеры, использующие его.

Здание

Чтобы создать LXCFS Установите предохранитель и заголовки разработки предохранителей в соответствии с вашим дистрибуцией. LXCFS предпочитает fuse3 , но работает с достаточно новыми версиями fuse2 :

 git clone git://github.com/lxc/lxcfs
cd lxcfs
meson setup -Dinit-script=systemd --prefix=/usr build/
meson compile -C build/
sudo meson install -C build/

Чтобы построить с дезинфицирующими средствами meson setup вы должны указать -Db_sanitize=... Например, чтобы включить Асан и Убсан:

 meson setup -Dinit-script=systemd --prefix=/usr build/ -Db_sanitize=address,undefined
meson compile -C build/

Использование

Рекомендуемая команда для запуска LXCFS:

 sudo mkdir -p /var/lib/lxcfs
sudo lxcfs /var/lib/lxcfs

Среда выполнения контейнера, желающая использовать LXCFS , должна затем привязывать установку соответствующих файлов в правильные места для запуска контейнера.

LXC

Чтобы использовать LXCFS с контейнерами на основе SystemD, вы можете либо использовать LXC 1.1, в этом случае он должен работать автоматически, либо иным образом скопировать файлы lxc.mount.hook и lxc.reboot.hook (после того, как он построен) из этого дерева в /usr/share/lxcfs , обязательно выполняется, затем добавьте следующие строки в конфигурацию вашего контейнера: конфигурация конфигуратора:

 lxc.mount.auto = cgroup:mixed
lxc.autodev = 1
lxc.kmsg = 0
lxc.include = /usr/share/lxc/config/common.conf.d/00-lxcfs.conf

Использование с Docker

 docker run -it -m 256m --memory-swap 256m 
      -v /var/lib/lxcfs/proc/cpuinfo:/proc/cpuinfo:rw 
      -v /var/lib/lxcfs/proc/diskstats:/proc/diskstats:rw 
      -v /var/lib/lxcfs/proc/meminfo:/proc/meminfo:rw 
      -v /var/lib/lxcfs/proc/stat:/proc/stat:rw 
      -v /var/lib/lxcfs/proc/swaps:/proc/swaps:rw 
      -v /var/lib/lxcfs/proc/uptime:/proc/uptime:rw 
      -v /var/lib/lxcfs/proc/slabinfo:/proc/slabinfo:rw 
      -v /var/lib/lxcfs/sys/devices/system/cpu:/sys/devices/system/cpu:rw 
      ubuntu:18.04 /bin/bash

В системе с включенным свопом параметр «-u» может использоваться для установки всех значений в «meminfo», которые относятся к свопу на 0.

sudo lxcfs -u/var/lib/lxcfs

Обработка обмена

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

Обработка CGRUP на Linux очень запутанно, и для LXCF просто нет идеального способа справиться с этим.

Терминология, используемая ниже:

• ОЗУ относится к memory.usage_in_bytes и memory.limit_in_bytes
• RAM+SWAP относится к memory.memsw.usage_in_bytes и memory.memsw.limit_in_bytes

Основные проблемы:

• Учет SWAP часто зарегистрируется и требует специальной опции времени загрузки ядра ( swapaccount=1 ) и/или специальных параметров сборки ядра ( CONFIG_MEMCG_SWAP ).

• Как ограничение оперативной памяти, так и предел обмена оперативной памяти могут быть установлены. Delta, однако, не является доступным пространством свопа, так как ядро ​​все еще свободно обмениваться столько бараном, сколько кажется. Это делает невозможным отображать размер устройства свопа, так как использование дельты между ОЗУ и ОЗУ+своп, чтобы это не учитыло бы ядро, заменяющее больше страниц, что приведет к обмену использованию, превышающим общее количество подмен.

• Невозможно отключить обмен в данном контейнере. Самое близкое, которое можно сделать, - это установить швырогство до 0, что серьезно ограничивает риск обмена страницами, но не устраняет их.

В результате LXCFS должен был пойти на некоторый компромисс, которые можно следующему:

• Когда учет SWAP не включен, вообще не сообщается о месте обмена. Это просто потому, что нет способа узнать потребление свопа. Контейнер может очень сильно использовать какое -то обмен, просто нет никакого способа узнать, сколько из него и показывать обмену устройства потребуется какое -то использование обмена. Показание значения хоста было бы совершенно неправильным, показывая значение 0 было бы неверно.

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

• Если малышность установлена ​​на 0, а использование обмена нет, обмену не сообщается. Однако, если есть использование замены, то сообщается об обмене размера использования (на 100%). Это обеспечивает адекватную отчетность о потреблении памяти, предотвращая предоставление приложений, предполагая, что будет доступно больше свопа.

Выпуск отчетности

Основная свалка

В случае сбоя LXCFS, для нас может быть чрезвычайно полезно иметь основной дамп памяти процесса LXCFS.

1. Пожалуйста, проверьте /var/crash и coredumpctl list на случай, если у вас уже есть файл дампа LXCFS Core
2. Если нет, вы можете использовать следующий способ сбора его из своей системы:

На машине, где вы запускаете LXCFS, выполнять как root:

 # save an old core_pattern setting value:
cat /proc/sys/kernel/core_pattern > /root/core_pattern.old_value.bak

# set a new one to collect all core dumps:
echo '|/bin/sh -c $@ -- eval exec gzip --fast > /var/crash/core-%e.%p.gz' > /proc/sys/kernel/core_pattern

# wait for the next LXCFS crash and check
ls -lah /var/crash

# there should be a file with a name like "core-lxcfs.80581.gz". Please, upload it somewhere and share with us.

# restore the old "core_pattern" value:
cat /root/core_pattern.old_value.bak > /proc/sys/kernel/core_pattern