Compute2026년 7월 13일

Kata 컨테이너 기술 이해

#kata-containers#kubernetes#isolation#microvm

KVM이 제공하는 하드웨어 보조 가상화 위에서 컨테이너의 민첩성과 VM의 강력한 보안을 결합하려는 업계의 첫 번째 본격적인 시도가 Kata 컨테이너이다. 클라우드 네이티브 생태계에 익숙한 엔지니어라면 Vantisso의 실행 모델을 보고 자연스럽게 이런 질문을 던질 수 있다. "이미 Kubernetes 표준으로 자리 잡은 보안 컨테이너인 Kata 컨테이너를 쓰면 되지 않는가?" 이 글은 그 질문에 대한 답이다. Kata 컨테이너의 설계 철학과 내부 동작 구조를 짚고 AI 에이전트 워크로드를 실행할 때 드러나는 한계를 분석한다.

설계 철학: "컨테이너를 VM처럼"

Kata 컨테이너의 핵심 철학은 사용자에게는 일반 컨테이너처럼 보이게 하고 인프라 내부에서는 가상 머신으로 격리한다는 것이다. 사용자가 Kubernetes에 Pod 배포를 요청하면 Kata 컨테이너는 전통적인 namespace 기반 컨테이너를 띄우는 대신 KVM 기반의 경량 가상 머신을 생성하고 그 가상 머신 내부에 사용자가 요청한 컨테이너 이미지를 실행한다.

가장 주목할 점은 이 모든 과정이 OCI(Open Container Initiative) 표준을 완벽하게 준수한다는 것이다. 개발자는 애플리케이션 이미지도, 매니페스트 본문도 손댈 필요가 없다. 실행할 런타임을 지정하는 한 줄이면 충분하다.

apiVersion: v1
kind: Pod
metadata:
  name: my-agent
spec:
  runtimeClassName: kata   # 이 한 줄로 VM 격리가 적용된다
  containers:
    - name: app
      image: my-agent:latest

호환성을 극대화하면서도 하드웨어 레벨의 격리를 확보한 절충안이다.

Kata 컨테이너의 내부 동작 구조

이 완벽한 호환성을 구현하기 위해 Kata 컨테이너는 Kubernetes 워커 노드 내부에서 다음과 같은 정교한 중재 과정을 수행한다.

containerd-shim-kata-v2 — Kubernetes의 노드 에이전트(Kubelet)와 컨테이너 런타임(containerd)이 명령을 내리면 Kata 컨테이너의 전용 shim 프로세스가 이를 가로챈다. 이 shim 프로세스는 호스트 OS에서 KVM을 제어하기 위한 VMM을 호출하는 중재자 역할을 한다.
VMM 기동과 게스트 커널 부팅 — QEMU 또는 Cloud Hypervisor 같은 VMM을 실행하여 하드웨어 경계를 생성하고 그 위에 Kata 컨테이너 전용으로 최적화된 게스트 리눅스 커널을 부팅한다.
virtio-fs — 호스트에 존재하는 컨테이너 이미지(rootfs)를 가상 머신 내부에서 읽을 수 있도록 호스트와 게스트 간 고속 파일 시스템 공유 기술인 virtio-fs를 통해 디스크를 마운트한다.
vsock(Virtual Socket) — 호스트의 shim 프로세스와 게스트 내부는 네트워크 스택을 거치지 않는 가상화 전용 통신 채널인 vsock으로 연결된다. 일반 네트워크 경로를 우회하므로 낮은 지연과 높은 보안성을 동시에 확보한다.
kata-agent — 게스트 OS 내부에서 실행되는 kata-agent는 호스트 shim 프로세스의 명령을 수신하는 실행자이다. shim 프로세스가 vsock을 통해 컨테이너 프로세스 실행 명령(gRPC)을 전달하면 kata-agent가 게스트 내부에서 실제 애플리케이션을 구동한다.

이 구조의 핵심 보안 특성은 게스트 내부의 에이전트가 악성 코드를 실행하거나 컨테이너 이탈을 시도하더라도 하드웨어 격리 장벽인 KVM 경계 안에 봉인된다는 것이다. 호스트 OS의 커널에 직접 접근하는 경로가 구조적으로 차단되는 효과가 있다.

Kata 컨테이너가 강한 영역

Kata 컨테이너는 보안이 중요한 멀티 테넌트 클라우드 환경이나 수 시간에서 수일 동안 실행되는 장기 실행(Long-running) 워크로드에 매우 적합하다. Kubernetes 생태계의 방대한 도구들을 그대로 활용할 수 있으며 GPU 패스스루(Pass-through)를 지원하여 LLM 인퍼런스 같은 무거운 AI 모델 서빙 인프라로도 탁월하게 작동한다.

에페메럴 에이전트 워크로드에서 드러나는 두 가지 한계

그러나 즉시 기동하고 순식간에 자원을 반납해야 하는 에페메럴 AI 에이전트 워크로드 앞에서는 두 가지 뚜렷한 한계를 드러낸다.

즉시성의 한계 — Kata 컨테이너는 OCI 표준과 Kubernetes Pod 샌드박스 규격을 맞추기 위해 런타임에 여러 단계를 순차적으로 거쳐야 한다. shim 프로세스 생성 → VMM 기동 → 게스트 커널 부팅 → virtio-fs 마운트 → kata-agent 통신으로 이어지는 이 시퀀스는 통상적으로 1초에서 3초 이상의 콜드 스타트 지연을 발생시킨다. 전통적 VM의 수십 초에 비하면 비약적인 발전이지만 사용자의 프롬프트에 즉각 반응하여 수백 밀리초 이내에 다수의 에이전트를 프로비저닝해야 하는 즉시성 기준에는 미치지 못한다.
메모리 오버헤드 — 샌드박스 하나를 기동하려면 게스트 OS의 메모리 외에도 이를 관리하는 containerd-shim 프로세스와 VMM 프로세스가 호스트 측에 상주해야 한다. 샌드박스 하나당 수십 MB 수준의 오버헤드가 발생하기 때문에 고밀도 에이전트 환경에서는 여전히 무거운 부담이다.

Vantisso가 다른 길을 택한 이유

결국 Kata 컨테이너는 Kubernetes 호환성이라는 거대한 장점을 얻기 위해 에이전트 중심 아키텍처가 요구하는 극단적인 민첩성과 경량성을 일정 부분 타협한 모델이다. 두 설계 모두 옳다. 다만 최적화 대상이 다를 뿐이다. Kata 컨테이너는 기존 컨테이너 워크로드를 그대로 둔 채 격리를 강화하는데 Vantisso는 에이전트 작업 하나를 띄우고 지우는 일을 가장 빠르고 가볍게 하는 데 초점을 둔다.

에페메럴 AI 에이전트 플랫폼은 Kubernetes 호환성을 위한 shim, OCI, K8s 계층을 걷어내고 실행 그 자체에만 집중하는 미니멀한 설계를 요구한다. Vantisso가 스냅샷 콜드 복원 200ms, 웜 풀 기동 2ms를 낼 수 있는 것도 이 계층들을 처음부터 두지 않았기 때문이다. 다음 글에서는 이 모든 계층을 제거하고 격리와 민첩성의 교차점을 찾아낸 Firecracker MicroVM의 내부 구조를 해부해 본다.

← Blog