컨테이너가 뭐길래? - namespace, cgroup, CRI, kubelet 쉽게 이해하기

🤖 AI Assisted Content
이 글은 AI(Claude, Anthropic)의 도움을 받아 작성되었습니다.
작성자가 내용을 검토하고 편집했으나, AI가 초안 작성 및 구성에 참여했음을 밝힙니다.

들어가며

Kubernetes를 공부하다 보면 "Pod는 쿠버네티스가 관리하고, 컨테이너는 외부에서 관리된다"라는 설명을 만나게 됩니다. Pod 안에 컨테이너가 있는데, 컨테이너는 외부에서 관리된다니 — 처음 보면 꽤 혼란스럽습니다.

이 글에서는 이 말이 무슨 뜻인지, 그리고 컨테이너라는 기술이 어떤 원리로 동작하는지를 namespace, cgroup, CRI, kubelet 네 가지 키워드로 풀어보겠습니다. VM과의 차이점까지 비유와 함께 정리했으니, 컨테이너의 핵심 원리를 한번에 잡아갈 수 있을 겁니다.

---

1. Pod와 컨테이너 — 누가 뭘 관리하는가

Kubernetes의 가장 작은 배포 단위는 Pod입니다. Pod 안에 컨테이너가 들어 있죠. 그런데 Kubernetes가 직접 컨테이너를 만들지는 않습니다. 컨테이너를 실제로 생성하고 실행하는 건 해당 노드에 설치된 컨테이너 런타임(containerd, CRI-O 등)의 몫입니다.

비유하면, Kubernetes는 택배 회사 본사이고 컨테이너 런타임은 현장 배송 기사입니다. 본사는 "이 물건을 이 주소로 보내라"는 주문서(Pod 스펙)를 만들고 추적하지만, 실제로 물건을 들고 뛰는 건 배송 기사입니다.

Kubernetes 세계 (추상화)        |  실제 실행 세계
                               |
  Pod Spec (desired state)     |
       ↓                       |
  kubelet (노드 에이전트)       |
       ↓ CRI API 호출          |
  ─────────────────────────────|──────────────────
                               |  containerd / CRI-O
                               |       ↓
                               |  실제 컨테이너 프로세스
                               |  (namespace + cgroup 적용)

Kubernetes가 직접 아는 건 Pod라는 추상화 단위까지입니다. "컨테이너 프로세스를 생성하고 격리하는" 실제 저수준 작업은 런타임이 처리합니다. Pod가 컨테이너를 추상화한 이유가 여기에 있습니다. Pod는 Kubernetes가 관리하는 리소스이고, 컨테이너는 Kubernetes 외부(런타임)에서 관리됩니다.

---

2. kubelet — 모든 노드에 상주하는 현장 매니저

kubelet은 모든 워커 노드에 하나씩 설치되는 에이전트 프로그램입니다.

Kubernetes 클러스터가 회사라면, kubelet은 각 지점에 상주하는 현장 매니저입니다. 본사(Control Plane)에서 "이 노드에서 Pod를 실행해"라는 지시가 내려오면, kubelet이 받아서 컨테이너 런타임에게 실제 작업을 시킵니다.

kubelet이 하는 일을 정리하면 이렇습니다:

• API Server로부터 Pod 스펙을 수신
• 컨테이너 런타임에게 CRI API로 컨테이너 생성 요청
• 컨테이너가 잘 돌고 있는지 주기적으로 상태 체크 (liveness/readiness probe)
• 컨테이너가 죽으면 restartPolicy에 따라 재시작 요청
• 노드의 CPU/메모리 상태를 API Server에 보고

API Server: "노드 A에 nginx Pod 띄워"
     ↓
kubelet (노드 A에 상주): "알겠습니다"
     ↓ CRI 호출
containerd: 실제로 nginx 컨테이너 프로세스 생성

kubelet은 Pod의 생명주기 전체를 책임지는 노드 측 관리자이고, 실제 컨테이너 조작은 항상 런타임에게 위임합니다.

---

3. CRI — kubelet과 런타임 사이의 표준 계약서

그러면 kubelet은 어떻게 컨테이너 런타임과 소통할까요? 여기서 등장하는 게 CRI(Container Runtime Interface)입니다.

CRI는 kubelet과 컨테이너 런타임 사이의 표준 API 규격입니다. USB 포트 규격처럼, 규격만 맞으면 어떤 장치든 꽂을 수 있는 것과 같습니다.

kubelet ──── CRI (gRPC API) ────→ containerd
kubelet ──── CRI (gRPC API) ────→ CRI-O
kubelet ──── CRI (gRPC API) ────→ 어떤 런타임이든

CRI가 정의하는 핵심 서비스는 두 가지입니다:

서비스	역할	주요 메서드
RuntimeService	컨테이너 생명주기 관리	CreateContainer, StartContainer, StopContainer, RemoveContainer, ContainerStatus
ImageService	컨테이너 이미지 관리	PullImage, ListImages, RemoveImage

kubelet은 이 표준 API만 호출하면 되니까, 뒤에 containerd가 있든 CRI-O가 있든 신경 쓸 필요가 없습니다.

💡 포인트: "파드 실행 중에는 노드가 컨테이너 런타임과 연동하며, 파드에 필요한 모든 컨테이너가 갖추어져 있는지 확인한다"는 말은, kubelet이 주기적으로 CRI를 통해 런타임에게 "이 Pod의 컨테이너 상태가 어때?"라고 물어보고, 죽은 컨테이너가 있으면 "다시 만들어줘"라고 요청하는 reconciliation loop를 뜻합니다.

---

4. namespace — "뭘 볼 수 있는가"를 격리

여기서부터가 컨테이너 기술의 진짜 핵심입니다. 컨테이너는 사실 특별한 마법이 아니라, Linux 커널이 제공하는 namespace와 cgroup 두 가지 기능을 조합한 것입니다.

namespace가 없는 세상

Linux 서버 한 대에 프로세스 3개가 돌고 있다고 해봅시다.

Linux 서버 (커널 1개)
├── nginx    (PID 100)
├── mysql    (PID 200)
└── redis    (PID 300)

이 상태에서 nginx 안에서 ps aux를 치면 mysql, redis 프로세스가 다 보입니다. 네트워크도 파일시스템도 공유합니다. nginx가 해킹당하면 mysql 데이터까지 접근할 수 있죠.

namespace를 적용하면

같은 서버인데, 각 프로세스에게 눈가리개를 씌웁니다.

Linux 서버 (커널 1개, 실제 현실)
├── nginx    (실제 PID 100)
├── mysql    (실제 PID 200)
└── redis    (실제 PID 300)

nginx가 보는 세상 (PID namespace 적용):
  └── nginx (PID 1) ← 자기가 유일한 프로세스인 줄 앎. mysql? redis? 모름.

mysql이 보는 세상 (PID namespace 적용):
  └── mysql (PID 1) ← 자기가 유일한 프로세스인 줄 앎. nginx? redis? 모름.

실제로는 같은 커널 위에 있는데, 각자 자기만의 PID 1번을 갖고 다른 프로세스의 존재 자체를 모릅니다.

Network namespace도 같은 원리

namespace 없이는 서버에 IP가 하나(192.168.1.10)이고 모든 프로세스가 공유합니다. nginx가 80번 포트를 쓰면 mysql은 80번을 못 씁니다.

Network namespace를 적용하면 각자 별도의 가상 네트워크 카드를 갖습니다:

nginx의 네트워크 세상:  IP 172.17.0.2, 포트 80 사용 중
mysql의 네트워크 세상:  IP 172.17.0.3, 포트 80 사용 가능 ← 충돌 없음

컨테이너마다 고유한 IP를 가질 수 있는 이유가 바로 이것입니다.

주요 namespace 종류

namespace	격리 대상	효과
PID	프로세스 ID	컨테이너 안에서는 자기 프로세스만 보임
Network	네트워크	컨테이너마다 별도 IP, 포트 공간
Mount	파일시스템	컨테이너마다 독립된 파일시스템 뷰
UTS	호스트명	컨테이너마다 다른 hostname 가능
IPC	프로세스 간 통신	공유 메모리 등 격리
User	사용자 ID	컨테이너 안의 root ≠ 호스트의 root

한마디로 namespace는, 같은 OS 커널 위의 프로세스인데 각자 독립된 컴퓨터에 있는 것처럼 착각하게 만드는 Linux 커널 기능입니다.

---

5. cgroup — "얼마나 쓸 수 있는가"를 제한

namespace가 "뭘 보는가"를 격리한다면, cgroup(Control Group)은 "얼마나 쓰는가"를 제한합니다.

namespace가 사무실의 칸막이라면, cgroup은 각 칸막이에 설치된 전기·수도 사용량 제한기입니다.

제한 대상	예시
CPU	이 컨테이너는 CPU 코어 0.5개분만 사용 가능
메모리	이 컨테이너는 최대 512MB까지만 사용 가능
디스크 I/O	읽기/쓰기 속도 제한
네트워크 대역폭	전송량 제한

Kubernetes에서 Pod 스펙에 작성하는 resources.limits가 바로 이 cgroup 설정으로 변환됩니다:

resources:
  requests:
    memory: "256Mi"    # 스케줄링 기준 (이 만큼은 보장해줘)
    cpu: "250m"
  limits:
    memory: "512Mi"    # cgroup이 실제로 이 한도를 강제
    cpu: "500m"

⚠️ 주의: 메모리 limits를 초과하면 cgroup이 해당 프로세스를 강제 종료합니다. Pod 상태가 OOMKilled로 바뀌는 이유가 바로 이겁니다.

---

6. VM과 컨테이너 — 근본적인 차이

이 모든 내용을 종합하면, VM과 컨테이너의 차이가 명확해집니다.

VM 방식:
┌──────────────────┐  ┌──────────────────┐
│  Guest OS 전체    │  │  Guest OS 전체    │  ← OS를 통째로 하나 더 띄움
│  (커널 포함)      │  │  (커널 포함)      │
│  nginx            │  │  mysql            │
└──────────────────┘  └──────────────────┘
       하이퍼바이저 (ESXi 등)
       물리 서버

컨테이너 방식 (namespace + cgroup):
┌──────────────┐  ┌──────────────┐
│  nginx        │  │  mysql        │  ← 프로세스만 격리
│  (PID 1로 봄) │  │  (PID 1로 봄) │
└──────────────┘  └──────────────┘
       같은 커널 공유               ← OS를 새로 안 띄움
       Linux 서버

VM은 진짜 별도의 컴퓨터를 만드는 것이고, 컨테이너는 하나의 컴퓨터에서 착시를 만드는 것입니다. 그래서 컨테이너가 VM보다 훨씬 가볍고, 몇 초 만에 시작됩니다.

---

정리

개념	한 줄 요약
Pod	Kubernetes가 관리하는 최소 배포 단위. 컨테이너를 추상화
kubelet	모든 노드에 상주하는 에이전트. Pod 스펙을 받아 런타임에게 작업 위임
CRI	kubelet과 컨테이너 런타임 사이의 표준 API. 런타임 종류에 상관없이 동일하게 동작
namespace	프로세스가 뭘 볼 수 있는지 격리. 각자 독립된 환경에 있다고 착각하게 만듦
cgroup	프로세스가 얼마나 자원을 쓸 수 있는지 제한. OOMKilled의 원인
컨테이너	VM이 아니라 namespace + cgroup + 파일시스템 이미지의 조합

컨테이너는 결국 "Linux 커널의 격리 기능을 영리하게 조합한 것"이고, Kubernetes는 이 컨테이너를 Pod라는 추상화로 감싸서 대규모로 관리하는 오케스트레이터입니다. CRI라는 표준 인터페이스 덕분에 런타임이 뭐든 상관없이 동일한 방식으로 동작할 수 있고, kubelet이 각 노드에서 이 모든 것을 중재하는 현장 매니저 역할을 합니다.

---

참고 문서

• Kubernetes - Container Runtime Interface (CRI)
• Kubernetes - Pods
• Kubernetes - kubelet
• Linux man pages - namespaces(7)
• Linux man pages - cgroups(7)