격리 경계가 어디에 있는가

한 줄 요약

VM 은 하드웨어 경계로 격리하고 컨테이너는 커널 기능(namespace/cgroup) 으로 격리한다. 이 한 문장에서 나머지 차이가 전부 따라 나온다.

왜 이게 필요했나

"컨테이너를 쓸까 VM 을 쓸까" 는 여전히 자주 나오는 질문이다. 답은 워크로드가 아니라 어떤 종류의 격리가 필요한가로 정해진다.

어떻게 동작하나

[VM]                          [컨테이너]앱                             앱게스트 라이브러리               라이브러리게스트 커널      <- 별개!       (호스트 커널을 공유)가상 하드웨어                   namespace + cgroup하이퍼바이저                    컨테이너 런타임호스트 커널                     호스트 커널

컨테이너는 게스트 커널이 없다. 그래서 시작이 빠르고(수십 ms) 메모리 오버헤드가 거의 없고 밀도가 높다. 대신 커널 취약점 하나가 격리를 통째로 무너뜨린다.

| 항목 | VM | 컨테이너 |
| --- | --- | --- |
| 커널 | 게스트마다 별개 | 호스트와 공유 |
| 시작 시간 | 수십 초 | 수십 ms |
| 메모리 오버헤드 | 게스트 커널 + 하이퍼바이저 | 거의 없음 |
| 밀도 | 호스트당 수십 | 호스트당 수백 |
| 격리 강도 | 강함(하드웨어 경계) | 약함(커널 경계) |
| 다른 OS/커널 | 가능 | 불가능 |
| 이미지 크기 | GB | MB |

언제 무엇을

VM 을 골라야 하는 경우

• 서로 신뢰하지 않는 테넌트를 한 호스트에 태울 때 (멀티테넌시)
• 다른 커널 버전이나 다른 OS 가 필요할 때 (윈도우, 옛 커널 의존)
• 커널 모듈을 로드하거나 커널 파라미터를 바꿔야 할 때
• 규제가 하드웨어 수준 격리를 요구할 때

컨테이너를 골라야 하는 경우

• 같은 조직의 신뢰되는 워크로드를 많이 태울 때
• 배포 주기가 짧고 시작 시간이 중요할 때
• 이미지 기반 불변 인프라를 원할 때

그 사이 — microVM

Firecracker, Kata Containers 같은 것들이 둘 사이를 메운다. VM 의 격리 경계를 유지하면서 시작 시간과 오버헤드를 컨테이너에 가깝게 줄인 것이다. 장치 모델을 극단적으로 줄이고(virtio 몇 개만), 부팅 경로를 짧게 만들어 100ms 안팎에 뜬다. AWS Lambda 가 Firecracker 위에서 돈다.

Kata Containers 는 한 걸음 더 나가서, 컨테이너 인터페이스(OCI/CRI)를 유지하면서 안에서는 경량 VM 을 띄운다. 쿠버네티스 관점에서는 그냥 파드인데 실제로는 VM 경계로 격리된다. RuntimeClass 로 워크로드별로 선택할 수 있어, "이 네임스페이스만 강한 격리" 같은 정책이 가능하다.

현장에서 만나는 모습

"컨테이너에서 커널 파라미터를 바꿔야 하는데 안 됩니다." 당연하다. 커널이 호스트와 공유되므로 컨테이너 안에서 sysctl -w 를 하면 호스트 전체에 영향을 준다. 그래서 대부분 막혀 있다. 정말 필요하면 노드 수준에서 설정하거나(DaemonSet, 노드 부트스트랩) VM 으로 가야 한다.

이 실습 환경이 바로 그 예다. capability 가 제거된 컨테이너라 mount, tcpdump, iptables 가 안 된다. 그래서 이 커리큘럼은 그 제약을 우회하는 대신 제약 자체를 교재로 삼았다 — 어떤 작업이 왜 특권을 요구하는지 아는 것이 곧 격리 구조를 이해하는 것이다.

다음에서 할 것

다음 코스에서 rootless 컨테이너를 다룬다. 특권 없이도 컨테이너가 도는 이유(user namespace)를 파고들면, 이 모듈에서 말한 "커널 경계로 격리한다" 는 문장이 구체적인 시스템 콜과 파일로 바뀐다.