Gocker(Phase 1) 3일차 회고

2026.08.23

한 일

• 컨테이너의 전체 구조에 대한 공부

---

도커

도커를 크게 보면 사용자 편의 도구(CLI)와 고수준 런타임(containerd), 저수준 런타임(runc)를 결합한 통합 플랫폼입니다.

Docker CLI 는 도커 명령어를 말합니다.

docker ps -a
docker version

그리고 Docker Engine는 위 명령어를 받아서 실제로 명령을 수행하는 엔진입니ㅏㄷ.

이 도커 엔진 내부에는 contaienrd가 있고, 그 containerd 내부에 runc가 존재합니다.

Docker
 ├─ Docker CLI       ← docker run 같은 명령어
 ├─ Docker Engine    ← 컨테이너 관리 
 │      │
 │      └─ containerd
 │             │
 │             └─ runc
 │                    ↓
 │                Container
 │
 ├─ BuildKit         ← 이미지 빌드
 └─ 기타 기능        ← network, volume 등

컨테이너 런타임

컨테이너 런타임은 컨테이너를 실제로 생성, 실행, 관리하는 소프트웨어 엔진입니다.

컨테이너 런타임에는 고수준 런타임과 저수준 런타임이 존재합니다.

이 두 런타임은 계층적인 관계입니다.

구분	역할	예시
고수준 런타임	이미지 다운로드, 압축 해제, 네트워크/스토리지 구성,저수준 런타임 호출	containerd CRI-O , Docker Engine
저수준 런타임	OS 시스템 콜을 직접 호출하여 실제 격리된 프로세스 생성	runc crun gVisor Kata Containers

예를 들어 docker run 명령어를 입력하면 내부 동작은 다음과 같습니다.

1. 고수준 런타임(containerd)이 레지스트리에서 이미지를 내려받고, 스토리지/네트워크 준비
2. 준비된 OCI 스펙 (JSON 명세서)을 저수준 런타임(runc)에 전달
3. 저수준 런타임(runc)이 리눅스 커널을 이용해서 격리된 공간을 만들고 애플리케이션 프로세스 실행
   

containerd

이 사진은 containerd 내부 아키텍처 및 핵심 컴포넌트 간의 상호작용을 나타낸 사진입니다.(공식 문서)

1. 최상단 인터페이스

   • GRPC : 외부 클라이언트가 containerd와 통신하기 위한 엔드포인트
   • Metrics : 컨테이너 실행 상태, 리소스 사용량, 시스템 통계를 수집하고 모니터링 도구으로 보내는 역할

2. 핵심 서브 시스템

   
   스토리지
   • Content : 이미지 매니페스트, 레이어 tar 파일 등 실제 데이터 블록을 저장
   • Snapshot : 컨테이너가 실행될 때 읽기/쓰기가 가능한 파일시스템 계층을 생성하고 관리
   • Diff : 레이어 간의 파일시스템 차이점을 비교하고 압축을 풀거나 적용하는 작업을 처리
     

   메타데이터

   • Images : 내려받은 컨테이너 이미지의 이름, 태그 등의 메타데이터를 관리
   • Containers: 컨테이너의 논리적 정의(어떤 스냅샷을 사용하는 지, 사용할 OCI 명세서 등)를 유지및 관리
     

   실행 및 이벤트

   • Tasks: 실제로 시스템 위에서 동작하는 컨테이너 프로세스, Containers는 정적 메타데이터이고, Tasks는 실제로 실행중인 인스턴스
   • Events: 컨테이너 생성, 시작, 종료, OOM 등 생명주기 관련 이벤트를 수집, 전파하는 이벤트 버스

3. 하위 계층

   • Runtimes(OCI Runtimes): Tasks가 호출하는 저수준 런타임 (runc 등)
   • OS : 리눅스/윈도우 커널
     

이 컴포넌트를 가지고 실제로 실행 중인 프로세스는 containerd 데몬입니다.

이 containerd 데몬이 자체적으로 할 수 있는 일은 다음과 같습니다.

1. 이미지 Pull
   

레지스트리에서 OCI/Docker 이미지를 받아올 수 있습니다.

 Registry
   │
   │ pull
   ▼
containerd
   │
   ▼
Content Store

2. 이미지 관리
   

받아온 이미지의 메타데이터와 콘텐츠를 관리할 수 있습니다.

nginx:latest

manifest
   │
   ├── config
   └── layers
        ├── layer A
        ├── layer B
        └── layer C

3. 컨테이너 생성/삭제
   

Container 객체를 관리할 수 있습니다.

여기서 말하는 Container는 실행 중인 프로세스와의 별개의 개념으로 설정/메타데이터를 담는 객체를 말합니다.

Container
   │
   │ 실행
   ▼
Task
   │
   ▼
Process 

Task가 실제 실행되는 컨테이너를 말합니다.

4. 실제 컨테이너 프로세스 실행

runc 런타임을 호출해서 OCI 런타임 사양에 맞게 실제 격리된 프로세스를 생성합니다.

runc 는 실제 격리된 프로세스를 생성하고 그 즉시 사라집니다.

그 후 실제 격리된 프로세스와 Contianerd 사이에서 중요한 역할을 하는 것이 containerd-shim 입니다.

5. 컨테이너 라이프사이클 관리

Task의 라이프사이클을 관리합니다.

컨테이너의 라이프사이클을 간단히 말하면 다음과 같습니다.

create
  ↓
start
  ↓
running
  ↓
kill / stop
  ↓
delete

6. Snapshot 관리

컨테이너가 사용할 파일 시스템을 준비합니다.

주로 overlayfs 파일 시스템을 사용합니다.

ctr

ctr는 containerd를 직접 제어하고 디버깅하기 위해 제공되는 CLI입니다.

containerd 데몬과 gRPC로 통신합니다.

특징

• 네임스페이스 기반 격리
• 낮은 수준의 수동 제어: docker run 하나로 끝내는 작업을 이미지 pull -> container 생성 -> Task 시작 단계로 구분하여 동작
• 제한된 사용자 편의 기능
  

주요 명령어

1. 네임스페이스

# 현재 containerd 내 네임스페이스 목록 조회
ctr ns ls

2. 이미지 관리

# 이미지 다운로드 (전체 경로 필요)
ctr images pull docker.io/library/nginx:latest
# 로컬 이미지 목록 확인
ctr images ls
# 이미지 삭제
ctr images rm <이미지명>

3. 컨테이너 & 태스크 실행/관리

# 정의된 컨테이너 목록 조회
ctr container ls
# 실제로 실행 중인 프로세스 목록 조회
ctr task ls
# 컨테이너 생성 및 백그라운드 태스크로 실행
ctr run -d docker.io/library/nginx:latest my_nginx
# 실행 중인 태스크 강제 종료
ctr task kill my_nginx
# 컨테이너 메타데이터 삭제
ctr container rm my_nginx

---

OCI

OCI (Open Container Initiative)는 컨테이너 기술의 특정 벤더(도커) 종속성을 없애고 상호 호환성을 유지하기 위해 만든 오픈 컨테이너 표준 기구입니다.

3대 표준 스펙

1. Runtime Spec (런타임 명세)
   • 컨테이너 라이프사이클과 실행 환경을 정의
2. Image Spec (이미지 명세)
   • 컨테이너 이미지를 패키징하는 규격 정의
   • 어떤 도구로 빌드하든 OCI 규격을 따르면 모든 OCI 호환 런타임에서 구도 가능
3. Distribution Spec (배포 명세)
   • OCI 이미지를 레지스트리에 Push/Pull하고 검색하기 위한 HTTP API 표준 규격