Stargzストアを使用したOracle Cloud Infrastructure Kubernetes Engine (OKE)での遅延コンテナ・イメージのロードの有効化
はじめに
レイジー・コンテナ・イメージ・ロード(レイジー・プルまたはオンデマンド・イメージ・ロードとも呼ばれる)は、フル・イメージをダウンロードする前にコンテナの実行を開始できるようにする手法です。実行時に必要なイメージの部分のみがフェッチされ、起動時間が短縮されます(特に大規模なイメージの場合)。
通常、コンテナを実行すると、次のようになります。
- コンテナ・ランタイム(CRI-O、containerdなど)は、レジストリからイメージ全体をダウンロードします。
- すべてのイメージ・レイヤーが解凍されます。
- すべてのレイヤーがダウンロードおよび解凍された後にのみ、コンテナが起動します。
遅延ロードの場合:
- コンテナは、仮想ファイルシステムを使用してすぐに起動します(イメージはまだローカルに存在しません)。
- アプリケーションがファイルにアクセスすると、ランタイムはリモート・レジストリから必要なコンテンツのみをオンデマンドでフェッチします。
- 追加ファイルは、実際に使用された場合にのみダウンロードされます。
- 完全なコンテナ・イメージがバックグラウンドでプルされます。
遅延ロードをサポートするには、コンテナ・イメージを再梱包する必要があります。eStargz形式を使用すると、イメージは独立して圧縮解除可能な小さなチャンクに再パックされます。これにより、コンテナ・ランタイムは、コンテナの起動時に必要なチャンクのみをフェッチできます。
eStargzイメージには、目次(目次)と呼ばれる特殊なファイルが含まれています。このファイルは、目次自体を除き、eStargzレイヤー内のすべてのファイルエントリのメタデータ(名前、ファイルタイプ、所有者、オフセットなど)を記録します。コンテナ・ランタイムでは、TOCを使用して、レイヤー全体の内容をダウンロードせずにコンテナのファイル・システムをマウントできます。
このチュートリアルでは、次の方法について学習します。
- 既存のコンテナ・イメージを再梱包してStargz形式を使用します。
- Stargz Storeプラグインを使用するためのOracle Cloud Infrastructure Kubernetes Engine (OKE) CRI-Oの構成
- サンプル・ワークロードを実行して、コンテナの起動時間の改善を実証します
前提条件
- OKEにアクセスできるOracle Cloud Infrastructure (OCI)アカウント
- 作業中のOKEクラスタ
- OKEクラスタにアクセスするように構成された
kubectl - ローカルにインストールされたDockerまたはcontainerd
設定
nerdctlを使用してコンテナ・イメージを再構築し、eStargz形式を使用します。
-
OCIレジストリ(OCIR)にイメージ・リポジトリを作成します。このチュートリアルでは、
tenancy-namespaceはidxzjcdxqjで、vllm/vllm-openaiという名前のrepoを作成します。
次の手順に従ってOCIRを認証し、新しいリポジトリを作成できます: Docker CLIを使用したイメージのプッシュ。
iad.ocir.ioを、作業中のOCIリージョンのOCIRドメインに置き換えてください。リージョン・キーのリストを次に示します。docker login iad.ocir.io -
Dockerがインストールされているマシンで最新バージョンのnerdctlをダウンロードします。
export NERDCTL_VERSION=2.2.2 wget https://github.com/containerd/nerdctl/releases/download/v${NERDCTL_VERSION}/nerdctl-${NERDCTL_VERSION}-linux-amd64.tar.gz tar -xf nerdctl-${NERDCTL_VERSION}-linux-amd64.tar.gz -
nerdctlをOCIRに認証します。./nerdctl login iad.ocir.io -
vllmコンテナ・イメージをeStargz形式に変換します。
./nerdctl image convert --estargz --oci docker.io/vllm/vllm-openai:v0.11.0 iad.ocir.io/idxzjcdxqj/vllm/vllm-openai:v0.11.0-esgz -
eStargz vllmコンテナ・イメージをOCIRにプッシュします。
./nerdctl image push iad.ocir.io/idxzjcdxqj/vllm/vllm-openai:v0.11.0-esgz -
dockerを使用すると、Dockerを使用して通常のイメージをOCIRにプル/プッシュできます。
docker image pull docker.io/vllm/vllm-openai:v0.11.0 docker image tag docker.io/vllm/vllm-openai:v0.11.0 iad.ocir.io/idxzjcdxqj/vllm/vllm-openai:v0.11.0-regular docker image push iad.ocir.io/idxzjcdxqj/vllm/vllm-openai:v0.11.0-regular
OKEノードへのStargzストア・プラグインのインストール
OKEがCRI-Oを使用していることを考えると、Stargz Storeプラグインを設定する必要があります。これは、CRI-O/Podman用の追加のレイヤー・ストア・プラグインの実装です。Stargz Storeは、リモートマウントされたeStargzレイヤーをCRI-O/Podmanに提供します。
-
ワーカー・ノードの1つにSSH接続し、stargz-snapshotter Githubページから最新バージョンをダウンロードします。
export STARGZ_SNAPSHOTTER_VERSION=v0.18.2 wget https://github.com/containerd/stargz-snapshotter/releases/download/${STARGZ_SNAPSHOTTER_VERSION}/stargz-snapshotter-${STARGZ_SNAPSHOTTER_VERSION}-linux-amd64.tar.gz -
stargz-storeを/usr/local/binに抽出します。tar -C /usr/local/bin -xvf stargz-snapshotter-v0.18.2-linux-amd64.tar.gz stargz-store -
/etc/containers/storage.confファイルを更新して、[storage.options]セクションにadditionallayerstoresを含めます。[storage] driver = "overlay" graphroot = "/var/lib/containers/storage" runroot = "/run/containers/storage" [storage.options] additionallayerstores = ["/var/lib/stargz-store/store:ref"] -
fuseがインストールされ、ロードされていることを確認します。apt-get install fuse modprobe fuse -
stargz-storeサービスを有効にします。wget -O /etc/systemd/system/stargz-store.service https://raw.githubusercontent.com/containerd/stargz-snapshotter/main/script/config-cri-o/etc/systemd/system/stargz-store.service systemctl daemon-reload systemctl restart stargz-store crio -
crioおよびstargz-storeサービスが実行されていることを確認します。systemctl status stargz-store systemctl status crio
パフォーマンスを評価する
-
次のマニフェストの
nodeNameおよびimageを更新し、テスト・デプロイメントを作成します:kubectl apply -f - <<EOF --- apiVersion: apps/v1 kind: Deployment metadata: name: test-estargz-cpu namespace: default labels: app: test-estargz spec: strategy: type: Recreate replicas: 1 selector: matchLabels: app: test-estargz template: metadata: labels: app: test-estargz spec: containers: ## Update the image to your own container repository - image: iad.ocir.io/idxzjcdxqj/vllm/vllm-openai:v0.11.0-esgz name: test command: ["/bin/bash", "-c", "echo started && sleep infinity"] ## Replace the nodename with the name of the node where stargz-store is configured. nodeName: 10.140.34.52 tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule --- apiVersion: apps/v1 kind: Deployment metadata: name: test-regular-cpu namespace: default labels: app: test-regular spec: strategy: type: Recreate replicas: 1 selector: matchLabels: app: test-regular template: metadata: labels: app: test-regular spec: containers: ## Update the image to your own container repository - image: iad.ocir.io/idxzjcdxqj/vllm/vllm-openai:v0.11.0-regular name: test command: ["/bin/bash", "-c", "echo started && sleep infinity"] env: - name: HF_HOME value: "/workspace" ## Replace the nodename with the name of the node where stargz-store is configured. nodeName: 10.140.34.52 tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule EOF -
コンテナの開始時間を監視します。
kubectl get pods -w -
リソースをクリーンアップします。
kubectl delete deploy test-regular-cpu kubectl delete deploy test-estargz-cpu -
GPUを使用したテスト・デプロイメントの場合は、このyamlマニフェストで
nodeNameおよびimageを更新し、次のコマンドを使用して適用します:kubectl apply -f test-manifest-gpu.yaml
結果
次の結果は、30Bパラメータの大規模言語モデルを使用してBM.GPU4.8シェイプで実行されるテストに基づいています。
-
ポッド開始時間は、eStargzの場合は
33s、通常のイメージの場合は4mです。$ kubectl get pods -w NAME READY STATUS RESTARTS AGE test-estargz-5699988945-2zxmh 0/1 ContainerCreating 0 8s test-regular-55fbdf64c8-hn6hg 0/1 ContainerCreating 0 7s test-estargz-5699988945-2zxmh 1/1 Running 0 33s test-regular-55fbdf64c8-hn6hg 1/1 Running 0 4m -
アプリケーションは、
1m27sのeStargzイメージを使用してポッド上で起動します。INFO 12-11 07:59:02 [__init__.py:216] Automatically detected platform cuda. (APIServer pid=1) INFO 12-11 07:59:26 [api_server.py:1839] vLLM API server version 0.11.0 (APIServer pid=1) INFO 12-11 07:59:26 [utils.py:233] non-default args: {'model_tag': 'cpatonn/Qwen3-30B-A3B-Instruct-2507-AWQ-4bit', 'max_model_len': 8192, 'enforce_eager': True} ... (APIServer pid=1) INFO 12-11 08:00:29 [launcher.py:42] Route: /metrics, Methods: GET (APIServer pid=1) INFO: Started server process [1] (APIServer pid=1) INFO: Waiting for application startup. (APIServer pid=1) INFO: Application startup complete. -
アプリケーションは、
32sの通常のイメージを使用してポッド上で起動します。INFO 12-11 08:01:19 [__init__.py:216] Automatically detected platform cuda. (APIServer pid=1) INFO 12-11 08:01:22 [api_server.py:1839] vLLM API server version 0.11.0 (APIServer pid=1) INFO 12-11 08:01:22 [utils.py:233] non-default args: {'model_tag': 'cpatonn/Qwen3-30B-A3B-Instruct-2507-AWQ-4bit', 'max_model_len': 8192, 'enforce_eager': True} ... (APIServer pid=1) INFO 12-11 08:01:51 [launcher.py:42] Route: /metrics, Methods: GET (APIServer pid=1) INFO: Started server process [1] (APIServer pid=1) INFO: Waiting for application startup. (APIServer pid=1) INFO: Application startup complete. -
eStargzイメージを使用するポッドは、通常のものより高速にトラフィック
1m22sを処理する準備ができています。
結論
OKEでeStargz形式を使用したレイジー・イメージ・プルを実装すると、ポッド初期化時間が大幅に改善され、コンテナ起動が4分からわずか33秒に短縮され、87%削減されます。eStargzコンテナ内のアプリケーションの初期化時間は、通常のイメージ(1m27sと32s)より約1分長くかかりますが、準備完了状態までの全体的な時間は依然として1m22s高速であり、ポッドはトラフィックに対してより迅速に利用できるようになります。このトレードオフは、迅速なスケーリング、ポッドの再スケジュールまたはコールド・スタートが重要な本番環境で特に重要であることがわかります。初期コンテナ・プル時間の大幅な短縮は、アプリケーションの起動オーバーヘッドのわずかな増加を上回るためです。大規模なコンテナ・イメージ(特にAIワークロード)を使用するワークロードの場合、eStargzによる遅延プルは、アプリケーション・コードの変更やインフラストラクチャの大幅な変更を必要とせずに、デプロイメントを加速する実用的なソリューションを提供します。
関連リンク
確認
- 著者: Andrei Ilas (マスター・プリンシパル・クラウド・アーキテクト)
その他の学習リソース
docs.oracle.com/learnの他のラボを調べるか、Oracle Learning YouTubeチャンネルで無料のラーニングコンテンツにアクセスしてください。また、Oracle Learning Explorerになるには、education.oracle.com/learning-explorerにアクセスしてください。
製品ドキュメントについては、Oracle Help Centerを参照してください。
Enable Lazy Container Image Loading in Oracle Cloud Infrastructure Kubernetes Engine (OKE) Using Stargz Store
G56888-01