가상화 개념과 컨테이너

클라우드 컴퓨팅에 대해 공부하기 위해 Docker 학습을 시작했습니다. 이 글은 인프런의 도커 마스터즈 강의를 듣고 작성했습니다.

효과적인 학습을 위해

• 강의 내용을 수기로 요약

• 강의 자료와 함께 수기에서 적은 내용을 markdown으로 옮기고

• 부족한 배경지식과 궁금증을 조사
  하는 방식으로 학습했습니다.

이번 글에선 가상화의 기본 개념, 도커, 쿠버네티스의 개요를 살핍니다.

1 가상화 기본 개념

가상화: 하드웨어에 종속된 리소스로 IT 서비스를 만든다.

물리적 머신의 기능 → 여러 사용자 / 환경에 배포

=> 물리적 머신 최대한 활용한다.

*ref-keywords: virtualization

ex: Bluestack / NOX / 게임보이 에뮬레이터

1.1 가상화의 역사

가상화 기술 시작

• 하이퍼바이저와 같은 가상화 지원 기술은 일괄 처리를 수행하는 컴퓨터에 여러 명의 사용자가 동시에 액세스 가능하게 하는 기술

• 일괄 처리는 급여와 같은 루틴 태스크를 매우 빠르게 수천 번 실행하는 사업 부문에서 널리 사용되는 컴퓨팅 방식

• 수십 년 전에 개발되어 있었음.

가상화 기술을 활용한 다양한 벤더사의 애플리케이션 배포

• 1990년대 대부분의 기업이 물리 서버와 단일 벤더 IT 스택을 사용하고 있었기 때문에 다른 벤더의 하드웨어에서 레거시 애플리케이션을 실행할 수 없음

• 가상화 Virtualization를 통해 기업은 서버를 파티셔닝하고 여러 유형 및 버전의 운영 체제에서 레거시 애플리케이션을 실행

• 서버를 더 효율적으로 사용해 구매, 셋업, 냉각, 유지관리와 관련된 비용 감소

1.2 하이퍼바이저의 정의와 가상화 원리

하이퍼바이저(Hypervisor)

• 소프트웨어가 물리 리소스를 필요로 하는 가상 환경으로부터 <u>리소스를 분리</u>

• 호스트 컴퓨터 1대에서 운영체제 다수를 동시에 실행하는 논리적 플랫폼

  • Platform = 운영체제가 실행될 수 있는 기반 환경

• 하이퍼바이저는 노트북 등의 운영 체제에 배포하거나 서버 등의 하드웨어에 직접 설치

• 하이퍼바이저가 물리 리소스를 분할하여 가상 환경에서 사용

하이퍼바이저 유형

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)은 모든 항목에서 오버헤드로 인해 성능이 떨어진다

1.5 컨테이너 격리 기술

Container는 기본적으로 Linux kernel 기능을 통해 구현된다고 합니다.

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 도커 아키텍처

stateDiagram
    [*] --> client : 사용자 명령 입력
    
    state "Docker Client" as client {
        [*] --> CLI : docker 명령어
        CLI --> HTTP_REST : REST API 호출
    }
    
    state "Docker Server" as server {
        [*] --> Daemon : Docker Daemon 시작
        Daemon --> API : REST API 엔드포인트
        API --> Containerd : 컨테이너 관리 요청
        Containerd --> Runc : 컨테이너 실행
    }
    
    client --> server : HTTP REST 통신
    server --> client : 응답 반환
    
    note right of client
        Docker CLI가 사용자 명령을
        HTTP REST API로 변환하여
        Docker Daemon과 통신
    end note
    
    note right of server
        Docker Daemon이 REST API를 통해
        클라이언트 요청을 받아
        containerd와 runc를 통해
        실제 컨테이너 작업 수행
    end note

도커의 클라이언트와 서버는 주로 REST API로 통신한다고 합니다.

도커 CLI (Command Line Interface)

도커 제어 CLI로 이해했습니다.

• 사용자가 도커와 상호 작용하기 위한 명령줄 도구

• 사용자는 도커 CLI를 통해 이미지를 빌드하고, 컨테이너를 생성하고, 관리할 수 있음

• CLI는 사용자가 도커 명령어를 입력하면 도커 데몬(Docker Daemon)에 명령을 전달

도커 데몬 (Docker Daemon)

• 도커의 핵심 서비스이며, 컨테이너의 생성, 실행, 관리 등의 작업을 수행

• 데몬은 컨테이너 실행에 필요한 리소스를 관리하고 도커 API를 통해 클라이언트 요청에 응답

컨테이너드* (Containerd)

• 도커 데몬에서 사용하는 핵심 컨테이너 런타임

• 도커는 버전 1.11 이후로 컨테이너 런타임을 분리하여 컨테이너드를 사용

• 컨테이너드는 컨테이너의 생명주기 관리, 이미지 관리, 네트워킹, 스토리지 등과 관련된 기능을 담당

• 컨테이너를 관리하는 중간관리자의 역할

런타임 (Runc)

• 컨테이너를 실행하는 데 사용되는 도구

• 도커는 기본적으로 런타임으로 Runc를 사용

• Runc는 Open Container Initiative (OCI)에서 정의한 컨테이너 실행을 위한** 표준 스펙인 OCI 컨테이너 런타임 스펙**을 구현한 도구

• 따라서 Runc는 컨테이너의 생명주기 관리와 관련된 핵심적인 작업을 담당

2.3 containerd의 역사

개발 배경

• Containerd는 원래 유명한 컨테이너 플랫폼인 Docker의 구성 요소로 개발

• Docker는 2013년에 처음 출시되었으며 컨테이너화된 애플리케이션을 구축하고 배포하기 위한 도구로 빠르게 널리 채택됨

• 레지스트리에서 이미지 가져오기, 컨테이너 시작 및 중지와 같은 컨테이너 관리와 관련된 하위 수준 작업을 처리하기 위해 Docker의 일부로 개발

독립형 프로젝트로의 전환

• 2017년 Docker에서 독립형 프로젝트 Graduated Project로 containerd가 추출되어 CNCF(Cloud 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 컨테이너 레지스트리**

"레지스트리" 개념이 크게 와닿지 않았으나, "저장소" 개념으로 보니 이해가 수월했습니다.
특히 강의에서 이미지, 컨테이너, 레지스트리 각각의 역할을 구분하여 숙지하면 좋습니다.

기본 개념

• 컨테이너: 이미지를 격리하여 독립된 공간에서 실행한 가상 환경(ENV)

• 이미지: 필요한 프로그램과 라이브러리, 소스를 설치한 뒤 만든 하나의 파일

  • 이미지로 말아 올리다라는 표현을 자주 쓰며, 의존성, 환경 파일 등을 하나의 .tar 파일로 압축한 것을 도커 Image라고 이해했습니다.

• 레지스트리: 사용자가 사용할 수 있도록 데이터베이스를 통해 Image를 제공해주고 있음.
  a. On-Premises : Hosted Docker Registry

  • 폐쇄망/내부 네트워크를 구성하여 올린 레지스트리입니다.

  • 반드시 적절한 네트워크와 함께 레지스트리가 갖추어져야 도커를 사용할 수 있습니다.

  • Harbor CI/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 이미지, 컨테이너, 도커와 쿠버네티스의 관계

마지막으로 정리하면 다음과 같습니다.

• 컨테이너: 용기 = 리눅스 커널(name_space+cgroup)로 구성. CPU/Network/Memory/Disk 등 리소스를 담는 Container(용기)로 이해.

• 도커: 항만 노동자

• 개별 컨테이너를 관리하는 관리자

• 쿠버네티스: 항해사

• 모든 컨테이너를 관장하는 관리자

긴 글 읽어주셔서 감사합니다!