フラミナル

考え方や調べたことを書き殴ります。IT技術系記事多め

lazy pullingとeStargzまわりのエッセンスをつかむ

読んでエッセンスをまとめる

問題/課題

image pull に時間がかかりすぎ->もっと早くしたい

解決のアプローチ

  • 最終的には欲しいものだけ先にゲットできれば最速
  • いまのイメージの構造(tar+圧縮)では必要なやつだけ取るのは不可能
  • 欲しいファイルを欲しい時にもってこれる(seekable)イメージ構造に変更しよう
    • Seekable tar.gz のコンセプト
  • 外部から呼び出す時は欲しいファイルを引数にしてリクエストをし、それだけを取得することで効率化しよう
  • これをlazy pullingと呼ぶ

アーキテクチャ

Stargzの(seekableなイメージ構造) 実装

  • 元々は各tarファイルを全てまとめてGzip圧縮していた
    • *.tar.gz: Gzip(TarF(file1) + TarF(file2) + TarF(file3) + TarFooter))
  • しかしStargzでは各tarファイルを個別にGzip圧縮し、それを連結し最後に追加したTOCファイルにてファイル名やオフセット値を管理しseekableにした
    • *.tar.gz: Gzip(TarF(file1)) + Gzip(TarF(file2)) + Gzip(TarF(file3_chunk1)) + Gzip(F(file3_chunk2)) + Gzip(F(index of earlier files in magic file), TarFooter)
    • Gzip化したファイルを連結しても問題なく1つのファイルとして管理でき、解凍ももコマンド一発でできるのはGzipの仕様
    • f:id:lirlia:20210616140716p:plain
  • いずれも.tar.gz形式のファイルができることは変わらないので、コンテナレジストリ側は追加実装が不要

f:id:lirlia:20210616140959p:plain

KubeCon EU 20 "Startup Containers in Lightning Speed with Lazy Image Distribution" P.8 より引用

eStargzの実装(extended Stargz)

Stargzではファイルへのアクセスが発生したタイミングで必要なファイルのみpullするような仕様になっていました。しかしそれではネットワークアクセスのオーバーヘッドが無視できません。
ではどうするかというとコンテナ起動時にアクセスされやすいファイルだけ最初にprefetchしてキャッシュしておきます。そうすることでアクセスされにくいファイルだけ遅延で取得すれば良くなります。
コンテナイメージのlazy pullingをcurlで試してみる - knqyf263's blog

f:id:lirlia:20210616141036p:plain

KubeCon EU 20 "Startup Containers in Lightning Speed with Lazy Image Distribution" P.10 より引用

たしかにどのイメージでも絶対に使うものがあるだろうから、それを先に読み込んでおくというは理にかなっている。

Stargz/eStargzを検索する実装

  • HTTPのRangeヘッダを使う
    • Rangeヘッダを付与するとアクセス先の特定領域のデータを取得できる