1. Docker 가상화 개념과 컨테이너
클라우드 컴퓨팅에 대해 공부하기 위해 Docker와 인프런의 도커 마스터즈 강의를 시작했습니다.
이 문서에서는 Docker 가상화의 기본 개념과 도커, 쿠버네티스 개요를 다룹니다.
1 가상화 기본 개념
가상화 = 하드웨어에 종속된 리소스로 IT 서비스를 만든다.
물리적 머신의 기능 → 여러 사용자 / 환경에 배포
=> 물리적 머신 최대한 활용한다.
ref-keywords: virtualization
ex: Bluestack / NOX / 게임보이 에뮬레이터
1.1 가상화의 역사
가상화 기술 시작
- 하이퍼바이저와 같은 가상화 지원 기술은 일괄 처리를 수행하는 컴퓨터에 여러 명의 사용자가 동시에 액세스 가능하게 하는 기술
- 일괄 처리는 급여와 같은 루틴 태스크를 매우 빠르게 수천 번 실행하는 사업 부문에서 널리 사용되는 컴퓨팅 방식
- 수십 년 전에 개발되어 있었음.
가상화 기술을 활용한 다양한 벤더사의 애플리케이션 배포
- 1990년대 대부분의 기업이 물리 서버와
단일 벤더 IT 스택을 사용하고 있었기 때문에 다른 벤더의 하드웨어에서 레거시 애플리케이션을 실행할 수 없음 가상화 Virtualization를 통해 기업은 서버를 파티셔닝하고 여러 유형 및 버전의 운영 체제에서 레거시 애플리케이션을 실행- 서버를 더 효율적으로 사용해 구매, 셋업, 냉각, 유지관리와 관련된 비용 감소
1.2 하이퍼바이저의 정의와 가상화 원리
하이퍼바이저(Hypervisor)
- 소프트웨어가 물리 리소스를 필요로 하는 가상 환경으로부터
<u>리소스를 분리</u> - 호스트 컴퓨터 1대에서 운영체제 다수를 동시에 실행하는 논리적 플랫폼
- Platform = 운영체제가 실행될 수 있는 기반 환경
- 하이퍼바이저는 노트북 등의 운영 체제에 배포하거나 서버 등의 하드웨어에 직접 설치
- 하이퍼바이저가 물리 리소스를 분할하여 가상 환경에서 사용
하이퍼바이저는 Native / Hoseted 2가지 타입이 있습니다.
Native - Type 1
정의: 하이퍼바이저가 운영체제 없이 하드웨어 위에 직접 설치되는 형태
- 해당 하드웨어/베어메탈에 직접 설치
- 게스트 운영체제는 두 번째 수준으로 실행
- 제품:
Xen,KVM,ESXi등 Xen: 오픈소스 기반의Type 1 하이퍼바이저로, 아마존 AWS 등 대규모 클라우드 인프라에서 사용KVM: 리눅스 커널에 포함된 가상화 모듈로, 리눅스 자체를 Type 1 하이퍼바이저처럼 동작하게 함.ESXi: VMware에서 제공하는 대표적인 상용 Type 1 하이퍼바이저로, 기업 서버 가상화 표준으로 널리 활용됨.
보통 기업에서 사용한다고 합니다.
❓베어 메탈 Bare-metal: 하드웨어 위에서 바로 실행
Hosted - Type 2
- 일반 프로그램처럼 호스트 운영체제에서 실행
- 게스트 운영체제는 세번째 수준으로 실행
- ?: "3번째 수준"?
- 제품: Virtualbox, Vmware, Parrallels 등
N번째 수준(Layer) 개념이 궁금하여 추가로 조사했습니다.
1. 하드웨어 (CPU, 메모리, 디스크)
↓
2. 호스트 운영체제 (예: Windows, macOS, Linux)
↓
3. 하이퍼바이저 프로그램 (VirtualBox, VMware Workstation, Parallels 등)
↓
4. 게스트 운영체제(Guest OS) (가상 머신 안에 설치된 OS)
여기서 게스트 OS는
하드웨어 → 호스트 OS → 하이퍼바이저 → 게스트 OS 순서로 실행되기 때문에,
흔히 세 번째 수준3rd layer이라고 표현한다고 합니다.
1.3 컨테이너
개념의 중요성에 대해 강조해주셨습니다. 도커가 널리 사용되면서 컨테이너=도커라고 합니다.
개인적으로는 Containerd, 컨테이너 런타임이 궁금하여 조금 더 알아보고 싶었습니다.
컨테이너의 개념
- 컨테이너는 가상환경을 사용해 각 마이크로 서비스를 격리 isolate하는 기술
- 컨테이너는 가상머신처럼 하드웨어를 전부 구현하지 않기 때문에 매우 빠른 실행 가능
- 최근에 M3 맥에서 UTM을 활용하여 Windows OS를 실행했는데 상당히 무거웠습니다.
- 컨테이너는 도커, K8S의 환경에서 더 작은 단위로 격리되어 실행되어 빠른 것이 아닐까 예상했습니다.
1.4 VM과 컨테이너의 성능 비교

이 부분은 사실 많이 낯선 내용이었습니다.
벤치마크 메트릭에서 Hypervisor / Docker / K8S의 성능 비교 및 리소스 효율성 위주로 이해했습니다.
PageRank 워크로드 실행 결과
- PageRank는 웹페이지들의 중요도를 수치로 평가하는 알고리즘
- 실제로 PageRank 점수를 계산하려면, 수백만~수십억 개의 노드와 링크로 구성된 대규모 그래프에서 위와 같은 연산을 반복 수행해야 함
- 이 과정은 행렬 곱셈, 벡터 연산 등 대량의 수치 계산과 반복적인 갱신이 필요하므로, 컴퓨팅 자원을 많이 소모
- 컨테이너 환경은 VM 환경에 비해 CPU 자원을 더 효율적으로 활용하며, 대기(Wait) 상태가 거의 없어 리소스 낭비가 적고, 작업 완료 시간도 짧음
- VM 환경은 인스턴스가 많아질수록 CPU 대기(Wait) 시간이 급격히 늘어나고, 전체 작업 시간이 길어짐. 이는 가상화 오버헤드와 리소스 경합 때문임
컨테이너와 VM, 베어메탈 벤치마크 결과
- 베어메탈(Native), 가상머신(KVM), 그리고 다양한 컨테이너 환경(Docker, LXC, RKT)에서 CPU, 메모리, 디스크 I/O, 네트워크 성능을 비교한 벤치마크 결과
- VM(KVM)은 모든 항목에서 오버헤드로 인해 성능이 떨어진다 -> 결론적으로
Docker가 선호되는 이유로 이해했습니다.
1.5 컨테이너 격리 - Linux Namespace + Cgroup

출처: Overview of Linux Namespace - 8gwifi.org
Container는 기본적으로 Linux kernel 기능을 통해 구현됩니다.
그 중에서 namespace와 cgroup이 도커의 핵심적인 기능 구현에 사용되는 것으로 이해했습니다.
도커가 리눅스 기반이기 때문에, docker network의 overlay나 layer 개념을 이해하는데 필요한 내용입니다.
A. 리눅스 네임스페이스(Namespace)
- 각 프로세스가 파일 시스템 마운트, 네트워크, 유저(uid), 호스트 네임(uts) 등에 대해 시스템에 독립 뷰를 제공
- What you can see - 프로세스 격리를 통해 "뷰"를 제어한다는 의미로 이해했습니다.
네임스페이스를 통해 프로세스마다 격리한다는 개념이 중요한 것같습니다.
B. cgroup(컨트롤 그룹)
- 프로세스 그룹이 사용할 수 있는 시스템 자원(메모리, CPU, I/O, 네트워크 등)의 "양"을 제한하거나 모니터링하는 역할
- cgroup은 자원의 '할당/제한/계량'을 담당하고, 네임스페이스는 '격리'를 담당
- /cpu_mem_cg는 systemd와 cgroupfs와 같은 "cgroup 계층(hierarchy)"의 최상위 관리 주체를 나타냄
리눅스 네임스페이스, cgroup을 이용하여 컨테이너를 구성하는 것에 난이도가 높기 때문에, 이를 단순화한 툴 Docker을 사용하게 됩니다.
2. 도커(Docker)
2.1 도커 소개 (2013년)
- 컨테이너 기술의 사실상 표준
- 다양한 운영체제에서 사용 가능(리눅스, 윈도우, MacOS)
- 앱App에 국한 되지 않고 의존성 및 파일 시스템까지 패키징하여 빌드, 배포, 실행을 단순화
- 리눅스의 네임 스페이스와 cgroups와 같은 커널 기능을 사용하여 가상화
2.2 도커 아키텍처
도커의 클라이언트와 서버는 주로 REST API로 통신한다고 합니다.
2.3. 도커 CLI (Command Line Interface)
도커 Desktop 앱을 사용할 수 있지만, 배포 환경 자동화를 위한 Infrastructure as Code를 만들기 위해선, 제어 CLI를 익혀야합니다.
docker [command] [target] [-options]로 자주 사용되는 것 같습니다.
이어지는 강의에서 개념과 함께 하나씩 익힐 수 있었습니다.
docker CLI
- 사용자가 도커와 상호 작용하기 위한 명령줄 도구
- 사용자는 도커 CLI를 통해 이미지를 빌드하고, 컨테이너를 생성하고, 관리할 수 있음
- CLI는 사용자가 도커 명령어를 입력하면 도커 데몬 Docker Daemon에 명령을 전달
apt install docker.io
이 명령어를 통해 리눅스 OS에서 도커 대몬, 컨테이너 등을 한번에 설치하고 CLI로 관리할 수 있습니다.
2.4. 도커 데몬 (Docker Daemon)
- 도커의 핵심 서비스이며,
컨테이너의 생성, 실행, 관리등의 작업을 수행 - 데몬은 컨테이너 실행에
필요한 리소스를 관리하고 도커 API를 통해 클라이언트 요청에 응답
2.5 컨테이너드 Containerd
- 도커 데몬에서 사용하는 핵심 컨테이너 런타임
- 도커는 버전 1.11 이후로 컨테이너 런타임을 분리하여 컨테이너드를 사용
- 컨테이너드는 컨테이너의 생명주기 관리, 이미지 관리, 네트워킹, 스토리지 등과 관련된 기능을 담당
- 컨테이너를 관리하는 중간관리자의 역할
런타임 (Runc)
- 컨테이너를 실행하는 데 사용되는 도구
- 도커는 기본적으로 런타임으로
Runc를 사용 Runc는Open Container Initiative (OCI)에서 정의한 컨테이너 실행을 위한** 표준 스펙인 OCI 컨테이너 런타임 스펙**을 구현한 도구- 따라서 Runc는 컨테이너의
생명주기 관리와 관련된 핵심적인 작업을 담당
Containerd + @
최근에는 Containerd만 도커에서 독립하면서 커뮤니티 활성화와 많은 발전이 이루어지고 있다고 합니다. 개인적으로도 관심이 많습니다.
개발 배경
- Containerd는 원래 유명한 컨테이너 플랫폼인 Docker의 구성 요소로 개발
- Docker는 2013년에 처음 출시되었으며 컨테이너화된 애플리케이션을 구축하고 배포하기 위한 도구로 빠르게 널리 채택됨
- 레지스트리에서 이미지 가져오기, 컨테이너 시작 및 중지와 같은 컨테이너 관리와 관련된 하위 수준 작업을 처리하기 위해 Docker의 일부로 개발
독립형 프로젝트로의 전환
- 2017년 Docker에서 독립형 프로젝트
Graduated Project로 containerd가 추출되어 CNCFCloud Native Computing Foundation 프로젝트가 됨 - 그 이후로 containerd는 성능, 안정성 및 보안에 중점을 두고 크게 발전하고 개선
- Containerd에는 Docker, Google 및 Red Hat과 같은 회사의 개발자를 포함하여 대규모의 활동적인 기여자 커뮤니티가 있음
CNCF 프로젝트로서의 성장
강의에서 CNCF를 알려주셔서 좋았습니다.
- Containerd는 CNCF(Cloud Native Computing Foundation) 프로젝트가 되어 가시성을 높이고 더 큰 기여자 커뮤니티를 유치하는 데 도움
컨테이너의 진화
- Docker에서 추출된 이후 containerd는 성능, 안정성 및 보안에 중점을 두고 크게 발전
- 2018년에 출시된 containerd 1.0은 프로젝트의 안정성과 성숙도에 중요한 이정표를 세움
- 2019년 Kubernetes의 기본 컨테이너 런타임으로 containerd 채택
- 2020년에 "졸업" 프로젝트로 CNCF Landscape에 containerd 포함
2.4 Container Registry
"레지스트리" 개념이 크게 와닿지 않았으나, "저장소" 개념으로 보니 이해가 수월했습니다.
특히 강의에서 이미지, 컨테이너, 레지스트리 각각의 역할을 구분하여 숙지하면 좋습니다.
기본 개념
- 컨테이너: 이미지를 격리하여 독립된 공간에서 실행한 가상 환경(ENV)
- 이미지: 필요한 프로그램과 라이브러리, 소스를 설치한 뒤 만든 하나의 파일
- _이미지로 말아 올리다_라는 표현을 자주 쓰며, 의존성, 환경 파일 등을 하나의
.tar파일로 압축한 것을 도커Image라고 이해했습니다. - 레지스트리: 사용자가 사용할 수 있도록 데이터베이스를 통해 Image를 제공해주고 있음.
a. On-Premises : Hosted Docker Registry - 폐쇄망/내부 네트워크를 구성하여 올린 레지스트리입니다.
- 반드시 적절한 네트워크와 함께 레지스트리가 갖추어져야 도커를 사용할 수 있습니다.
HarborCI/CD 관련 내용에서 더 살펴볼 예정입니다.
b. Public Cloud:- Docker Trusted Registry, Azure Container, AWS, Google 등 공공 클라우드에 해당합니다.
- 누구나 이미지를 만들어 푸시할 수 있으며 푸시된 이미지는 다른 사람들에게 공유 가능
2.5 도커의 한계
- 서비스가 커지면 커질 수록 관리해야 하는 컨테이너의 양이 급격히 증가
- 도커를 사용하여 관리를 한다 하더라도 쉽지 않은 형태
예시:
- 32대의 서버의 호스트에 도커가 설치되었다고 가정합니다.
- 각 도커에 200개의 컨테이너가 있다면, 모든 컨테이너는 6400개가 됩니다.
- 이 중 몇몇의 컨테이너에서 문제가 발생한다면 관리 비용이 상승할 것입니다. 32개의 다른 도커를 관리해야 하기 때문에, 컨테이너가 분산되어 복잡성이 증가합니다.
- 이러한 문제로 인해 컨테이너 관리의 중요성이 대두되었습니다.
3. 쿠버네티스(Kubernetes)
3.1 쿠버네티스 소개
쿠버네티스는 이러한 컨테이너 관리의 문제를 해결하기 위해 도입되었습니다.
도커 레이어를 건너 뛰고, 모든 컨테이너를 K8S 플러그인을 통해 관리하게 됩니다.
- 2014년 구글이 오픈 소스 공개
- 구글이 컨테이너 운영 노하우가 담긴 오픈소스
- 고대 그리스어로 항해사라는 의미를 가짐
- 다수의 컨테이너를 자동으로 운영하기 위한 오케스트레이션 도구
- 많은 시스템을 통합, 컨테이너를 다루기 위한 API 제공
3.2 쿠버네티스 개념
강의에선 간략히 소개해주셔서, 추가로 문서의 개요를 번역해봤습니다.
Kubernetes is a portable, extensible, open source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.
쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 가볍고portable, 확장 가능한 오픈소스 플랫폼입니다. 선언적 구성과 자동화를 모두 지원하며, 빠르게 성장하는 생태계를 갖고 있어 광범위한 서비스/지원/도구가 제공됩니다.
이 문서를 읽고 난 후엔 컨테이너화된 Containered이라는 용어에 익숙해질 수 있을 것입니다.
수 많은 컨테이너를 관리하기 위한 Container Ochestration 플랫폼으로 이해하고, 별도 문서에서 더 살펴보겠습니다.
Summary
마지막으로 정리하면 다음과 같습니다.
- 컨테이너
- Linux Kernel
name_space+cgroup로 구성.
자원 ResourceCPU/Network/Memory/Disk etc을 담는 Container
- Linux Kernel
- 도커: 항만 노동자
- 개별 컨테이너를 관리하는 관리자
- 쿠버네티스: 항해사
- 모든 컨테이너를 관장하는 관리자