컨테이너, 도커, 쿠버네티스

1. 컨테이너란?

 - 일반적인 가상 머신은 호스트 OS에 하이퍼바이저(Hypervisor)를 설치하고 그 위에 게스트 OS를 동작시키는 형태입니다. 하지만 컨테이너 기술은 호스트 OS에 컨테이너 런타임을 올리고 그 위에 프로세스로서 컨테이너를 동작시킵니다. 컨테이너란 호스트 OS의 커널을 공유하면서 분리된 프로세스로서 실행해 마치 가상 머신이 움직이고 있는 것처럼 보이게 하는 기술입니다.

 

 

2. 도커란?

 

- 도커(Docker)는 컨테이너를 동작시키기 위한 엔진 중 하나입니다. 2013년에 닷클라우드(dotCloud)에 의해 발표, 공개되었습니다.

 

- 도커의 특징

 첫번째. 컨테이너 관리 방식입니다. 도커에서는 Dockerfile이라는 정의 파일을 작성하여 동일한 컨테이너 이미지를 간단히 만들 수 있습니다. 이는 IaC(Infrastructure as Code2)를 구현하는 데 매우 적합한 소프트웨어입니다. 또 한, 컨테이너 이미지에는 애플리케이션과 그 실행 환경 설정이 포함되어 있기 때문에 도커 엔진만 설치되어 있다면 그 애플리케이션의 동작이 보장된다는 장점이 있습니다.

 두번째. 컨테이너 이미지를 저장, 공유하기 위한 에코시스템이 초기부터 준비되었다는 점입니다. 생성한 컨테이너 이미지는 각 환경에 확실히 배포할 수 있어야 의미가 있습니다. 도커에서는 도커 허브(Docker Hub)라고 하는, 컨테이너 이미지를 저장 및 공유할 수 있는 컨테이너 리포지토리가 제공됩니다. docker push/pull 명령으로 간단히 도커 허브에 컨테이너 이미지를 전송하거나 다운로드할 수 있습니다. 이를 통해 애플리케이션을 배포할 때 환경 설정 차이로 인해 발생하기 쉬운 문제를 해결할 수 있습니다. 즉, 개발 환경에서 스테이징 환경, 서비스 환경으로 동일한 컨테이너 이미지를 배포할 수 있으므로 테스트를 거친 컨테이너 이미지를 서비스 환경에 안정적으로 배포할 수 있습니다.

 

- 도커의 과제와 오케스트레이션 도구의 필요성

 보통 시스템 구성이 커지면 컨테이너 여러 개를 연결해 서비스 하나를 만들게 됩니다. 이런 구성일 때 문제 되는 것 중 하나로 컨테이너 사이의 통신과 가용성 확보가 있습니다. 서비스 환경에서 시스템을 동작시키기 위해 컴포넌트 각각을 다중화(redundancy)하는 것은 기본입니다. 예를 들어 컨테이너가 스케일 아웃 등을 하는 경우 상단에 있는 로드밸런서에 어떻게 연결하는 것이 좋을까? 라던가, 가상 머신 1대 안에서 컨테이너 여러 개를 동작시키는 경우 리소스 제어는 어떻게 하면 좋을까? 등은 한쪽 컨테이너에 부하가 높아져도 다른 한쪽 컨테이너의 성능이 떨어지지 않게 하는 다중화 관련 고민입니다. 또한 컨테이너가 동작하는 가상 머신에 장애가 발생했을 때 모든 컨테이너가 정지되고 서비스 전체가 멈춰버리는 현상을 막으려는 노력도 있습니다. 이러한 과제를 해결하기 위해 등장한 것이 바로 쿠버 네티스와 같은 컨테이너 오케스트레이션 도구 들입니다.

 

3. 쿠버네티스란?

 - 쿠버 네티스는 2014년 구글에서 발표되었습니다. 구글이 자사 서비스를 호스트 하기 위해 개발한 보그(Borg)라는 오케스트레이션 도구가 그 기원이라고 할 수 있습니다. 구글은 2015년 7월 21일 버전 1.0을 발표함과 동시에 리눅스 파운데이션과 공동으로 클라우드 네이티브 컴퓨팅 파운데이션(Cloud Native Computing Foundation, CNCF5)을 설립하여 쿠버 네티스를 CNCF에 기증하였습니다. 이후 쿠버네티스를 중심으로 한 에코시스템이 형성되면서 현재는 컨테이너 오케스트레이션 도구의 사실상 표준으로 불리는 위치가 되었습니다.

 

 - 쿠버 네티스의 개념

 쿠버 네티스에서는 데이터 플레인이라고 불리는 서버를 여러 대 실행시켜 그 위에 가상 오케스트레이션 계층을 구축하고 거기에서 컨테이너가 동작합니다. 컨테이너 이용자는 이를 통해 컨테이너 그룹을 하나의 큰 머신 리소스로 볼 수 있어 인프라를 추상화할 수 있습니다. 인프라 관리 측면에서 보더라도 여러 대의 서버로 구성이 가능하므로 단일 장애점(Single Point of Failure, SpoF)을 배제할 수 있는 장점이 있습니다.

 또한 쿠버 네티스는 어떤 가상 머신에서 어느 정도의 컨테이너를 동작시킬지를 관리하거나, 새로운 컨테이너를 배포할 때 어떤 가상 머신에 배포하면 좋을지 등을 자동으로 판단합니다. 장애가 발생한 컨테이너를 정지시키고 재시작하는 구조도 갖고 있습니다. 이러한 기능은 컨트롤 플레인이라는 마스터 노드 그룹에서 구현됩니다.

 

 - 쿠버 네티스의 기본 오브젝트

 * 파드

  쿠버네티스의 최소 단위며, 파드 하나 안에서는 하나 이상의 컨테이너를 동작시킬 수 있습니다. 파드에는 어떤 컨테이너 이미지를 사용할지 등을 설정합니다.

 

 * 레플리카셋

  레플리카셋(ReplicaSet)은 파드를 얼마나 동작시킬지 관리하는 오브젝트입니다. 레플리카셋에서 파드의 수를 설정하면 그만큼의 파드가 동작하는 것을 보장합니다.

 

 * 디플로이먼트

  배포 이력을 관리합니다. 애플리케이션의 새로운 버전을 릴리스하거나 부하 증가에 따라 레플리카셋 수를 변경하는 등 여러 가지 동작이 발생하는데 이들은 디플로이먼트로 관리할 수 있습니다. 또한 디플로이먼트는 적용 이력도 관리하므로 새로운 버전의 애플리케이션 릴리스 이후 문제가 발생하면 바로 이전 버전으로 쉽게 롤백할 수 있습니다. 서비스를 운영하는 상황 대부분에서 파드를 동작시킬 때는 디플로이먼트 단위로 관리합니다.

 

 * 서비스

 배포한 파드를 쿠버 네티스 클러스터 외부에 공개하기 위한 구조를 제공합니다. 대표적인 공개 방법은 로드밸런서를 사용하는 것입니다. 클러스터 내에 파드 여러 개를 동작시킨 경우 그 앞단에 로드밸런서를 배치하여 특정 파드를 클러스터 외부로 공개할 수 있습니다.