Будет ли один и тот же файл из различных docker изображений кэшироваться на странице в узле k8s только один раз? - PullRequest
Новая
       12

Будет ли один и тот же файл из различных docker изображений кэшироваться на странице в узле k8s только один раз?

0 голосов
/ 15 января 2020

Выдержка из https://docs.docker.com/storage/storagedriver/overlayfs-driver/

Кэширование страниц. OverlayFS поддерживает совместное использование кэша страниц. Несколько контейнеров, обращающихся к одному и тому же файлу, совместно используют одну запись кэша страницы для этого файла.

Это в контексте многослойного docker изображения, где несколько контейнеров обращаются к одному и тому же изображению. Однако в моем развертывании я вижу очень стабильную (во времени) разницу в использовании кэша страниц одним и тем же образом, работающим на разных, но одинаково настроенных узлах кластера Kubernetes. Ни один из узлов не имеет давления в кеше, которое может привести к разным скоростям восстановления.

Итак, мне было интересно, может ли the same file в приведенном выше отрывке ссылаться на "одинаковость", подтвержденную ha sh, и файл может быть частью различных docker изображений?

Разница составляет порядка 30-60 МБ, и это согласуется с библиотеками python / libg c, которые использует мой контейнер. Все это имело бы смысл, если бы общие разделяемые библиотеки были «дедуплицированы» в кэше страниц на уровне узла overlayfs. Кэш страницы будет подсчитываться для cgroup на основе первого касания согласно пункту 2.3 https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt

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

Мне известно о многочисленных размышлениях при дедупликации, например, https://lwn.net/Articles/636943/ Y2015:

Чиннер высказался, чтобы описать проблему, состоящую в том, что в системе могут работать сотни контейнеров, все из которых основаны на снимке одна root файловая система. Это означает, что в кэше страниц будет сто копий glib c, поскольку они поступают из разных пространств имен с разными inode, поэтому обмен данными отсутствует.

И нет, я не использую KSM, поэтому не нужно об этом упоминать. Я был бы признателен, если бы некоторые ссылки на исходный код пролили свет на это поведение.

1 Ответ

0 голосов
/ 24 января 2020

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

Каждая строка в Dockerfile может представлять 0,1 или несколько слоев согласно https://docs.docker.com/storage/storagedriver/. Например, моя текущая сборка FROM ubuntu дает три базовых слоя в моем изображении:

# docker inspect ubuntu: 

"GraphDriver": {
            "Data": {
                "LowerDir": "/var/lib/docker/overlay2/22abb0d6b77061cc1e3a04de4d3c83be15e60b87adebf9b7b2fa9adc0fbb0f2d/diff:/var/lib/docker/overlay2/7ab02c0180d53cfa2f444a10650a688c8cebd0368ddb2cea1dba7f01b2008d37/diff:/var/lib/docker/overlay2/3ee0e4ab0518c76376a4023f7c438cc6a8d28121eba9cdbed9440cfc7474204e/diff",

Если я скажу RUN apt-get -y install python, docker создаст слой, содержащий все папки, файлы и временные метки, созданные этой командой. Слой будет tar 'd, а sha256 будет взят из файла tar. В приведенном выше примере с Ubuntu вы можете видеть, что мезонинный слой имеет sha256sum: 3ee0e4ab0518c76376a4023f7c438cc6a8d28121eba9cdbed9440cfc7474204e

Как только мое изображение будет организовано кластером Kubernetes, слой будет накачан до стандартного местоположения на узле, где запускается изображение , Будет создана ссылка на папку слоя - единственная причина, по которой ссылка должна сделать путь короче, как описано здесь: https://docs.docker.com/storage/storagedriver/overlayfs-driver/. Таким образом, у узла, на котором запущен образ, созданный из Ubuntu, будет что-то похожее на: 

# ls -l /var/lib/docker/overlay2/l |grep 3ee0e4ab0518c76
lrwxrwxrwx    1 root     root            72 Dec 13 15:40 VGN2ARTYLKI6LQWXSZSMKUQOQL -> ../3ee0e4ab0518c76376a4023f7c438cc6a8d28121eba9cdbed9440cfc7474204e/diff

Обратите внимание, что VGN2ARTYLKI6LQWXSZSMKUQOQL здесь является уникальным / node и спецификацией b / node c. И этот идентификатор появится в креплениях для контейнеров. Root cgroup видит все монтирования на узле, а pid 1 обычно принадлежит root cgroup. Таким образом, рассматриваемый слой распределяется следующим образом: 

# grep `ls -l /var/lib/docker/overlay2/l |grep 3ee0e4ab0518c76 |awk '{print$9}'` /proc/1/mounts

overlay /var/lib/docker/overlay2/84ec5295eb902ab01b37451f9063987f5803a0ff4bc53ee27c1838f783f61f48/merged overlay rw,relatime,lowerdir=
/var/lib/docker/overlay2/l/7RBRYLLCPECAY5IXIQWNNFMT4L:
/var/lib/docker/overlay2/l/LK4X5JGJE327XH6STN6DHMQZUI:
/var/lib/docker/overlay2/l/2RODCFKARIMWO2NUPHVP7HREVF:
/var/lib/docker/overlay2/l/DH43WT4W2DPJTMMKHJL46IPIXM:
/var/lib/docker/overlay2/l/DQBSRPR7QCKCXNT4QQHHC6L2TO:
/var/lib/docker/overlay2/l/N3NL6BAOEKFZYIAXCCFEHMRJC2:
/var/lib/docker/overlay2/l/VGN2ARTYLKI6LQWXSZSMKUQOQL,upperdir=/var/lib/docker/overlay2/84ec5295eb902ab01b37451f9063987f5803a0ff4bc53ee27c1838f783f61f48/diff,workdir=/var/lib/docker/overlay2/84ec5295eb902ab01b37451f9063987f5803a0ff4bc53ee27c1838f783f61f48/work 0 0

overlay /var/lib/docker/overlay2/89ce211716bd81100b99ecacc3c9da7af602029b2724d01db41d5efad37f43e6/merged overlay rw,relatime,lowerdir=
/var/lib/docker/overlay2/l/SQEWZDFCQQX6EKH7IZHSFXKLBN:
/var/lib/docker/overlay2/l/TJFM5IIGAQIKCMA5LDT6X4NUJK:
/var/lib/docker/overlay2/l/DQBSRPR7QCKCXNT4QQHHC6L2TO:
/var/lib/docker/overlay2/l/N3NL6BAOEKFZYIAXCCFEHMRJC2:
/var/lib/docker/overlay2/l/VGN2ARTYLKI6LQWXSZSMKUQOQL,upperdir=/var/lib/docker/overlay2/89ce211716bd81100b99ecacc3c9da7af602029b2724d01db41d5efad37f43e6/diff,workdir=/var/lib/docker/overlay2/89ce211716bd81100b99ecacc3c9da7af602029b2724d01db41d5efad37f43e6/work 0 0

Два наложенных монтирования означают, что слой распределяется между двумя работающими контейнерами, созданными из этой версии образа Ubuntu. Или более кратко: 

# grep `ls -l /var/lib/docker/overlay2/l |grep 3ee0e4ab0518c76 |awk ‘{print$9}’` /proc/1/mounts |wc -l
2

Это подтверждает, что контент распределяется между несвязанными контейнерами, и объясняет разницу в использовании кэша страниц, которую я вижу. Это риск для безопасности? Теоретически, злоумышленник может внедрить злонамеренный код в оболочки Ubuntu и создать одноразовый номер, дающий тот же sha256. Это риск на практике? Наверное, не так много ...

...