[EKS] 가상머신 vs 컨테이너?

이번 시간에는 EKS를 알아보기에 앞서 VM과 컨테이너의 차이점에 대해 알아보는 시간을 갖는다. 또한 Docker와 k8s의 전반적인 개념에 대해서도 알아볼 예정이다.

01-1. 가상머신 vs 컨테이너

가상머신(VM)과 컨테이너는 애플리케이션을 IT 자원으로부터 독립적으로 격리하는 특성을 가진다. 이는 하나의 애플리케이션이 다른 애플리케이션에 영향을 주지 않도록, 각각 별도의 실행 환경을 제공한다는 의미다. 예를 들어, VM은 대형 쇼핑몰 전체를 복제해 하나 더 만드는 방식으로, 완전한 독립 환경을 구성한다. 반면 컨테이너는 동일한 쇼핑몰 안에 상점을 분리해 임대하는 개념으로, 각 상점이 자체 환경을 가지되 기본 인프라는 공유하는 구조라고 볼 수 있다.

01-2. 가상머신 특징

가상머신(VM)은 하드웨어 인프라 위에 운영체제(OS)를 설치한 후, 그 위에 하이퍼바이저(Hypervisor)를 구성하여 동작한다. 하이퍼바이저 위에는 각각의 Guest OS가 설치되며, 그 위에서 실행 파일, 라이브러리, 애플리케이션이 구동된다. VM은 하드웨어 수준의 가상화를 지원하며, 이는 물리적인 하드웨어를 가상으로 생성해 사용하는 방식이다. 앞서 예시로 든 것처럼, 하나의 대형 쇼핑몰을 통째로 복제하는 구조와 유사하다.

01-3. 컨테이너 특징

컨테이너 환경 역시 하드웨어 인프라 위에 운영체제가 설치된다는 점에서는 가상머신과 동일하다. 그러나 운영체제 위에는 하이퍼바이저 대신 컨테이너 엔진(Docker, containerd, CRI-O)이 설치되며, 그 위에서 애플리케이션이 직접 실행된다. 이러한 구조는 앞서 설명한 비유처럼, 하나의 대형 쇼핑몰 안에 여러 개의 상점을 구성해 각 상점이 독립적으로 운영되는 방식에 비유할 수 있다. 또한, 각각의 컨테이너는 Host OS의 커널 자원을 공유한다는 특징이 가지고 있으며, OS 레벨의 가상화는 Linux의 namespace, cgroup을 통해 프로세스 단위의 격리 환경을 이룰 수 있다.

01-4. 가상머신과 컨테이너 비교 정리

	가상머신(Virtual Machine)	컨테이너(Container)
가상화	하드웨어 수준의 가상화	운영체제 수준의 가상화
OS	Guest OS	Host OS
오버헤드	크다	작다
성능	낮음	높음
복제 및 배포	느림	빠름
격리 및 보안	높음	낮음

 

02. Docker란?

Docker는 Linux 기반의 컨테이너 환경을 제공해주는 오픈소스 플랫폼이다. 이러한 Docker는 리눅스 상에서 namespace와 cgroup 등의 Linux 커널 자원을 기반으로 컨테이너를 완전 격리하고, 리소스 사용량을 개별 컨테이너별로 격리시켜 제한하도록 할 수 있다.

02-1. Docker 아키텍처

Docker는 클라이언트가 명령을 통해 요청을 보내면 Docker Host의 Daemon이 이를 처리하여 이미지·컨테이너·네트워크·볼륨 등을 관리하고, 별도의 레지스트리는 이미지와 플러그인 등을 저장·공유하는 구조로 동작한다.

02-2. Docker 동작 흐름

하지만 다수의 컨테이너가 구성된다면 이들을 관리하는데 어려움이 발생한다.
하여 컨테이너 오케스트레이션 툴(k8s, Mesos, Docker Swam)을 사용하여 컨테이너를 관리한다

docker run, build, pull → docker host daemon → command 수행

03. k8s Overview

쿠버네티스(k8s)는 다수의 컨테이너를 빠르게 확장 및 배포하고, 관리하기 위한 오픈소스 플랫폼이다. k8s를 사용하면 기존 Docker만으로 해결하지 못한 문제를 해결할 수 있다. 하지만, 러닝커브가 높고 팀에 숙련된 엔지니어가 없는 경우 오히려 k8s를 도입하는 것은 독이 될 수 있다. k8s의 역혁은 아래와 같다.

1. 2014년 : 공식적인 k8s이 발표 되었으며, Google의 내부 컨테이너 배포 시스템인 Borg를 기반으로 k8s로 발전
2. 2015년 : k8s 1.0 버전 릴리즈, 버전 발표와 동시에 CNCF(Cloud Native Computing Foundation)으로 이관되며 오픈소스로 전 세계에 공개됨
3. 현재 : 컨테이너 오케스트레이션의 사실상 표준 역할

03-1. k8s 구성 요소

 

An Overview of Kubernetes Architecture - OpsRamp

 

서버에 Kubernetes(k8s)를 설치하면 기본적으로 하나의 클러스터가 생성되며, 이는 마스터 노드(Control Plane)와 워커 노드(Worker Node)로 구성된다. 마스터 노드에는 API Server, Scheduler, etcd, Controller Manager 등 클러스터를 제어하는 핵심 컴포넌트가 위치하고, 워커 노드에는 kubelet, kube-proxy, Pod 등이 배치되어 실제 애플리케이션이 실행된다.

03-2. Control Plane 컴포넌트 구성 요소

✅ 1. API Server

API Server는 k8s 클러스터의 진입점(Front Door) 역할을 합니다. kubectl, 내부 컴포넌트, 외부 시스템이 k8s 클러스터와 상호 작용할 수 있는 RESTful 형태의 API 인터페이스를 제공합니다. 모든 요청은 인증, 인가 유효성을 거쳐 유효성 검사를 수행한 뒤 처리되며, 리소스 상태는 etcd에 저장됩니다. 또한, 스케줄링이나 제어가 필요한 경우 해당 요청은 Scheduler나 Controller Manager에게 전달 됩니다.

✅ 2. Scheduler

Scheduler는 쿠버네티스(k8s) 클러스터 내에서 아직 노드에 할당되지 않은(Pending 상태) Pod를 감지하고, 해당 Pod를 어느 노드에 배치할지 결정하는 컴포넌트이다. 스케쥴링 시 고려되는 요소로는 노드별로 가용이 가능한 리소스(CPU or Mem), Pod의 요구 조건, Node Selector 등이 존재한다. 또한, Scheduler는 단지 “어떤 노드에서 실행할지” 결정만 하고, 실행 명령은 Kubelet을 통해 수행이 된다.(kubelet은 API Server watch)

✅ 3. Controller Manager

Controller Manager는 쿠버네티스(k8s) 클러스터의 상태를 지속적으로 감시하고, 사용자가 정의한 상태(Desired State)에 맞게 클러스터를 유지하는 컴포턴트이다. 이러한 Controller Manager는 여러 컨트롤러(예: ReplicaSetController, NodeController 등)을 통합 실행하며, 컨트롤 루프(Control Loop) 방식으로 동작한다. 예를 들어, 3개의 파드를 유지해야 하는데 1개만 실행 중이라면, 나머지 2개를 자동으로 생성한다. 즉, 클러스터의 자동 복구 및 유지를 위한 핵심 구성 요소다.

✅ 4. etcd

etcd는 쿠버네티스(k8s) 클러스터의 모든 정보를 저장하는 분산 Key - Value 저장소로, 클러스터의 중앙 데이터베이스(DB) 역할을 수행한다. API Server를 통해 생성 되거나 수정된 모든 리소스(Pod, Deployment, ConfigMap)의 정보는 etcd에 저장되며, 쿠버네티스는 이를 기준으로 클러스터 상태를 유지한다. 또한, Controller Manager와 Scheduler 같은 컴포넌트들은 etcd에 저장된 정보를 기반으로 동작하며, 클러스터에 장애가 발생하여도 etcd에 저장된 데이터를 기반으로 상태를 복원할 수 있다. 즉, etcd는 클러스터의 일관성과 복구 가능성을 보장하는 핵심 컴포넌트이다.

03-3. Worker Node 컴포넌트

✅ 1. kubelet

kubelet이 지속적으로 API Server를 watch 하면서, 자신에게 스케줄된 PodSpec을 가지고 온다.즉, PUSH 라기보다는 PULL/WATCH의 느낌이 더 강하다.

예시 : kubectl → API Server → Scheduler 노드 선정 → etcd에 기록 → kubelet이 확인(watch)

https://leehosu.github.io/kubelet

 

kubelet이란?

Docker 런타임은 k8s에서 지원을 안한다고 봐야한다.

Kubelet은 워커 노드에서 실행되는 핵심 에이전트로, 해당 노드에서 Pod가 정상적으로 구동되도록 관리하는 역할을 한다. 사용자가 YAML 파일을 작성 후, kubectl을 통해 명령을 수행하면 API Server에 요청이 간다. 후에 API Server는 kubelet에게 요청을 전달하고, kubelet은 PodSpec을 바탕으로 컨테이너 런타임(Docker, Containerd)에게 컨테이너 실행을 요청한다. 이후 kubelet은 해당 컨테이너의 상태를 확인하고 유지하는 역할을 한다.

✅ 2. kube-proxy

kube-proxy 역시 워커 노드에서 실행되는 네트워크 프록시로서, 사용자가 서비스(Service)에 요청을 보내면 해당 서비스(Service)가 가지고 있는 가상 IP(ClusterIP)와 포트를 실제로 동작중인 여러 파드(Pod)의 IP/Port로 연결해주는 역할을 한다. 이를 통해 kube-proxy는 서비스(Service) 단위의 부하 분산(Load Balancing)을 제공하며, 내부적으로는 iptables나 IPVS 같은 기능을 이용해 트래픽을 적절한 파드로 라우팅한다. 즉, kube-proxy 덕분에 사용자는 파드 개수나 위치를 신경 쓰지 않고 서비스 IP로만 접근해도 항상 정상적인 파드로 트래픽이 전달된다.

99. 참고 자료

kubelet이란?

Docker & Kubernetes Overview | CloudNet@와 함께하는 Amazon EKS 기본 강의