제목이 의문문이죠?
맞습니다. 컨테이너 OS는 가상이 아닙니다.
최근에 Kubernetes와 함께 가상 OS라는 마케팅 용어가 등장했습니다.
일부 관점에서 Container에는 OS가 없을 수 있습니다.
하지만 Container에 OS가 존재하는데, 그 OS가 가상의 OS다. 라고 하는 것은 틀린 말입니다.
먼저 용어 정리부터 해야겠습니다.
OS와 kernel
OS는 Operating System의 약자로, 한국어로는 운영체제라고 합니다.
운영체제의 구성요소로는 크게 두개로 볼수 있습니다.
Kernel과 System Application입니다.
Application은 한국어로 응용프로그램이라고도 합니다.
특히 Microsoft의 운영체제에서 응용 프로그램이라고 번역 하죠.
Kernel
Kernel은 핵심이 되는 컴퓨터 프로그램으로, 시스템의 모든 것을 완전히 제어(control)합니다.Application들이 CPU에 직접 접근하면 컴퓨터를 고장낼수도 있고,
여러 프로그램이 동시에 접근을 시도하면 서로 충돌 할수도 있습니다.
그래서 Kernel에 요청하면 Kernel이 CPU에 접근하는 것이죠.
중재자이면서, Application이 Linux 자원에 접근하기 위한 통로입니다.
System Application
시스템 애플리케이션은 OS와 함께 제공되는 애플리케이션을 말합니다.
윈도우에서 보면 Internet explorer나 Micrsoft Edge는 커널 프로그램은 아니지만,
Windows 운영체제에 포함된 프로그램이죠.
이 앱들도 Kernel을 거치지 않고 직접 자원에 접근하지는 않습니다.
결국 OS와 함께 제공 될 뿐, 응용 프로그램(Application)에 해당됩니다.
따라서 Kernel을 통해서 자원에 접근하게 됩니다.
그러면 컨테이너 Linux와 Native Linux의 구조에 대해서 비교해보겠습니다.
OS 구조: Container OS vs Baremetal OS
조금 전에 OS는 크게 두가지로 나눠볼 수 있다고 하였습니다.
Linux OS의 파일 구조를 알기 위해서 부팅 순서를 살짝 보도록 하겠습니다.
Baremetal OS의 부팅순서
- GRUB 로딩
- Kernel 로딩
- initram 마운트
- root 디스크 마운트
- chroot
- 애플리케이션 실행
여기서 눈여겨 봐야할 것은 3번부터 5번입니다.
커널에서 먼저 init ram 파일시스템을 불러와서 /에 마운트를 합니다.
Init ram fs는 커널과 유기적으로 연결되는 시스템 애플리케이션과 커널 밖에 저장된 커널 모듈,
root 디스크 마운트에 필요한 애플리케이션이 있습니다.
그러고 나서 실제 Linux 파티션을 /sysroot에 마운트합니다.
이후에 /sysroot로 chroot합니다.
chroot? 그게 뭔데?
사실 chroot가 무엇인지는 중요하지는 않습니다.chroot라는걸 한다는 것이 중요하죠.
Container나 Native에 설치한 리눅스나 모두 chroot라는 것을 이용한다는 것을 보여드리기 위한 것입니다.
chroot는 /의 위치를 바꾸는 프로그램입니다.
위 글에서 설명 드리면 /sysroot로 chroot하면,/에 /sysroot에 있던 파일들이 표시되죠.
예를 들어, /에 a,b,c라는 폴더가 있습니다.
/sysroot에는 q,w,e라는 폴더가 있어요.
/a
/b
/c
/sysroot/q
/sysroot/w
/sysroot/e여기에서 /sysroot로 /chroot를 하면 이런 폴더 구조로 바뀝니다.
/q
/w
/e예시로 보여드리니까 이해하기 쉽죠?
말 그대로 / (root)를 바꾸는 프로그램이예요.
말로 설정하자면 Baremetal에서는 디스크에 Kernel이 있고, 그 커널을 사용하며, 어딘가에 마운트 된 directory로 chroot하여 리눅스를 사용하고 있죠.
Container OS의 부팅 순서
먼저 Kernel은 Host와 공유하기 때문에 Kernel과 관련된 부팅 과정은 빠집니다.
여기서 중요한것은 공유 입니다.
Kernel이 없는 것이 아니라, 이미 존재하는 것을 사용하는것이죠.
- container image 마운트
- chroot
- 애플리케이션 실행
Kubernete냐, Docker냐에 따라 마운트 되는 위치는 다를 수 있습니다.
Docker는 /var/lib/docker/overlay2에 마운트 됩니다.
그리고 이 위치로 chroot하여 애플리케이션을 실행합니다.
(명확히 하면 chroot는 보안상의 이유로 사용하지 않습니다. pivot root를 사용하는데, 특정 디렉토리를 /에 있는 것처럼 보이게 한다는 점에서는 chroot와 같습니다)
그러면 Container는 디스크에 Kernel이 있고, 그 커널을 사용하며, 어딘가에 마운트 된 directory로 chroot하여 리눅스를 사용하고 있죠.
똑같죠?
그들이 말하는 컨테이너의 OS 유무는 어떤 의미일까?
이 말을 하려고 이 글을 썼습니다.
사실 저도 잘 모릅니다.
제가 추측한 가상 OS는 이런 뜻중에 하나일 것 같습니다.
Container ‘이미지’에는 OS가 없다.
아마 container 이미지 파일에 Kernel 없다는 의미일 것입니다.
위에서 OS에는 Kernel + System Application이라고 말씀드렸는데
작게는 Kernel만을 OS라고 보는 분도 계십니다.
Kernel만을 OS라고 보시는 분들은, Kernel은 OS이고,
Kernel + Application을 distribution(배포판)이라고 보시죠.
하지만 그 말에 따르면 Ubuntu와 Red Hat은 같은 버전의 커널을 사용하기만 하면 같은 OS이며,
버전이 달라도 버전이 다른 같은 OS라고 볼수 있습니다.
저는 그래서 이 말도 동의하지 않지만, Kernel만을 OS라고 보는 입장까지 고려해봤습니다.
Kernel을 OS라고 본다고 하면 Container에는 OS가 없다는 말은 맞지만,
여전히 가상 OS라는 말은 틀리게 되죠.
OS를 Kernel만 본다면 가상의 OS가 있는게 아니라, 그냥 OS가 없는거예요.
Container 이미지에는 ‘Kernel’이 없다.
컨테이너 이미지와 컨테이너를 명확히 구분해야 합니다.
Container Image는 chroot 할 파일입니다.
이 파일에는 Kernel이 없습니다.
그래서 Container Image 안에는 OS의 일부만 있다는 의미로 가상 OS라고 한 것일 수도 있습니다.
그러므로 Container 이미지 파일은 가상 OS 파일이라고 할수도 있습니다.
하지만 부팅한 Container는 가상 OS일까요?
엄연히 존재하는 Kernel을 사용합니다.
이미 존재하다보니 새롭게 부팅하는 절차가 없을 뿐이며,
Kernel은 실존하고, Container 안에서 Kernel을 직접 접근할 수 있습니다.
그러므로 Container Image는 불완전한 OS를 갖고 있으나,
Container는 완전한 OS 구성을 갖추고 있다고 할 수 있습니다.
부팅할 때 Kernel을 불러오지 않는다.
OS를 부팅 과정으로 결정 짓나요?
결과적으로 Kernel에 접근하고, 사용할 수 있는데
부팅 과정에서 불러오지 않는다고 가상 OS라니요.
윈도우는 fast boot라는 기능이 있습니다.
시스템 종료할 때 다음 부팅에 필요한 정보를 보조 저장소에 몰아둡니다.(디스크 조각 모음 안해도 부팅을 빠르게 하기 위해서죠)
그리고 일부 커널 정보를 램에 넣어둡니다.
마치 절전모드처럼요.
윈도우는 종료 후 전원을 켜면, 가상 OS로 부팅하네요?
참고로 윈도우는 빠른 시작이 활성화 되어있다면, 다시시작보다 종료 후 시작이 시작 시간이 더 빠릅니다.
게다가 종료 후, 전원을 차단 하였다가 다시 부팅하는 것과 종료 후 부팅하는 것에도 속도차이가 나죠.
무려 하드디스크 환경에서도 8초 미만 부팅을 제공해줬습니다다만 조건이 까다롭고, 매 종료시마다 2기가바이트 이상의 파일을 보조저장소에 쓰기 때문에
SSD가 도입된 이후로 사용되는 것을 본적 없습니다.오히려 매 종료시마다 발생하는 쓰기가 수명을 깎아내고, SSD는 원래부터 조각모음도 필요 없기 때문이죠.
지금 이미 적용이 되었는지는 모르겠는데, 리눅스도 부팅에 필요한 일부 정보를 램에 넣어두어서 부팅 시간 간소화 하면,
가상 OS로 부팅한다고 볼수 있네요.
절전모드에서 복귀하는 것도 가상 OS겠군요!
이미 존재하는 Kernel을 사용하느라 로드하지 않으니까요!
/를 다른곳에 마운트 하여 사용한다
어쩌면 Container 이미지를 어딘가에 마운트 한 다음 chroot해서 사용하기 때문에 그렇게 표현했을 수도 있습니다.
System Application이 Host OS와 완전히 달라지니까요.
어머나! 이게 왠걸! 이미 initram(태초에 /에 마운트 되는 파일)과 /sysroot(부팅 완료 될 때는 /에 마운트 되는 파일)은 서로 다른 위치에 저장되어있네요?
마치 Container Image의 파일이 다른 곳에 있다가 /에 마운트 되는 것 같이 말이죠!
그러면 실제 Linux도 가상 OS라고 할수 있겠네요!!
마무리
조금만 수정하면 맞는 말일 수 있습니다.
OS = Kernel이라고 본다면, Container 이미지에는 OS가 없다.가 맞을 수 있습니다.
하지만 컨테이너에는 OS가 없다는 어떻게 해도 틀린 말입니다.
게다가 OS = Kernel + System Application이라고 본다면 `Container 이미지에는 OS가 없다`는 말조차 틀린 말이죠.
게다가 가상 OS라는 용어도 틀린 말입니다.
Kernel만을 OS로 본다면 Container imaeg는 가상 OS가 있는게 아니라, 그냥 OS(Kernel)가 없습니다.
또한 OS를 Kernel + System Application이라고 본다면
Container 이미지 안에는 System Application만 있기 때문에 OS가 일부만 있는 것은 맞지만
실제로 디스크에 존재하고 있으니 가상OS는 아니죠.
Container에도 System Application과 Kernel이 실존하기 때문에 가상이 아닌 실존 OS입니다.
따라서 관점에 따라 컨테이너에는 OS가 없다고 볼수 있지만
가상 OS는 어떻게 봐도 틀린 용어입니다.
컨테이너의 가장 큰 장점은
가상머신처럼 분명히 나누어져서 애플리케이션 간에 인식을 못하는데도
Kernel에는 직접 접근 할수 있는 것이 장점입니다.
없는 Kernel에 접근할리가 없잖아요.
커널. 있습니다. 이미지 파일에 없을 뿐, 있습니다.
답글 남기기