VM vs Container
쿠버네티스는 컨테이너를 관리하기 위한 오픈소스 플랫폼 입니다.
자세한 이야기를 하기전에 VM 과 컨테이너에 대해 먼저 이해할 필요가 있습니다.
VM (Virtual Machine)
VM(Virtual Machine) 이란 하나의 컴퓨터에 하이퍼바이저 소프트웨어를 사용하여 여러개의 Guest OS 환경을 만들어 사용하는 방식을 의미합니다.
사용자 정의 인프라를 반영구적으로 사용하는 환경이 필요할 경우 유용하게 사용할 수 있는 방식 입니다.
이는 Guest OS 에 종속적이고 OS 생성시 GB 단위로 메모리를 선택하여야 하며 Guest OS 의 전용 커널을 사용하기 때문에 부팅 속도가 느리고 무겁다는 단점이 있습니다. VM 부팅은 다음의 순서로 실행 됩니다.
하이퍼바이저 실행 -> Guest OS 실행 -> Guest OS 커널 및 필수 프로세스 실행 -> 어플리케이션 실행
Container
컨테이너는 하나의 OS 에서 격리된 어플리케이션을 실행하는 가상의 환경을 의미합니다.
어플리케이션은 이미지의 형태로 압축되어 있습니다.
컨테이너는 Guest OS 처럼 독립적으로 작동하지만 OS 커널을 공유하기 때문에 부팅 속도가 매우 빠릅니다.
또한 MB 단위의 메모리를 요구하기 때문에 VM 에 비해 불필요한 메모리 사용률을 줄일 수 있습니다.
이처럼 빠른 실행은 확장이 빈번히 일어나는 마이크로서비스에 유리한 환경 입니다.
Container Runtime
컨테이너 런타임은 컨테이너의 실행을 관리하는 소프트웨어 입니다. 이는 다음의 순서로 실행이 됩니다.
이미지 다운로드 -> 이미지 압축해제 -> 컨테이너 생성 및 실행
컨테이너 런타임은 High-level container runtime 과 Low-level container runtime 으로 나뉩니다.
앞서 말슴드린 실행의 순서에 번호를 붙인다면, High level container runtime 은 세 단계를 모두 담당하는 런타임을 의미하며 Low level container runtime 은 컨테이너 런타임의 세번째 단계(생성 및 실행)만을 담당하는 런타임을 의미합니다.
현재 가장 많이 사용되는 High-level container runtime 은 containerD 입니다.
OCI
OCI(Open Container Initiative) 는 Low level container runtime(컨테이너 생성) 의 표준 형식을 의미합니다.
lmctfy, rkt, railcar, runC 등이 있으며 runC 가 가장 많이 사용되고 있습니다.
runC 는 containderD 에 포함되어 있습니다.
Docker vs ContainerD
Docker 는 컨테이너 애플리케이션을 쉽게 빌드, 배포 및 실행할 수 있도록 돕는 종합 플랫폼으로 내부에서 ContainerD 를 사용합니다. ContainerD 는 Docker 의 관리도구를 포함하지 않고 컨테이너 런타임의 기능만을 수행하는 프로그램 입니다.
Kubernates
쿠버네티스(Kubernetes)는 분산된 여러 서버에서 실행되는 컨테이너들을 클러스터링하여 하나의 통합된 인프라처럼 관리하는 역할을 합니다. 이를 컨테이너 오케스트레이션이라고 합니다.
Pod & Node
파드는 쿠버네티스에서 배포할 수 있는 가장 작은 단위입니다. 하나 이상의 컨테이너, 네트워크, 스토리지로 이루어져 있습니다. 개념적으로 보면 docker-compose 와 비슷하다고 볼 수 있습니다.
노드는 쿠버네티스 실행 환경을 제공하는 컴퓨터 입니다. 각 노드는 파드를 실행하고 관리하는 역할을 합니다.
노드는 Control plane 과 Worker Node 로 나뉘어 집니다.
Control plane
컨트롤 플레인은 클러스터를 관리하는 역할을 하는 노드 입니다. 다음의 컨포넌트로 이루어져 있습니다.
- API Server: 클러스터와의 통신을 담당하는 역할
- Controller Manager: 클러스터의 상태를 관리하고 유지하는 역할
- Scheduler: 파드를 적절한 워커 노드에 배치하는 역할
- etcd: 클러스터의 설정 및 상태 정보를 저장하는 분산 키-값 저장소
Worker Node
워커 노드는 실제로 어플리케이션을 실행하는 노드입니다. 다음의 컴포넌트로 이루어져 있습니다.
- Kubelet: 노드의 상태를 관리하고 컨트롤 플레인과 통신하는 역할
- kube-proxy: 클러스터의 트래픽과 로드밸런싱을 관리하는 역할
- Container Runtime: 컨테이너를 생성하고 실행하는 역할
쿠버네티스가 가져온 변화들
쿠버네티스는 기존에 사용자가 직접 관리해야만 했던 것들을 자동으로 처리 해줍니다.
배포 자동화
VM 환경에서 분산 서비스를 배포하는 경우 사용자가 로드밸런서를 관리해야하는 등 수작업으로 처리해야할 부분이 존재합니다. 이에 반해 쿠버네티스는 롤링 업데이트를 통해 자동으로 서비스를 배포할 수 있도록 지원 합니다.
컨테이너 스케줄링을 통해 노드 리소스(CPU, 메모리)를 고려하여 최적의 위치에 배포를 진행하며
배포 중 오류 발생시 이전 버전으로 롤백 시키는 기능도 자동으로 수행합니다.
서비스 배포는 다음의 순서대로 진행 됩니다.
- 배포 요청이 들어옵니다. (
kubectl apply -f <name>.yaml)- etcd에 파드 객채를 저장 합니다.
- scheduler 가 적절한 워커 노드를 선택하고 이 정보를 api server에 업데이트합니다.
- api server 가 워커 노드에게 파드 실행 명령을 전송합니다.
- 워커 노드의 컨테이너 런타임이 컨테이너를 생성 및 실행합니다.
- 워커 노드의 kubelet 이 새로 생성한 파드의 헬스체크를 시작합니다.
- 헬스체크에 성공하면 kube-proxy 가 사용자 요청을 받을 수 있도록 트래픽 설정을 합니다.
(기존 파드는 삭제합니다)- 헬스체크에 실패하면 롤백 됩니다.
- 실행 결과를 kube api server 에 보고합니다.
오토 스케일링
특정 서비스에 트래픽이 몰리는 경우 수동 또는 자동으로 파드를 생성하여 스케일 아웃을 진행합니다.
반대로 트래픽이 적은 서비스의 경우 파드의 수를 감소시켜 리소스 낭비를 최소화 합니다.
오토스케일링은 다음의 순서대로 진행 됩니다.
- kubelet 이 주기적으로 파드의 상태를 모니터링 합니다.
- 오토 스케일링이 필요하다고 판단되는 경우 api server 에 요청을 전송합니다.
- ectd 에 변경된 스케일 정보를 저장합니다.
- 새로운 파드를 생성합니다.
장애 복구
파드가 종료된 경우 이를 감지하여 서비스를 재시동합니다. 만약 특정 노드가 죽는 경우 다른 노드로 파드를 이관합니다.
장애 복구는 다음의 순서대로 진행됩니다.
- kubelet 이 주기적으로 파드의 상태를 모니터링 합니다.
- 파드가 죽은 경우 api server 에 장애 복구 요청을 보냅니다.
- 새로운 파드를 생성합니다.
로드 밸런싱
파드의 수가 변경되더라도 하나의 서비스로 묶여 있다면 자동으로 로드밸런싱을 수행하여 트래픽을 균등하게 분배합니다.
인프라 형상관리
Kubernetes 설정은 YAML 파일을 통해 관리되며 이를 통해 인프라 형상 관리가 가능해집니다.
YAML 파일을 사용하면 클러스터 리소스(예: Pod, Service, Deployment 등)를 선언적 방식으로 정의할 수 있습니다.
이러한 파일을 버전 관리 시스템(Git 등)에서 관리하면 인프라 변경 사항을 코드 레벨에서 추적하고 관리할 수 있게 됩니다.
또한 파드는 이미지를 기반으로 실행되므로 이 또한 Docker Hub 와 같은 이미지 허브에서 형상관리를 할 수 있습니다.
언제 사용해야할까
쿠버네티스의 러닝 커브는 매우 높습니다. 개발, 네트워크, 모니터링, 컨테이너에 이르기까지 적용하는데 많은 시간이 소요될 수 있습니다. 또한 쿠버네티스 자체가 고사양의 서버를 필요로 하며 오토스케일링을 위해 일정 부분의 리소스를 항상 유지하고 있어여 하므로 비용이 많이 듭니다.
만약 팀 규모가 적고 관리하는 서비스 수가 적으며 예측 가능한 트래픽이 들어오는 경우엔 VM 환경에서 서비스를 관리하는게 유리할 수 있습니다. 그러나 수천개의 서비스를 관리해야하고 트래픽이 예측불가하다면 쿠버네티스는 최적의 인프라 솔루션이 될 수 있습니다.
