앞 모듈에서 "컨테이너는 커널을 공유하면서도 격리된다"고 배웠습니다. Docker가 이것을 어떻게 구현하는지 봅니다.

컨테이너가 격리된다는 것은 마법이 아닙니다. 리눅스 커널이 오래전부터 제공해온 두 가지 기능을 Docker가 사용하기 쉽게 포장한 것입니다. **네임스페이스(Namespace)**와 **cgroups(Control Groups)**가 그것입니다.

네임스페이스는 "각 컨테이너가 자기만의 세계를 가지게 한다"는 개념입니다. 컨테이너 안에서 보면 자신이 혼자 서버 전체를 쓰는 것처럼 보이지만, 실제로는 같은 커널 위에서 수십 개의 컨테이너가 동시에 동작하고 있습니다. 네임스페이스가 프로세스, 네트워크, 파일시스템 등 커널 자원을 컨테이너마다 독립된 공간으로 분리해주기 때문입니다.

cgroups는 "각 컨테이너가 쓸 수 있는 자원의 양을 제한한다"는 개념입니다. 아무리 격리되어 있어도 CPU나 메모리를 무한정 쓸 수 있으면 한 컨테이너가 서버 전체를 점유할 수 있습니다. cgroups가 각 컨테이너에 자원 상한선을 걸어줍니다.

확대

아래 표는 네임스페이스가 어떤 항목을 격리하는지 정리한 것입니다:

리눅스 네임스페이스 — 컨테이너마다 독립된 세계:

cgroups — 자원 사용량 제한:

cgroups는 docker run 실행 시 --memory, --cpus 플래그로 설정한 제한값을 커널 수준에서 강제합니다.

# 실습 디렉토리 준비
mkdir -p /tmp/docker/part1/exam_4 && cd /tmp/docker/part1/exam_4

# 컨테이너에 메모리와 CPU 제한 적용
docker run --memory=512m --cpus=0.5 nginx

# → 커널이 이 컨테이너 프로세스의 메모리를 512MB로 제한
# → 초과 시 OOM Killer가 컨테이너 프로세스를 종료

이 두 기술(네임스페이스 + cgroups)이 Docker가 컨테이너를 격리하는 핵심 메커니즘입니다. Docker 엔진은 이 기술들을 사용하기 쉽게 포장한 것입니다.

방금 namespace(격리)와 cgroup(제한)을 따로 배웠습니다. 그런데 실제 docker run 한 줄은 이 둘에 **overlayfs 레이어(파일시스템)**까지 더해 세 장치를 순서대로 조립해, '독립된 것처럼 보이는 프로세스' 하나를 만들어 냅니다. 이 조립 순서를 알면 컨테이너가 왜 VM보다 가벼운지(커널을 공유하니까), 그리고 실행이 실패했을 때 어느 조립 단계를 봐야 하는지가 한눈에 보입니다.

docker run --memory=512m --cpus=0.5 nginx
   │
   ① 파일시스템 조립 → overlayfs로 읽기전용 이미지 레이어들 위에
   │                  쓰기 가능 레이어 1장을 얹어 컨테이너의 루트(/)를 만듦
   │
   ② namespace 생성 → clone()으로 pid·net·mnt·uts·ipc(·user) 분리
   │                  → 컨테이너는 자기만의 PID 1·eth0·/ 를 보게 됨
   │
   ③ cgroup 배치 → 이 프로세스를 cgroup에 넣고 CPU 0.5·메모리 512m 상한 기록
   │                  → 커널이 초과 시 스로틀·OOM으로 강제
   │
   ④ 루트 전환 → mnt 네임스페이스 안에서 ①의 overlayfs를 / 로 pivot_root
   │
   ⑤ 프로세스 실행 → 격리·제한된 환경에서 nginx 를 PID 1로 시작
   ▼
[컨테이너]  호스트 커널을 공유하는, 격리된 하나의 프로세스

세 장치가 각각 무엇을 맡고, 없거나 새면 어떻게 되나:

VM과의 근본 차이가 여기서 드러납니다. VM은 하이퍼바이저 위에 게스트 커널을 통째로 올려 부팅하지만, 컨테이너는 위 세 장치로 '격리된 척'하는 하나의 프로세스일 뿐 호스트 커널을 그대로 공유합니다. 그래서 부팅이 없고 수십 ms 만에 뜨며 이미지도 가볍습니다. 대신 커널이 따로 없으니 호스트 커널 버전·cgroup 버전·아키텍처 차이가 컨테이너로 그대로 샙니다. 핵심은 시야(namespace)와 몫(cgroup)이 서로 다른 장치라는 점입니다 — 격리했다고 자원 한도까지 아는 게 아니고, 자원을 제한했다고 시야가 좁아지는 것도 아닙니다.

정리하면 docker run 실패는 이 조립 단계로 좁혀 진단합니다 — 이미지·overlayfs 준비 실패(①), clone()/namespace 생성 실패(②), cgroup 한도 관련(③, OOMKilled·스로틀), 루트 마운트 실패(④, exec 경로 문제로 exit 127/126)입니다.

docker run nginx를 실행하면 CLI부터 실제 프로세스 생성까지 여러 컴포넌트를 거칩니다. 장애가 났을 때 dockerd가 죽었는지, containerd가 문제인지, runc가 실패했는지 구분해야 올바른 지점에서 복구할 수 있습니다. 또한 Kubernetes가 Docker 대신 containerd를 직접 쓰는 이유, 컨테이너 안에서 Docker 소켓을 마운트하면 왜 보안 위험이 되는지도 이 구조에서 이해됩니다. 이 ConceptBlock에서는 Docker 엔진의 계층 구조와 각 컴포넌트의 역할 분리를 다룹니다.

확대

Docker 엔진의 내부 구조

초기 Docker는 단일 모놀리식 바이너리였지만, 현재는 OCI(Open Container Initiative) 표준에 따라 여러 컴포넌트로 분리되어 있습니다. 이 분리는 컨테이너 생태계의 상호 운용성을 높이고 각 레이어가 독립적으로 교체 가능하도록 합니다.

확대

각 컴포넌트의 역할

Docker CLI 사용자가 입력하는 docker run, docker build 등의 명령어를 처리합니다. CLI는 /var/run/docker.sock 유닉스 소켓을 통해 dockerd와 REST API로 통신합니다.

dockerd (Docker Daemon) Docker의 핵심 데몬 프로세스입니다. 다음 역할을 담당합니다:

• Docker API 서버 운영
• Dockerfile 빌드 처리 (docker build)
• Docker 네트워크 관리 (bridge, overlay 등)
• Docker 볼륨 관리
• containerd와의 통신 조율

containerd CNCF(Cloud Native Computing Foundation)에 기증된 독립적인 컨테이너 런타임입니다. Kubernetes도 직접 containerd를 사용합니다. 주요 역할:

• 컨테이너 이미지 pull/push 및 저장소 관리
• 컨테이너 스냅샷 관리 (overlay filesystem)
• 컨테이너 실행/중지/삭제 생명주기 관리

containerd-shim containerd와 실제 컨테이너 프로세스 사이의 중간 프로세스입니다. containerd가 재시작되더라도 실행 중인 컨테이너가 종료되지 않도록 보호하는 역할을 합니다.

runc OCI 런타임 스펙(OCI Runtime Specification)의 참조 구현체입니다. 실제로 다음 작업을 수행합니다:

• Linux 네임스페이스 생성 및 설정
• cgroup 계층 구조 생성 및 리소스 제한 설정
• 컨테이너 루트 파일시스템 마운트 (overlay)
• clone() 시스템 콜로 격리된 프로세스 생성

Docker 소켓과 보안

/var/run/docker.sock은 Docker CLI와 dockerd가 통신하는 Unix 소켓입니다. 이 소켓에 접근하는 것은 사실상 root 권한과 동일하므로, 누가 접근할 수 있는지 확인하는 것이 중요합니다.

# Docker 소켓 파일 확인
ls -la /var/run/docker.sock
# srw-rw---- 1 root docker ... /var/run/docker.sock

/var/run/docker.sock은 docker 그룹에 속한 사용자만 접근할 수 있습니다. 이 소켓에 접근할 수 있다는 것은 사실상 root 권한과 동일한 수준의 권한을 의미하므로, 신뢰할 수 있는 사용자에게만 docker 그룹 멤버십을 부여해야 합니다.

앞에서 네임스페이스가 격리를, cgroups가 자원 제한을 담당한다고 배웠습니다. 이 둘을 하나로 뭉뚱그리면 "격리했으니 알아서 한도 안에서 돌겠지"라는 오해가 생기는데, 여기서 실제 성능·OOM 사고가 나옵니다.

• 네임스페이스가 격리하는 것과 아닌 것: pid·net·mnt 네임스페이스는 프로세스·네트워크·마운트의 '보이는 범위'를 나눕니다. 하지만 /proc/cpuinfo·/proc/meminfo는 커널 전역 정보라 네임스페이스로 가려지지 않습니다. 64코어·256GB 호스트에서 --cpus 1 --memory 512m로 띄운 컨테이너 안에서도 nproc는 64, free는 256GB로 보입니다. cgroup은 '쓸 수 있는 양'을 제한할 뿐 '보이는 숫자'를 바꾸지 않습니다.
• 런타임이 이 거짓말에 속습니다: 코어 수로 스레드풀·워커 수를 자동 결정하는 런타임이 많습니다 — Go의 GOMAXPROCS, nginx의 worker_processes auto, JVM의 가용 프로세서, Node의 워커 풀. 호스트 64코어를 보고 워커 64개를 띄우면, 정작 --cpus 1의 CPU 몫 안에서 64개가 경합해 컨텍스트 스위칭만 늘고 느려집니다. 메모리도 마찬가지로, 호스트 RAM 기준으로 힙·캐시를 크게 잡으면 cgroup 한도를 넘겨 OOMKill이 납니다.
• 한도를 명시하거나 cgroup 인식 런타임으로 메웁니다: 최신 JVM(UseContainerSupport)·최신 Go·Node는 cgroup 한도를 읽어 스스로 맞추기도 하지만, 오래된 버전이나 worker_processes auto는 여전히 호스트를 봅니다. GOMAXPROCS·worker 수·-Xmx·스레드풀 크기를 컨테이너 한도에 맞춰 명시하거나, automaxprocs 같은 보정 라이브러리를 씁니다.
• 왜 이게 패러다임 이야기인가: "컨테이너는 격리된 프로세스"의 정확한 뜻은 '보이는 범위(네임스페이스)'와 '쓸 수 있는 양(cgroup)'이 서로 다른 장치라는 것입니다. 격리와 제한을 별개로 이해해야, 자원 한도를 건 컨테이너가 왜 여전히 호스트 전체를 본다고 착각하고 과다 할당하는지가 설명됩니다.

정리하면 네임스페이스는 '시야'를, cgroup은 '몫'을 다룹니다. 이 둘이 다르다는 걸 알아야 자원 한도가 앱의 자동 튜닝까지 자동으로 바꿔 주지는 않는다는 점을 놓치지 않습니다.

docker exec demo ps aux를 실행했을 때 PID가 1번부터 시작하는 걸 보고 이상하다고 느낀 적 있을 겁니다. 호스트에서 같은 프로세스를 보면 PID가 수만 번대입니다. 같은 프로세스를 두 개의 다른 PID로 보는 이유가 pid 네임스페이스입니다. 네임스페이스의 6가지 유형을 구체적으로 알면 컨테이너 내부에서 보이는 세계가 왜 다른지, 컨테이너가 어느 수준까지 격리되고 어느 수준에서 공유하는지 이해할 수 있습니다. 이 ConceptBlock에서는 각 네임스페이스가 무엇을 격리하는지 실제 명령어로 확인합니다.

확대

컨테이너는 사실 "격리된 프로세스"다

컨테이너의 본질은 VM처럼 별도 OS를 띄우는 것이 아니라, 리눅스 커널의 네임스페이스 기능으로 격리된 프로세스입니다. 네임스페이스가 뭘 격리하는지 구체적으로 알아야 "컨테이너 안에서 보이는 세계"가 왜 다른지 이해됩니다.

pid 네임스페이스 — 프로세스 번호 격리

컨테이너 안에서 보이는 PID와 호스트에서 보이는 PID가 다릅니다.

# 컨테이너 실행
docker run -d --name demo nginx

# 호스트에서 nginx 프로세스 PID 확인 (큰 번호)
docker inspect demo --format '{{.State.Pid}}'
# 예: 12345

# 컨테이너 안에서는 PID 1로 보임
docker exec demo ps aux
# PID   USER     COMMAND
#   1   root     nginx: master process
#  31   nginx    nginx: worker process

컨테이너 밖에서는 PID 12345인데, 컨테이너 안에서는 PID 1입니다. 같은 프로세스를 두 개의 다른 PID 공간에서 보고 있는 것입니다.

net 네임스페이스 — 네트워크 인터페이스 격리

컨테이너는 자신만의 eth0, 라우팅 테이블, iptables를 가집니다.

# 컨테이너 안의 네트워크 인터페이스
docker exec demo ip addr show
# eth0: 172.17.0.2/16  ← 컨테이너 전용 IP

# 호스트의 네트워크 인터페이스 (컨테이너 eth0과 별개)
ip addr show
# eth0: 192.168.1.100/24  ← 호스트 IP
# docker0: 172.17.0.1/16  ← Docker 브릿지

mnt 네임스페이스 — 파일시스템 격리

컨테이너는 호스트와 다른 /(루트) 파일시스템을 봅니다.

# 컨테이너 안의 /
docker exec demo ls /
# bin  boot  dev  etc  lib  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

# 호스트 / 와 내용이 다름 (이미지의 파일시스템)
# 컨테이너가 삭제될 때 이 파일시스템도 사라짐

uts 네임스페이스 — 호스트명 격리

컨테이너는 호스트와 다른 hostname을 가집니다. --hostname 옵션으로 직접 지정하지 않으면 컨테이너 ID 앞 12자리가 자동으로 사용됩니다.

# 컨테이너 안의 hostname
docker exec demo hostname
# a1b2c3d4e5f6  ← 컨테이너 ID 기반 자동 생성

# --hostname 옵션으로 지정 가능
docker run --hostname myapp nginx
docker exec myapp hostname
# myapp

ipc 네임스페이스 — 프로세스 간 통신 격리

공유 메모리(shared memory), 세마포어 등 IPC 리소스가 컨테이너 간 격리됩니다. 컨테이너 A가 만든 공유 메모리를 컨테이너 B는 볼 수 없습니다.

user 네임스페이스 — 사용자 ID 격리 (Rootless Container의 기초)

컨테이너 안의 root(UID 0)는 호스트에서 일반 사용자로 매핑될 수 있습니다. 이 구조를 쓰면 컨테이너가 탈출하더라도 호스트의 root 권한을 바로 얻지 못합니다. 자세한 보안 설정은 docker-security 챕터에서 심화 학습합니다.

네임스페이스 실제 확인

네임스페이스는 /proc/<PID>/ns/ 디렉토리 아래 심볼릭 링크로 존재합니다. 링크가 가리키는 숫자 ID가 같으면 같은 네임스페이스를 공유하고, 다르면 격리된 것입니다.

# 컨테이너 프로세스의 네임스페이스 파일 목록
PID=$(docker inspect demo --format '{{.State.Pid}}')
sudo ls -la /proc/$PID/ns/
# lrwxrwxrwx ... ipc -> ipc:[4026532345]
# lrwxrwxrwx ... mnt -> mnt:[4026532344]
# lrwxrwxrwx ... net -> net:[4026532348]
# lrwxrwxrwx ... pid -> pid:[4026532346]
# lrwxrwxrwx ... uts -> uts:[4026532343]

각 네임스페이스는 고유한 ID를 가지며, 같은 ID면 같은 네임스페이스를 공유하고 있음을 의미합니다.

ubuntu:22.04와 python:3.11 이미지를 따로 pull했는데 두 번째 pull이 유독 빠르게 끝납니다. 'Already exists' 메시지가 표시되며 일부 레이어만 내려받습니다. 두 이미지가 공통 레이어를 공유하기 때문입니다. 이 공유 구조를 이해하면 Dockerfile에서 왜 COPY requirements.txt를 소스코드보다 앞에 두어야 하는지, 컨테이너를 삭제해도 이미지가 남아있는 이유가 자연스럽게 설명됩니다. 이 ConceptBlock에서는 이미지 레이어 구조와 컨테이너 쓰기 레이어의 관계를 다룹니다.

확대

Docker 이미지 = 레이어(Layer)의 스택

Dockerfile 명령어 하나(FROM, RUN, COPY 등)가 실행될 때마다 새로운 읽기 전용 레이어가 생성됩니다. 이미지는 이 레이어들이 쌓인 구조입니다.

docker pull python:3.11-slim 실행 시 터미널 출력:

3.11-slim: Pulling from library/python
a480a496ba95: Pull complete     ← 레이어 1 (Debian 기반)
f3ace1b8ce45: Pull complete     ← 레이어 2 (apt 업데이트)
11d6fdd0e8a7: Pull complete     ← 레이어 3 (Python 설치)
Digest: sha256:abc123...

각 줄이 하나의 레이어입니다.

레이어 공유 — 디스크를 절약하는 방법

같은 베이스 이미지를 쓰는 이미지들은 하위 레이어를 공유합니다.

# ubuntu:22.04 pull
docker pull ubuntu:22.04
# Layers: abc111, abc222, abc333

# python:3.11 pull (ubuntu 기반)
docker pull python:3.11
# abc111: Already exists   ← 이미 있는 레이어는 다운로드 안 함!
# abc222: Already exists   ← 재사용!
# abc333: Already exists   ← 재사용!
# xyz444: Pull complete    ← Python만 새로 받음

이것이 docker pull이 빠른 이유입니다. 디스크에도 중복 없이 한 번만 저장됩니다.

이미지 레이어 확인 명령어

docker history로 이미지를 구성하는 레이어와 각각의 크기를 확인하고, docker system df로 공유 레이어를 반영한 실제 디스크 사용량을 파악할 수 있습니다.

# 이미지의 레이어 히스토리와 각 크기 확인
docker history nginx:alpine
# IMAGE          CREATED       CREATED BY                     SIZE
# abc123def456   2 days ago    CMD ["nginx" "-g" "daemon ...  0B
# <missing>      2 days ago    EXPOSE map[80/tcp:{}]           0B
# <missing>      2 days ago    COPY /etc/nginx /etc/nginx ...  5.47kB
# <missing>      2 days ago    RUN /bin/sh -c apk add --...   15.1MB
# <missing>      2 days ago    FROM alpine:3.19               7.73MB  ← 베이스

# 로컬 이미지 목록과 크기
docker image ls
# REPOSITORY    TAG       IMAGE ID       SIZE
# nginx         alpine    abc123         43.2MB
# python        3.11      def456         230MB

# 전체 디스크 사용량 (공유 레이어 반영한 실제 사용량)
docker system df
# TYPE      TOTAL   SIZE      RECLAIMABLE
# Images    5       520MB     320MB (61%)

컨테이너 = 이미지 + 쓰기 레이어 1개

이미지 레이어는 읽기 전용입니다. docker run으로 컨테이너를 만들면 그 위에 쓰기 가능한 레이어가 하나 추가됩니다. 컨테이너를 삭제하면 이 쓰기 레이어만 사라지고, 이미지 레이어는 그대로 남습니다.

확대

같은 이미지로 컨테이너 10개를 실행해도 이미지 레이어는 공유하고, 쓰기 레이어만 10개 생성됩니다.