도커(Docker)의 단점과 카타 컨테이너(Kata Containers)

컨테이너 기술의 표준으로 자리 잡은 도커는 현대 개발 환경에서 필수적인 도구이다. 가볍고 빠르며 배포가 쉽다는 강력한 장점이 있지만, 시스템 레벨에서 인프라 구조를 깊이 들여다보면 도커 역시 완벽한 기술은 아니며 명확한 한계를 지니고 있다.
이번 글에서는 도커의 단점과 그 근본적인 원인을 알아보고, 이를 보완하기 위해 등장한 MicroVM 개념과 Kata Containers에 대해 정리해 본다.

1. 도커의 단점: 불완전한 격리

도커는 리눅스의 cgroup과 namespace 기술을 활용해 프로세스를 논리적으로 격리한다. VM처럼 무거운 Guest OS를 띄우지 않아 가볍다는 장점이 있지만, Host OS의 커널을 그대로 공유하기 때문에 다음과 같은 치명적인 단점들이 발생한다.

• 보안 취약점 (Docker Container Escape): 컨테이너는 물리적으로 완전히 분리된 것이 아니라 커널을 공유한다. 따라서 악의적인 공격자가 특정 컨테이너 내부에서 커널의 취약점을 공략해 권한을 상승시키면, 격리된 환경을 뚫고 나와 Host OS 전체와 다른 컨테이너들까지 장악해 버리는 컨테이너 이스케이프 현상이 발생할 수 있다.
• 장애 전파 범위의 확대: 호스트 서버의 커널에 문제가 생기면 그 커널을 공유하는 모든 컨테이너가 동시에 영향을 받는다. 특정 컨테이너 하나가 커널 패닉을 유발하는 에러를 발생시킬 경우, 시스템 전체가 다운되는 큰 장애로 이어질 위험이 있다.
• 운영체제 종속성: 리눅스 커널의 핵심 기능을 사용하기 때문에, 기본적으로 리눅스 환경에서만 네이티브하게 작동한다. 윈도우나 맥OS 등 다른 운영체제에서는 도커를 직접 구동할 수 없으며, 별도의 가상화 레이어를 반드시 거쳐야 한다.

2. 도커의 단점을 보완하는 대체 기술: MicroVM

도커의 이러한 한계, 특히 보안과 격리 문제를 극복하기 위해 등장한 개념이 바로 MicroVM이다.
MicroVM이란 기존 VM에서 플로피 디스크 컨트롤러나 불필요한 디바이스 드라이버 등 무거운 하드웨어 에뮬레이션 기능을 모두 생략한 초경량 가상 머신 아키텍처를 뜻한다.

• 불필요한 기능이 생략돼 부팅 속도가 밀리초 단위로 아주 빠르다.
• 각 컨테이너가 하드웨어 수준에서 완전히 분리된 독립적인 게스트 커널을 가지기 때문에, 특정 컨테이너에서 보안 사고가 발생하거나 치명적인 에러가 생겨도 호스트 OS나 다른 컨테이너에는 영향을 주지 않는다.

즉, 도커의 가벼움과 VM의 보안성이라는 두 마리 토끼를 잡기 위해 고안된 개념이다.

3. Kata Containers

 
이러한 마이크로 가상 머신을 도커 생태계에서 그대로 사용할 수 있게 만들어주는 기술이 카타 컨테이너이다.
일반적인 도커는 내부적으로 runc라는 표준 런타임을 사용하여 호스트 커널을 공유하는 방식으로 컨테이너를 실행한다. 카타 컨테이너는 이 runc를 1:1로 대체하는 런타임으로, 기존 도커 이미지를 수정 없이 그대로 실행할 수 있는 호환성을 제공한다.
도커 엔진 설정에서 기본 런타임을 카타 컨테이너로 변경하면, 컨테이너 배포 시 카타 컨테이너가 내부적으로 마이크로 가상 머신을 짧은 시간 안에 생성하고 그 안에 컨테이너를 실행한다. 관리자 입장에서는 기존 도커 명령어를 그대로 사용하면서도, 도커의 단점을 보완할 수 있다.

위 그림을 보면 기존 컨테이너와 카타 컨테이너의 구조적 차이를 한눈에 알 수 있다.

• 기존 컨테이너 구조: 오른쪽 구조를 보면 프로세스 A, B, C가 각각 네임스페이스와 seccomp, MAC, CAPS 같은 보안 필터를 가지고 격리되지만, 모두 하단의 단일 호스트 커널을 공유하고 있다. 격리가 네임스페이스와 cgroup에 의존하는 논리적 격리 수준이다.
• 카타 컨테이너 구조: 왼쪽 구조를 보면 카타 컨테이너는 각 프로세스가 독립적인 Virtual Machine에 속해 있다. 가장 핵심적인 차이점은 각 VM 내부에 컨테이너 전용의 개별 게스트 커널이 존재한다는 점이다.

이 개별 게스트 커널은 그 아래의 Hardware Virtualization 레이어를 통해 호스트 커널과 물리적으로 격리된다. 이는 단순히 프로세스를 논리적으로 분리하는 수준을 넘어, 하드웨어 가상화 기술을 기반으로 완벽한 물리적 격리를 제공한다.

4. 실습

1단계: 하드웨어 가상화(KVM) 지원 여부 확인

가장 먼저 현재 우분투 가상 머신이 또 다른 가상 머신(MicroVM)을 생성할 수 있는 상태인지 확인해야 한다. 우분투 바탕화면에서 터미널을 열고 아래 명령어를 입력한다.

grep -Ec '(vmx|svm)' /proc/cpuinfo

이 명령어의 출력 결과가 1 이상이라면 중첩 가상화가 정상적으로 활성화된 것이다. 만약 0이 나온다면 가상 머신을 끄고 버추얼박스 프로세서 설정에서 네스티드 VT 옵션을 다시 확인해야 한다. 나의 경우 네스티드 VT 옵션을 활성화가 안돼서 호스트 pc의 가상화 옵션을 수정하고 cmd로 직접 활성화 명령어를 통해 활성화해주었다.

2단계: 도커(Docker) 기본 엔진 설치

카타 컨테이너를 실행하기 위한 기본 뼈대인 도커 엔진을 설치한다. 패키지 목록을 최신화한 뒤 도커를 설치하는 과정이다.

sudo apt-get update
sudo apt-get install -y docker.io

설치가 완료되면 가상 머신이 켜질 때마다 도커가 자동으로 실행되도록 시스템 서비스에 등록해 준다.

sudo systemctl enable --now docker

3단계: 카타 컨테이너 런타임 설치

아래 명령어를 입력하여 설치를 진행한다.

# 1. 스크립트 다운로드
https://github.com/kata-containers/kata-containers/releases/download/3.28.0/kata-static-3.28.0-amd64.tar.zst

# 2. 실행 권한 부여
sudo chmod +x kata-manager.sh

# 3. 카타 컨테이너 설치
sudo ./kata-manager.sh -o

4단계: 도커 설정 파일에 카타 런타임 등록

이제 도커가 기본 런타임(runc) 외에 카타 컨테이너라는 새로운 런타임을 인식할 수 있도록 설정 파일을 만들어 주어야 한다. 나노(nano) 편집기를 열어 설정 파일을 생성한다.

sudo nano /etc/docker/daemon.json

편집기 화면이 열리면 아래의 JSON 코드를 복사해서 그대로 붙여넣기 한다.

{
  "runtimes": {
    "kata-runtime": {
      "path": "/snap/bin/kata-containers.runtime"
    }
  }
}

작성을 마쳤다면 Ctrl + O 를 누르고 Enter 를 쳐서 저장한 뒤, Ctrl + X 를 눌러 편집기를 빠져나온다. 이후 수정한 설정이 바로 반영되도록 도커 데몬을 재시작한다.

Bash

 

sudo systemctl restart docker

5단계: 일반 도커 컨테이너 커널 확인 

모든 준비가 끝났다. 먼저 도커의 기본 런타임으로 우분투 컨테이너 3개를 연속으로 띄우고 커널 버전을 확인해 본다. 터미널에 아래 명령어들을 한 줄씩 차례대로 입력한다. 

sudo docker run --rm ubuntu uname -r
sudo docker run --rm ubuntu uname -r
sudo docker run --rm ubuntu uname -r

출력된 세 줄의 결과를 캡처해 둔다. 결과를 보면 호스트 리눅스 서버와 완전히 똑같은 커널 버전이 연속해서 나타난다. 이는 세 개의 컨테이너가 단 하나의 호스트 커널을 공유하고 있음을 증명한다.

6단계: 카타 컨테이너 커널 확인 

sudo docker run --rm --runtime=kata-runtime ubuntu uname -r

- 이상하게 자꾸 에러가 나서 확인을 못했다ㅜㅜ 하지만 결과가 제대로 나온다면, 위 도커 커널과 다른 커널 버전이 결과로 나올 것이다.

---

결론적으로, 카타 컨테이너를 사용하면 도커의 편리한 생태계를 그대로 누리면서도, 내부적으로는 각 컨테이너가 독립적인 커널을 가지는 보안 환경을 구축할 수 있다.
도커는 일반적인 마이크로서비스 배포에 여전히 훌륭한 도구이다. 하지만 여러 사용자의 코드가 섞여 돌아가는 멀티 테넌트 환경이나, 고도의 보안이 요구되는 시스템에서는 한계가 명확하다. 인프라를 설계할 때는 시스템의 목적에 맞춰 단순한 컨테이너 격리를 사용할지, 아니면 MicroVM 기반의 강력한 격리 기술을 도입할지 판단하는 시각이 필요할 것이라 생각한다.