読んでエッセンスをまとめる
- GitHub - google/crfs: CRFS: Container Registry Filesystem
- Speeding Up Pulling Container Images on a Variety of Tools with eStargz | by Kohei Tokunaga | nttlabs | May, 2021 | Medium
- コンテナイメージのlazy pullingをcurlで試してみる - knqyf263's blog
- stargz-snapshotter/stargz-estargz.md at master · containerd/stargz-snapshotter · GitHub
問題/課題
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の仕様
- いずれも.tar.gz形式のファイルができることは変わらないので、コンテナレジストリ側は追加実装が不要
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
KubeCon EU 20 "Startup Containers in Lightning Speed with Lazy Image Distribution" P.10 より引用
たしかにどのイメージでも絶対に使うものがあるだろうから、それを先に読み込んでおくというは理にかなっている。
Stargz/eStargzを検索する実装
- HTTPのRangeヘッダを使う
- Rangeヘッダを付与するとアクセス先の特定領域のデータを取得できる