Stargz Store를 사용하여 Oracle Cloud Infrastructure Kubernetes Engine(OKE)에서 지연 컨테이너 이미지 로딩 사용
소개
지연된 컨테이너 이미지 로딩(지연 풀링 또는 온디맨드 이미지 로딩이라고도 함)은 전체 이미지가 다운로드되기 전에 컨테이너가 실행을 시작할 수 있는 기술입니다. 런타임 시 필요한 이미지의 일부만 패치(fetch)되어 시작 시간(특히 큰 이미지의 경우)이 단축됩니다.
일반적으로 컨테이너를 실행하는 경우:
- 컨테이너 런타임(예: CRI-O, containerd)은 레지스트리에서 전체 이미지를 다운로드합니다.
- 모든 이미지 레이어의 압축을 풉니다.
- 모든 레이어를 다운로드하고 압축을 푼 후에만 컨테이너가 시작됩니다.
지연 로딩:
- 컨테이너는 가상 파일 시스템을 사용하여 즉시 시작됩니다(이미지는 아직 로컬에 없습니다).
- 응용 프로그램이 파일에 액세스할 때 런타임은 요청 시 원격 레지스트리에서 필요한 컨텐트만 인출합니다.
- 실제로 사용되는 경우에만 추가 파일이 다운로드됩니다.
- 전체 컨테이너 이미지가 백그라운드에서 풀링됩니다.
지연 로딩을 지원하려면 컨테이너 이미지를 재압축해야 합니다. eStargz 형식을 사용하면 이미지가 작고 독립적으로 압축 해제 가능한 청크로 재압축됩니다. 따라서 컨테이너가 시작될 때 컨테이너 런타임이 필요한 조각만 인출할 수 있습니다.
eStargz 이미지에는 TOC 자체를 제외한 eStargz 계층에 있는 모든 파일 항목의 메타데이터(예: 이름, 파일 유형, 소유자, 오프셋)를 기록하는 TOC(목차)라는 특수 파일이 포함되어 있습니다. 컨테이너 런타임은 TOC를 사용하여 전체 계층 컨텐츠를 다운로드하지 않고 컨테이너의 파일 시스템을 마운트할 수 있습니다.
이 자습서에서는 다음을 수행하는 방법에 대해 알아봅니다.
- Stargz 형식을 사용하도록 기존 컨테이너 이미지 재압축
- Stargz Store 플러그인을 사용하도록 Oracle Cloud Infrastructure Kubernetes Engine(OKE) CRI-O 구성
- 샘플 워크로드를 실행하여 컨테이너 시작 시간 향상 시연
필수 조건
- OKE에 액세스할 수 있는 OCI(Oracle Cloud Infrastructure) 계정
- 작동 중인 OKE 클러스터
- OKE 클러스터에 액세스하도록 구성된
kubectl - 로컬에 설치된 Docker 또는 containerd
설정
nerdctl을 사용하여 eStargz 형식을 사용하도록 컨테이너 이미지 재구축
-
OCIR(OCI Registry)에서 이미지 저장소를 생성합니다. 이 자습서에서는
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 -
OCIR에
nerdctl를 인증합니다../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 -
도커를 사용하여 일반 이미지를 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 Store 플러그인 설치
OKE가 CRI-O를 사용하는 경우 Stargz Store 플러그인을 설정해야 합니다. CRI-O/Podman에 대한 추가 계층 저장소 플러그인의 구현입니다. Stargz Store는 CRI-O/Podman에 원격으로 장착된 eStargz 레이어를 제공합니다.
-
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 -
[storage.options]섹션에additionallayerstores를 포함하도록/etc/containers/storage.conf파일을 업데이트합니다.[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 구성에서 실행된 테스트를 기반으로 하는 결과입니다.
-
Pod 시작 시간은 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 이미지를 사용하여 Pod에서 시작됩니다.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의 정규 이미지를 사용하여 POD에서 시작됩니다.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 형식을 사용하여 로지 이미지 풀링을 구현하면 Pod 초기화 시간이 크게 향상되어 컨테이너 시작 시간이 4분에서 33초로 줄어들고 87% 감소합니다. eStargz 컨테이너 내의 애플리케이션 초기화 시간은 일반 이미지(1m27s 대 32s)보다 약 1분 더 오래 걸리지만, 전체 준비 상태 소요 시간은 여전히 1m22s 더 빠르므로 트래픽에 포드를 더 빠르게 사용할 수 있습니다. 이 절충안은 초기 컨테이너 풀 시간을 크게 줄이면 애플리케이션 시작 오버헤드가 약간 증가하기 때문에 빠른 확장, 포드 일정 조정 또는 콜드 시작이 중요한 프로덕션 환경에서 특히 중요합니다. 대규모 컨테이너 이미지, 특히 AI 워크로드를 사용하는 워크로드의 경우 eStargz를 사용한 게으른 풀링은 애플리케이션 코드 또는 중요한 인프라 수정을 변경하지 않고도 배포를 가속화할 수 있는 실용적인 솔루션을 제공합니다.
관련 링크
승인
- Authors: Andrei Ilas(마스터 수석 클라우드 아키텍트)
추가 학습 자원
docs.oracle.com/learn에서 다른 랩을 탐색하거나 Oracle Learning YouTube 채널에서 더 많은 무료 학습 콘텐츠에 액세스하세요. 또한 education.oracle.com/learning-explorer를 방문하여 Oracle Learning Explorer가 되십시오.
제품 설명서는 Oracle Help Center를 참조하십시오.
Enable Lazy Container Image Loading in Oracle Cloud Infrastructure Kubernetes Engine (OKE) Using Stargz Store
G56889-01