- 가상 머신과 컨테이너의 성능은 대략 30% 정도 차이 난다
- 허나, 무조건 성능만을 보고 컨테이너가 가상 머신보다 좋은 것은 아니다. 가상 머신은 자체 Kernel 을 가지기에, Host OS 와 다른 환경의 guest OS 를 설치하여, 다른 환경의 APP 를 설치하여 사용할 수 있지만, 컨테이너의 경우 Host OS 를 직접 사용하므로, Host OS 와 동일한 환경의 APP 만 설치하여 사용할 수 있기 때문이다
- ex ) 컨테이너의 경우 WINDOW OS 를 사용할 때, Linux 환경의 APP 을 설치하여 사용할 수 없다. 가상 머신의 경우 WINDOW OS 위에 하이퍼 바이저 위에 guest OS 로 Linux OS 를 설치하여, Linux 환경의 APP 을 설치하여 사용 가능하다
하이퍼 바이저를 이용하여 가상 서버를 구축하고, 해당 서버 위에 애플리케이션이 배치되는 형태로 가상 머신은 각자의 커널을 갖는다. 실제로 애플리케이션이 동작하기 위해서는 guest OS -> guest OS 의 커널 -> 하이퍼 바이저 -> Host OS 의 커널 -> 물리 자원을 거쳐야 하므로 성능 저하가 발생한다
Host OS 가 있을 수도 있고, 없을 수도 있다
컨테이너 : 소프트웨어 서비스를 실행하는 데 필요한 특정 버전의 프로그래밍 언어 런타임 및 라이브러리와 같은 종속 항목과 애플리케이션 코드를 함께 포함하는 경량 패키지. 즉, 어떤 환경에서나 실행하기 위해 필요한 모든 요소를 포함하는 소프트웨어 패키지
- 도커 컨테이너 : 도커 컨테이너란 이미지를 통해 실행한 인스턴스
- 리눅스 컨테이너 : 시스템의 나머지 부분과 분리된 1개 이상의 프로세스 세트
도커 엔진 : 도커에서 이미지와 컨테이너를 관리하는 도구이며, 도커의 핵심이다
컨테이너는 자신이 속한 OS 의 커널을 직접 사용하므로, 성능 저하가 거의 없다
컨테이너는 가상 머신처럼 물리적 자원을 격리시키는 것이 아니라, 프로세스를 격리를 통해 경량의 이미지를 실행하고 서비스하게 해준다
- 클라우드 서비스의 컨테이너는 애플리케이션을 구동하는 환경을 격리한 공간을 의미
컨테이너의 자원의 기본은 별도로 할당하지 않았으므로 물리 자원을 공유한다. 허나, cgroup 이용해서 각 컨테이너 별로 cpu , ram 사용량 제한을 걸 수 있다
- 따라서 성능 저하가 없으면서도 배포가 용이하고, 스케일등의 적용이 쉬운 컨테이너를 이용하는 것이 이용자를 위해서 유리하다
user namespace : 사용자 또는 그룹별로 격리
UTS ( unix time-sharing ) namespace : 응용 프로그램 입장에서 호스트명과 도메인에 대한 분리된 가시성을 제공
mount namespace : 프로세스에서 마운트된 파일 시스템에 대해 가시성을 제공하기 위해 자신만의 mount namespace 를 사용할 수 있다 ( 각각의 컨테이너에서 별도의 호스트 디렉터리를 마운트 할 수 있다 )
PID namespace : Process ID 는 Host 상의 다른 응용 프로그램으로 부터 격리될 수 있다. 이를 통해 동일한 애플리케이션이 동시에 2개 이상 동작하는 것도 가능하다
network namespace : 네트워크 인터페이스, 라우팅 테이블등에 대한 격리가 가능하다
- gitlab 은 설치형 오픈 소스로도 제공된다
쿠버네티스는 컨테이너를 생성하는 runtime ( containerd, cri-o, rkt, podman 등 ) 이 아니다. 쿠버네티스는 다양한 runtime 을 사용하므로, 사실상 표준으로 취급된다
쿠버네티스와 달리 runtime 으로 도커만을 사용하는 오케스트레이션 툴인 swarm 도 있다