84. 컨테이너 런타임 (Container Runtime)

⚠️ 이 문서는 쿠버네티스(Kubernetes)가 "컨테이너를 하나 띄워라"라고 고수준의 명령을 내렸을 때, 실제로 리눅스 커널(Namespace, Cgroups)과 통신하며 컨테이너 이미지를 다운받고 격리된 공간에서 **프로세스를 직접 구동시키는 실질적인 하위 작업자이자 심장인 '컨테이너 런타임(예: containerd, CRI-O)'**을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 쿠버네티스는 오케스트레이션(지휘)만 할 뿐, 컨테이너를 직접 실행할 줄 모른다. 컨테이너를 돌리는 진짜 엔진은 각 노드(서버) 바닥에 깔려있는 이 '컨테이너 런타임'이라는 별도의 소프트웨어다.
  2. 가치: 과거에는 도커(Docker)라는 무거운 통짜 엔진 하나에 완벽히 종속되어 있었으나, 런타임 표준(CRI)이 확립되면서 도커를 버리고 훨씬 가볍고 빠르며 보안이 뛰어난 containerd나 CRI-O 같은 다양한 런타임을 입맛에 맞게 골라 쓸 수 있게 되었다.
  3. 기술 체계: 쿠버네티스의 명령을 받는 '고수준 런타임(containerd)'과, 실제로 리눅스 커널을 조작해 프로세스를 가두는 '저수준 런타임(runc)'의 2단계 계층 구조로 분리되어 완벽한 역할 분담을 이룬다.

Ⅰ. 쿠버네티스와 도커(Docker)의 결별 사태

모든 컨테이너가 '도커'라고 불리던 시대는 끝났다.

  1. 도커의 비대함 (Monolithic):
    • 과거 쿠버네티스는 컨테이너를 띄우기 위해 오직 도커(Docker Engine)만 사용했다.
    • 하지만 도커는 단순히 컨테이너를 실행하는 기능 외에도 이미지 빌드, 볼륨 관리, 네트워크 등 개발자 편의를 위한 수많은 잡다한 기능이 뭉쳐져 있는 무거운 '통짜(Monolithic)' 프로그램이라 서버 리소스를 많이 잡아먹었다.
  2. CRI (Container Runtime Interface) 표준의 등장:
    • 쿠버네티스는 무거운 도커와 결별하기로 마음먹었다. "앞으로 나는 'CRI 표준 규격'으로만 명령을 내릴 테니, 내 명령만 알아듣는다면 도커든 뭐든 어떤 가벼운 엔진을 쓰든 상관 안 하겠다"라고 선언했다.
  3. Dockershim의 제거 (v1.24):
    • 도커는 이 CRI 표준을 지원하지 않아서, 쿠버네티스가 중간에 통역기(Dockershim)를 달고 억지로 써오다가 결국 버전 1.24부터 이 통역기를 아예 삭제해 버렸다. 이로써 쿠버네티스 클러스터에서 런타임으로서의 도커는 완전히 퇴출당했다.

📢 섹션 요약 비유: 과거 쿠버네티스 사장님은 '도커'라는 엄청난 만능 비서를 썼습니다. 하지만 커피 타기, 문서 번역 등 불필요한 재주가 너무 많아 월급만 비싸자, 사장님은 "앞으로 타이핑(CRI) 규격 시험을 통과한 싸고 빠른 타자 전문 타자수(containerd 등)만 고용하겠다"며 도커 비서를 해고해 버린 역사적 사건입니다.

Ⅱ. 고수준 런타임과 저수준 런타임의 분업

우리가 흔히 말하는 런타임은 두 명의 작업자로 나뉘어 있다.

  1. 고수준 런타임 (High-level Runtime: containerd, CRI-O):
    • 쿠버네티스(Kubelet)의 명령을 직접 받는 매니저다.
    • 레지스트리(Docker Hub 등)에서 이미지를 Pull해서 다운받고, 이미지의 압축을 풀며, 컨테이너의 생명주기를 전반적으로 관리한다. (도커에서 '핵심 엔진' 부분만 쏙 빼내어 독립시킨 것이 containerd 다)
  2. 저수준 런타임 (Low-level Runtime: runc, gVisor):
    • 고수준 런타임의 지시를 받아 **실제 험한 일(리눅스 커널 조작)**을 하는 현장 반장이다.
    • 리눅스의 Namespace(보이지 않는 벽 치기)와 Cgroups(CPU/메모리 할당량 조절) 기술을 이용해 프로세스를 완벽히 격리된 방(컨테이너)에 가두고 전원(프로세스)을 켜는 역할만 딱 수행하고 쿨하게 퇴장한다. (표준 규격: OCI)

📢 섹션 요약 비유: 쿠버네티스(사장)가 "매장 오픈해!"라고 지시하면, 고수준 런타임(매니저)이 본사에서 간판(이미지)을 떼 와서 세팅을 준비하고, 저수준 런타임(현장 인부)에게 "벽돌(커널)로 여기 벽을 쳐서 빈 공간을 만들어"라고 지시하여 실제 물리적인 공간(컨테이너)을 확보하는 철저한 수직적 분업 체계입니다.

Ⅲ. 차세대 런타임 보안: 격리의 한계 돌파 (gVisor, Kata)

runc의 논리적 격리벽은 해커에게 뚫릴 위험이 있다.

  1. 공유 커널(Shared Kernel)의 치명적 약점:
    • 일반적인 컨테이너(runc)는 리눅스 커널을 숙주(Host) OS와 공유한다.
    • 만약 컨테이너 안으로 들어온 해커가 커널 자체의 취약점을 공격하면, 컨테이너 벽을 뚫고(Container Escape) 숙주 서버 전체와 옆 컨테이너들까지 장악해 버린다.
  2. 샌드박스 런타임 (gVisor, Kata Containers):
    • 이런 위험을 막기 위해 극강의 보안이 필요한 금융권 등에서는 일반적인 runc 대신 특수한 저수준 런타임을 쓴다.
    • gVisor (구글 제작): 컨테이너와 커널 사이에 가짜 커널(게스트 커널)을 층으로 깔아두어 해커의 명령을 중간에서 모두 튕겨낸다.
    • Kata Containers: 아예 컨테이너 하나당 아주 작고 가벼운 가상 머신(MicroVM)을 하나씩 띄워서 하드웨어 수준으로 벽을 쳐버린다.

📢 섹션 요약 비유: 일반 런타임(runc)은 얇은 합판으로 방을 나눈 셰어하우스라서 한 방에 폭탄(해커)이 터지면 옆방까지 다 날아갑니다. 반면 gVisor나 Kata 같은 특수 런타임은 방과 방 사이에 두꺼운 티타늄 장갑판을 덧대거나 아예 방을 별도의 독채 건물로 지어버려(샌드박스), 한 놈이 죽어도 절대 옆으로 피해가 번지지 않는 완벽한 방호벽을 제공합니다.