Сегодня друг zouyee Дуан Цюаньфэн представляет вам «Lazy-pulling Interpretation of Containerd Mirroring», в которой пишется «kuberneter scheduling from small to deep: Framework», так что следите за обновлениями.
1. Предпосылки
Мы знаем, что время запуска контейнера очень быстрое, но если образ контейнера на узле не существует, то при запуске контейнера сначала нужно вытащить образ.Вытягивание образа занимает много времени в процессе запуска контейнера.Этот процесс заключается в переносе всех слоев образа контейнера на локальный диск. По статистике операция извлечения образа занимает 76% времени запуска контейнера. Это не проблема, когда количество контейнеров невелико, но это будет очень медленно, когда количество контейнеров велико и все они запущены в холодном состоянии.
Как решить проблему медленной загрузки образа при холодном старте контейнера? Есть такое решение: в процессе запуска контейнера образ, используемый контейнером, считывается из репозитория образов по запросу через высокоскоростную сеть, вместо того, чтобы подтягивать вниз все слои образа. Stargz-snapshotter — это подпроект в containerd, он расширяет функции containerd в форме прокси-плагина и представляет собой реализацию containerd для удаленного моментального снимка.
Изменение версии
2. Используйте
Stargz-snapshotter относительно просто использовать в kuberentes: используйте Containerd в качестве среды выполнения CRI для kuberentes. Запустите службу stargz-snapshotter локально в качестве удаленного снимка containerd.
зеркальное преобразование
Перед использованием нам нужно преобразовать наше обычное изображение в изображение, которое может быть распознано stargz-snapshotter, и использовать инструмент ctr-remote для преобразования.Следующий пример - преобразование локального образа Centos и отправка его на зеркальный склад. после завершения преобразования:
$ ctr-remote image optimize --plain-http --entrypoint='[ "sleep" ]' --args='[ "3000" ]' centos:7 centos:7-eg
В сравнении
Используйте инструмент crictl, чтобы получить изображения до и после преобразования локально и провести сравнение. Быстрее получать изображения ленивым способом:
# 正常拉取镜像
$ time crictl pull centos:7
Image is up to date for sha256:ef8f4eaacef5da519df36f0462e280c77f8125870dbb77e85c898c87fdbbea27real
0m5.967suser 0m0.009ssys 0m0.012s
# 拉取优化后的镜像
$ time crictl pull centos:7-eg
Image is up to date for sha256:36edf0c0bb4daca572ba284057960f1441b14e0d21d5e497cb47646a22f653d6real
0m0.624suser 0m0.012ssys 0m0.010s
Просмотр зеркальных слоев
Используйте crictl для создания модуля, войдите в контейнер и проверьте локальный кеш каждого слоя изображения в каталоге /.stargz-snapshotter/:
$ cat /.stargz-snapshotter/*{"digest":"sha256:857949cb596c96cc9e91156bf7587a105a2e1bc1e6db1b9507596a24a80f351a","size":80005845,"fetchedSize":3055845,"fetchedPercent":3.819527185794988}{"digest":"sha256:8c57b1a6bef1480562bc27d145f6d371955e1f1901ebdea590f38bfedd6e17d0","size":33614550,"fetchedSize":64550,"fetchedPercent":0.19202993941611593}
3. Принцип
На приведенном выше рисунке представлен обзор реализации stargz-snapshotter. Обычно, когда мы извлекаем изображение, нам нужно вытащить каждый слой изображения. После использования stargz-snapshotter containerd больше не является слоем для извлечения изображения, но для хранения.Каждый слой образа в зеркальном хранилище создает каталог на работающем узле контейнера и монтирует его в каждый каталог с помощью удаленного монтирования. Перед запуском контейнера каждый каталог монтируется как оверлей, чтобы обеспечить корневую файловую систему для контейнера. Когда файл необходимо прочитать, файл на зеркальном уровне в зеркальном хранилище считывается через сеть.
Давайте посмотрим, как удаленно монтируется зеркальный слой и как читать файлы с зеркального слоя по требованию.
файловая система пользовательского режима
Stargz-snapshotter использует FUSE для реализации файловой системы пользовательского пространства. Фреймворк FUSE (файловая система в пользовательском пространстве) — это модуль ядра, который позволяет пользователям реализовать файловую систему в пользовательском пространстве и смонтировать ее в каталог, точно так же, как реализовать файловую систему в ядре.
Как показано на рисунке выше, stargz-snapshotter — это программа, реализующая файловую систему пользовательского режима (язык golang, использующая go-fuse в качестве зависимости от реализации). Когда происходит операция извлечения образа, stargz-snapshotter создаст каталог в ${stargz-root}/snapshotter/snapshots/ для каждого слоя образа, выполнит логику реализации файловой системы и сохранит файловую систему. только что созданный каталог, такой как /dcos/snapshotter/snapshots/1 на рисунке. Когда пользователь читает файл в каталоге, поток запроса выглядит следующим образом:
① Запрос операции на FUSE через VFS
② Модуль ядра FUSE вызывает логику stargz-snapshotter в соответствии с типом запроса, и stargz-snapshotter считывает файлы этого слоя с зеркального хранилища.
③ Stargz-snapshotter возвращает содержимое файла в системный вызов через VFS
(e) формат stargz
а. формат stargz
Обычно слои изображения, хранящиеся в зеркальном репозитории, сжаты с помощью gzip, и мы не можем извлечь отдельные файлы из этого сжатого файла. Как stargz-snapshotter считывает один файл с одного слоя изображения?
Stargz-snapshotter использует другой формат для сжатия слоя изображения, который также является пакетом gzip, доступным для поиска пакетом gzip Рисунок 3 представляет собой сравнение targz и stargz. Файлы в сжатом пакете можно извлекать и извлекать, но они все еще в формате zip; каждый файл в слое изображения будет помещен в zip-пакет и, наконец, сформирован в большой zip-пакет; во всем zip-файл, который записывает смещение каждого файла в пакете; Нижний колонтитул занимает последние 47 байт и записывает смещение оглавления во всем zip-пакете.
Таким образом, вы можете найти смещение TOC через нижний колонтитул последних 47 байт зеркального слоя, а затем прочитать содержимое TOC, чтобы узнать, какие файлы находятся во всем зеркальном слое, и каково смещение каждого файла. . Stargz-Snapshotter использует этот файл TOC для извлечения файлов всего слоя изображения по запросу.
б. формат estartgz
По умолчанию, после удаленного подключения слоя образа к целевому хосту, stargz-snapshotter создаст фоновую задачу по умолчанию для кэширования слоя образа. В процессе запуска контейнера, если файлы, необходимые для запуска контейнера, не кэшированы локально, stargz-snapshotter необходимо прочитать из репозитория образов через сеть, что приведет к снижению скорости запуска контейнера.
estargz оптимизирован для формата stargz, как показано на рисунке выше. У него есть дополнительный файл ориентира, который делит файлы в слое изображения на две категории: одна, которая, скорее всего, будет использоваться во время работы контейнера, а другая, возможно, не будет использоваться. Таким образом, фоновые задачи будут предпочтительно кэшировать файлы, необходимые контейнеру для запуска, что повысит частоту попаданий в локальный кэш и ускорит запуск контейнера.
На следующем рисунке показано сравнение трех зеркальных слоев: устаревший — обычный зеркальный слой, stargz — зеркальный слой в формате stargz, а estargz — зеркальный слой в формате stargz после оптимизации.
C. Многоуровневые изображения для извлечения
Зеркальный слой использует формат estargz для извлечения файлов из сжатого пакета.Как stargz получает все или часть данных файлов по осколкам из зеркального хранилища?
В спецификации OCI есть описание того, как получить некоторые данные из хранилища, а в реестре докеров тоже есть соответствующая реализация интерфейса.
Интерфейс для получения данных развертывания уровня образа в реестре выглядит следующим образом:
Среди них имя — это имя целевого репозитория, дайджест — это значение дайджеста большого двоичного объекта зеркального слоя, Хост — это адрес зеркального репозитория, а Диапазон описывает фрагмент большого двоичного объекта, который необходимо получить.
Возвращаемый ответ выглядит следующим образом:
Среди них start — это начальный байт, end — конечный байт, size — размер слоя, а length — слайс уровня этого запроса.
ленивый процесс вытягивания
Процесс для containerd использования stargz-snapshotter для извлечения изображений выглядит следующим образом:
① Проанализируйте значение дайджеста манифеста зеркала в соответствии с именем и тегом зеркала.
② В соответствии со значением дайджеста зеркального манифеста загрузите манифест с зеркального склада и сохраните его в хранилище контента.
③ Получите дайджест конфигурации зеркала в соответствии с содержимым манифеста, загрузите конфигурацию с зеркального хранилища и сохраните ее в хранилище контента.
④ Проанализируйте каждый слой изображения и создайте снимок.Если containerd использует stargz-snapshotter, он вернет ошибку, что снимок уже существует. Логика Stargz-snapshotter PrepareSnapshot представляет собой процесс подготовки файловой системы для текущего слоя и ее локального монтирования.
⑤ После разрешения всех слоев изображения метаданные изображения будут сохранены.
4. Резюме
При создании контейнера процесс извлечения образа занимает большую часть времени запуска контейнера.Обычно мы используем различные методы, чтобы сделать образ как можно меньше или распространять образы через сеть P2P. Ленивое извлечение изображений — еще один способ увеличить скорость распространения изображений.
При использовании stargz-snapshotter для извлечения образа загружаются только манифест и конфигурация образа, и каждый слой образа монтируется на текущем хосте с помощью удаленного монтирования, чтобы контейнер мог читать файлы по требованию во время его работы. . Традиционным способом является загрузка каждого слоя изображения на локальный диск для распаковки. Напротив, первый может увеличить скорость извлечения образов и ускорить холодный запуск контейнеров. Но следует отметить, что файл загружается по запросу, это зависит от лучшего сетевого окружения.
Для последующего контента, пожалуйста, проверьте официальный аккаунт:
использованная литература