[Container] cgroups + namespaces: 컨테이너의 두 기둥
cgroups, namespaces, cgroup v2, PID namespace, network namespace, mount namespace, user namespace, Linux container internals
정의
컨테이너 = namespaces + cgroups + 파일시스템 (overlay). VM 이 아니라 host 의 프로세스 + 격리.
flowchart LR
Container[Container]
Container --> NS["Namespaces<br/>(격리)"]
Container --> CG["cgroups<br/>(자원 제한)"]
Container --> FS["Overlay FS<br/>(layered FS)"]
Namespaces (격리)
| Namespace | 격리 대상 |
|---|---|
pid | 프로세스 ID (안에서 PID=1) |
mnt | 파일시스템 마운트 |
net | 네트워크 인터페이스, 라우팅, 방화벽 |
uts | hostname, domain |
ipc | System V IPC, POSIX msg queue |
user | UID/GID 매핑 (root in container ≠ root in host) |
cgroup | cgroup root |
time | clock |
# 새 namespace 에서 명령 실행
unshare --pid --mount --net --fork bash
cgroups (자원 제한)
flowchart TB
Root[/sys/fs/cgroup/]
Root --> ContainerA[container-a/]
Root --> ContainerB[container-b/]
ContainerA --> CPU["cpu.max = 50000 100000<br/>(50% CPU)"]
ContainerA --> Mem[memory.max = 512M]
ContainerA --> IO[io.max = read 100MB/s]
ContainerB --> CPU2[cpu.max = 200000 100000]
ContainerB --> Mem2[memory.max = 2G]
| Controller | 제한 |
|---|---|
cpu | CPU 시간 |
memory | RAM + swap |
io | block I/O |
pid | 프로세스 수 |
network (BPF) | NIC bandwidth |
hugetlb | huge pages |
cgroup v1 vs v2
| v1 | v2 | |
|---|---|---|
| 출시 | 2007 | 2016 |
| 계층 | controller 별 다수 | 단일 통합 계층 |
| 권장 | legacy | 모든 현대 distro |
Ubuntu 22.04+, Fedora 31+, K8s 1.25+ 가 cgroup v2 기본.
OCI Runtime spec 에서
{
"linux": {
"namespaces": [
{ "type": "pid" },
{ "type": "network" },
{ "type": "ipc" },
{ "type": "uts" },
{ "type": "mount" }
],
"resources": {
"memory": { "limit": 536870912 },
"cpu": { "shares": 1024, "quota": 50000, "period": 100000 }
}
}
}
OOM kill (cgroup memory)
sequenceDiagram
Container->>OS: allocate memory (RAM 부족)
OS-->>Container: ENOMEM 또는 OOM kill
Note over OS: cgroup memory.max 초과
OS->>Container: SIGKILL (즉시)
CAUTION
Memory limit 초과 = SIGKILL (graceful 없음). 애플리케이션이 준비 안 됨. limit 보수적으로.
User Namespace
container 내부 root (uid 0)
host: uid 100000 (제한된 일반 사용자)
컨테이너 내부 root 가 host root 아님. 보안 강화. rootless container (podman) 의 토대.
OverlayFS
lowerdir (read-only): image layers
upperdir (read-write): container 변경
merged: 통합 view
Layered FS 의 append-only 동작 직관 (Linked list 의 읽기 시 위에서 아래로 와 유사).
흔한 함정
WARNING
--privileged= 모든 namespace 해제. 컨테이너 의미 없음. capabilities 만 추가.- 호스트 PID/IPC/Network 공유 = 컨테이너 = host process. 격리 없음.
- CPU limit 의 throttle = container 가 느려짐 (kill 아님). 메트릭으로 확인.
- Memory limit 너무 작음 = OOM kill 반복. 측정.
관련 위키
이 글의 용어 (4개)
- [Container] Docker: image, layer, registryvirtualization
- 정의 Docker = 컨테이너 빌드 + 실행 + 배포 의 표준 도구. 2013 출시 → 컨테이너 시대 의 시작. 현재는 OCI 표준 으로 진화 ( , , 등 호환). Layere…
- [Container] Image Best Practices: 작게, 안전하게virtualization
- 5가지 원칙 1. Base Image 선택 | Base | 크기 | 적합 | |---|---|---| | | 70 MB | 개발 / 디버깅 친화 | | | 40 MB | 일반 |…
- [Container] OCI Image: spec, manifest, layer 표준cloud
- 정의 OCI (Open Container Initiative) = 컨테이너 표준 (Linux Foundation, 2015). image format + runtime + dis…
- [K8s] Pod: 컨테이너의 최소 단위, sidecar, lifecyclekubernetes
- 정의 Pod = K8s 의 가장 작은 배포 단위. 1개 이상의 컨테이너 + 공유 네트워크 + 공유 스토리지. [!IMPORTANT] Pod 는 컨테이너의 wrapping 이 아니…
이 개념을 다룬 위키 페이지 (7)
- wiki[Container] OCI Image: spec, manifest, layer 표준
- wiki[K8s] Pod: 컨테이너의 최소 단위, sidecar, lifecycle
- wiki[Container] Image Best Practices: 작게, 안전하게
- wiki[Container] Docker: image, layer, registry
- wikiLXC / LXD: System Containers, Docker 이전의 컨테이너
- wiki가상화 (Virtualization): 하드웨어, OS, 컨테이너 계층 전체 정리
- wikiVM vs Container: 층 구조, 성능, 격리 완벽 비교
💬 댓글