우분투 Docker 컨테이너는 누구의 커널을 쓸까? Mac에서 VM이 필요한 이유

Ubuntu 컨테이너 안에서도 커널은 바깥에서 가져온다

Linux에서 Docker Engine으로 직접 실행한 Ubuntu 컨테이너는 그 Linux 호스트의 커널을 사용한다. Ubuntu라는 이름은 컨테이너 안에서 사용할 파일·명령·라이브러리의 구성을 가리킨다. Ubuntu 가상머신을 켤 때처럼 별도의 커널을 부팅한다는 뜻은 아니다.

10월 22일 공개된 개발 블로그 Code and Cake의 글은 직접 컨테이너 런타임을 만들다가 발견한 이 차이를 짚었다. Docker를 작은 VM으로 생각하면 낯설지만, Docker 공식 설명의 출발점은 격리된 프로세스다. 프로세스를 실행하는 커널은 여러 컨테이너가 공유한다.

컨테이너 이미지는 그 프로세스가 쓸 파일을 포장한다. Python 앱이라면 Python 실행 환경과 앱 코드, 의존 라이브러리가 들어갈 수 있다. Ubuntu 이미지에서 다른 배포판 이미지로 바꾸면 이런 사용자 공간의 구성이 달라지지만, 실행 중인 호스트 커널이 함께 바뀌지는 않는다.

Mac에서는 Linux VM이 컨테이너의 호스트가 된다

Mac의 Docker Desktop은 Linux 컨테이너를 실행할 Linux VM을 제공한다. 이때 커널을 공유하는 상대는 macOS 자체가 아니라 VM 안의 Linux다. 컨테이너마다 VM을 하나씩 부팅한다는 의미도 아니다.

마지막 행은 놓치기 쉽다. Docker는 Linux용 Desktop도 VM을 쓴다고 명시한다. 플랫폼 간 사용 경험을 맞추고 호스트의 배포판 업데이트와 별도로 커널 기능을 제공하기 위한 선택이다. 따라서 ‘Linux 컴퓨터에서 실행한다’는 정보만으로 VM 유무를 결론 낼 수 없다. Engine을 직접 쓰는지 Desktop을 쓰는지까지 봐야 한다.

격리와 CPU·메모리 상한은 다른 설정이다

커널을 공유한다고 컨테이너 안팎에서 모든 것이 똑같이 보이는 것은 아니다. Docker는 네임스페이스를 이용해 프로세스가 보는 환경을 분리한다. 파일시스템과 프로세스·네트워크의 범위를 나누면서도 실행은 같은 커널이 담당할 수 있다.

자원 사용량에는 별도의 주의가 필요하다. 공식 자원 제한 문서에 따르면 컨테이너에는 기본적으로 고정된 자원 상한이 없다. 호스트 커널의 스케줄러가 허용하는 만큼 사용할 수 있으므로, 컨테이너로 포장했다는 사실만으로 CPU나 메모리 사용량까지 정해지지는 않는다.

root 권한 여부도 별개다. Rootless 모드는 데몬과 컨테이너를 사용자 네임스페이스 안에서 비루트 권한으로 실행한다. 실행 권한을 바꾸는 방식이며, 컨테이너에 독립된 커널을 추가하는 기능은 아니다.

라이브러리 문제인지, 커널 요구인지에 따라 바꿀 곳이 다르다

앱이 특정 라이브러리나 실행 환경을 요구한다면 이미지의 사용자 공간 구성을 바꾸는 것이 해결 방향이 될 수 있다. 반대로 필요한 것이 특정 Linux 커널 기능이라면 컨테이너를 실행하는 호스트나 Desktop VM의 지원 여부를 봐야 한다. 최신 Ubuntu 이미지를 받는 것만으로 그 요구가 충족되지는 않는다.

실행 환경을 설명할 때도 이미지 이름과 호스트를 함께 적는 편이 정확하다. ‘Ubuntu 컨테이너’라는 말만으로는 Linux 서버의 Engine에서 도는지, Mac의 Desktop VM에서 도는지 알 수 없다. 이미지는 앱이 사용할 파일을 정하고, 호스트는 그 앱을 실행할 커널을 제공한다. 이 둘을 나누면 Docker와 VM이 함께 등장해도 모순이 사라진다.

자주 묻는 질문