Startup Containers in Lightning Speed with Lazy Image Distribution

KubeCon + CloudNativeCon Europe 2020 1日目 のセッションである Startup Containers in Lightning Speed with Lazy Image Distribution についてです。

KubeFest Tokyo 2020 の LT でも同様のお話をされていたので、そちらの動画のリンクも合わせて張っておきます。

要するに

OCI Image の lazy pull を実現して、 pull にかかる時間を改善した。

Problems on the OCI/Docker Specs

  • 従来の Docker 利用時の課題の一つ: イメージの pull が遅い
    • コンテナ起動時間の76%はpullに費やされるが、データは6.4%しか読まれないそう *1

Lazypull with containerd Stargz Snopshotter

OCI イメージのアーカイブ形式に tarball の代わりに stargz を利用し、containerd に Stargz Snapshotter をプラグインとして追加することで lazy pull を実現

  • lazy pull
    • pull 時には起動に必要な最小限のみフェッチ
    • 見せかけの rootfs を FUSE で提供
    • ファイルアクセスが有った際にオンデマンドで都度フェッチ

これにより、 python3.7 の docker pull の時間が: 約32秒 -> 約7秒

Stargz

  • tarball は "non-seekable"
    • 全体を読まないと中身のファイルを取得できない
  • Stargz : per-file で取得可能な tarball コンパチなアーカイブ形式

eStargz

  • Stargz の課題: オンデマンド fetch はネットワーク起因のオーバヘッドが無視できない
  • eStargz : 優先されるファイルをプリフェッチすることで上記の課題点を解決

ベンチマーク

スライドにあるので省略しますが、どれも Stargz , eStargz は従来と比べて pull にかかる時間が短くなっています。 また、 glassfish イメージの例では (オンデマンドにフェッチしてくるファイルが多いため?) Stargz でもそれなりに時間がかかってしまっていますが、 eStargz によるプリフェッチでより時間が短くなっています。

感想

言われてみれば docker pull に結構時間を食われるので、lazy pull 機能はすごく魅力的に感じました。 一方でセッション中に質問にも挙がっていましたが、lazy pull 方式をとってしまうと Registry が予期せず落ちてしまっていた場合に lazy pull も失敗してしまうと思うので、その辺りをどううまくやるのか気になりました。