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

목차

· 컨테이너란?

· 도커란?

· 컨테이너 오케스트레이션 시스템

· 쿠버네티스란?

---

컨테이너란?

---

· 리눅스는 프로세스별로 자원을 격리해서 사용하는 cgroup과 특정 디렉터리로 권한을 제한하는 chroot 등으로 격리 환경을 구성할 수 있다. 여기에 디스크의 파일 변경 사항을 레이어 형태로 저장하는 파일 시스템을 합해 컨테이너 개념이 탄생했다.

 

· 도커를 이용하면 간단한 명령으로 컨테이너 이미지를 만들고, 저장소에 저장할 수 있다. 그리고 도커를 설치한 호스트에 해당 컨테이너 이미지를 다운로드해서 컨테이너를 실행할 수 있다.

컨테이너의 장점

1. 컨테이너가 등장하기 전에는 호스트에도 개발 환경에 필요한 설정을 똑같이 해야 했다. 이 과정에서 여러 장애 요소가 많이 발생하는 등 어려움이 있었다.

2. 컨테이너를 이용하면 개발 환경과 운영 환경의 차이 때문에 일어나는 장애를 막을 수 있다. 개발 환경에서 실행했던 컨테이너를 컨테이너 런타임(예:도커)만 있다면 실제 서버 어디에서든지 실행할 수 있기 떄문이다.

 

가상 머신 vs 컨테이너

· 기존 가상 머신은 하이퍼바이저 위에 가상 머신마다 게스트 운영체제가 있고, 그 위에 앱이 위치한다.

- 단점:

1. 각종 시스템 자원을 가상화하고 독립된 공간을 생성하는 작업은 하이퍼바이저를 거치므로, 일반 호스트에 비해 성능 손실이 발생한다.

2. 가상 머신은 게스트 운영체제를 사용하기 위한 라이브러리, 커널 등을 전부 포함하기 때문에 가상 머신을 배포하기 위한 이미지로 만들었을 때 이미지의 크기 또한 커진다. (수 기가의 가상 머신 이미지를 애플리케이션으로 배포하기는 부담스럽다)

- 하이퍼바이저:  운영체제와 가상 머신의 리소스를 분리해 VM의 생성과 관리를 지원

- 게스트 OS: 하이퍼바이저에 의해 생성되고 관리되는 운영체제.

<-> 호스트 OS: 서버를 부팅할 때 실행되는 운영체제

 

· 컨테이너는 호스트 운영 체제 위에 도커가 있고, 바로 앱이 위치한다. 

- 즉, 컨테이너가 구조상 레이어가 더 간단하므로 가상 머신보다 성능을 높이기 쉽다.

- hypervisor는 os 및 커널이 통째로 가상화되는 반면에, container는 filesystem의 가상화만을 이룬다.

 

도커란?

---

· 컨테이너 생태계에서 사실상의 표준

· 리눅스 컨테이너에 여러 기능을 추가하여 애플리케이션을 컨테이너로서 더 쉽게 사용하기 위한 오픈소스 프로젝트로 Go 언어로 작성

· 가상화된 공간을 생성하기 위해 리눅스 자체 기능인 chroot, 네임스페이스, cgroup을 사용하여 프로세스 단위의 격리 환경을 만들기 때문에 성능 손실이 거의 없다.

- namespace: 커널에 관련된 영역을 분리((mnt, pid, net, ipc, uts, user)

- cgroup: 자원에 관련된 영역을 분리(memory, CPU, I/O, network)

· 컨테이너에 필요한 커널은 호스트의 커널을 공유해 사용하고, 컨테이너 안에 애플리케이션을 구동하는 데 필요한 라이브러리 및 실행 파일만 존재하므로, 컨테이너를 이미지로 만들었을 때 이미지의 용량 또한 가상 머신에 비해 대폭 줄어든다.

- 즉, 컨테이너를 이지미로 만들어 배포하는 시간이 가상 머신 보다 빠르고, 가상화된 공간을 사용할 때 성능 손실이 거의 없다.

 

도커의 장점

1. 애플리케이션의 개발과 배포가 편하다.

· 도커 컨테이너는 호스트 OS 위에서 실행되는 격리된 공간이다. 따라서 컨테이너 자체에 특별한 권한을 주지 않은 한 컨테이너 내부에 여러 소프트웨어를 설치하고, 설정 파일을 수정해도 호스트 OS에 영향을 끼치지 않는다.

· 컨테이너 내부에서 작업을 마친 뒤 해당 컨테이너를 도커 이미지라는 일종의 패키지로 만들어 운영 환경에 배포할 수 있다. (운영 서버에 새로운 패키지 설치, 라이브러리 의존성 문제 등이 발생 x) 즉, 개발/운영 환경의 통합이 가능하다.

· 도커 이미지는 가상 머신 이미지와 달리 커널을 포함하지 않아 이미지 크기가 작다.

· 이미지 내용을 레이어 단위로 구성하여, 중복되는 레이어를 재사용할 수 있다. 따라서 애플리케이션 속도가 빨라진다.

 

2. 여러 애플리케이션의 독립성과 확장성이 높아진다.

· 컨테이너는 수 초 내로 생성, 시작이 가능하고, 여러 모듈에게 독립된 환경을 동시에 제공할 수 있어 마이크로서비스 구조에서 많이 사용된다.

- 마이크로서비스: 여러 모듈을 독립된 형태로 구성하는 구조다. 언어에 종속되지 않고, 변화에 빠르게 대응할 수 있고, 각 모듈의 관리가 쉬워진다. <-> 모놀리틱서비스: 소프트웨어의 여러 상호 작용하는로직을 하나의 프로그램 내에서 구동시키는 방식

 

 

컨테이너 오케스트레이션 시스템

---

· 실제 상용 서비스는 서버 하나에 장애가 발생했을 때 서비스에 영향을 받지 않도록 여러 대 서버를 통해 운영된다. 이런 상용 서비스 구성에 컨테이너만 단독으로 사용된다면 문제가 발생한다.

1. 컨테이너 이미지를 만들고 여러 대 서버에 컨테이너를 배포하는 전체 과정을 수동으로 제어해야 한다.

2. 서버에 장애가 발생했을 때 해당 서버의 컨테이너를 다른 서버로 옮기는 등의 작업을 수동으로 제어해야 한다.

 

· 컨테이너 오케스트레이션 시스템을 사용하면, 수동 제어 부분 모두를 자동화할 수 있다. 따라서 시스템 운영이 훨씬 수월해진다.

· 컨테이너 오케스트레이션 시스템으로 상용 서비스에 사용할 서버들을 클러스터로 구성하면, 서버 1대든 100대든 컨테이너를 한 번에 명령으로 자동 배포할 수 있다.

· 사용 중인 클러스터 일부에 장애가 발생하면 오케스트레이션 시스템은 알아서 장애가 발생한 서버에 있는 컨테이너들을 정상 운영 중인 다른 서버로 옮겨서 실행한다. 장애가 발생한 서버로 향하는 트래픽도 자동으로 중지시키고 새로 옮긴 컨테이너로 보낸다.

- 개발자는 상용 서비스의 안정성을 컨테이너 오케스트레이터에 맡겨 두고 장애가 발생한 서버를 고치면 된다.

 

· 즉, 도커 등의 컨테이너를 대규모 운영 환경에서 구축하기 위한 도구다.

 

쿠버네티스란?

---

· 배의 조타수란 그리스 단어에서 유래했다.

· 2014년 구글 내부에서 사용하던 컨테이너 오케스트레이션 시스템 보그를 오픈 소스 소프트웨어로 공개한 것이다.

· Kubernetes의 k와 s사이 글자 개수가 8개이므로, k8s라고도 표기한다.

 

쿠버네티스의 특징

1. 선언적 API

· 쿠버네티스의 가장 큰 설계 원칙은 AP가 선언적(declative)이라는 것이다. 

- 컨테이너가 어떤 상태이길 원하는지만 쿠버네티스에 설정하면 지속해서 컨테이너의 상태를 확인하고, 설정한 상태가 아니라면 그것이 맞게 맞춘다는 개념이다.

 

· 선언적 특징의 장점:
1. 원하는 상태를 정의해 유지할 수 있으므로 관리 비용이 줄어든다.

- 개발자가 상태를 보고 직접 명령을 실행할 필요가 없다.

2. 사용자가 설정한 명령이 없어지는 것을 염려하지 않아도 된다. ex) 네트워크 상태 등의 문제로 명령이 전달되지 않는 문제

3. 쿠버네티스에서 사용하는 컴포넌트 구현이 단순하고, 컴포넌트를 여러 개 실행해둘 수 있으므로 단일 장애점이 없다.

- 단일 장애점: 시스템 구성 요소 중 동작하지 않으면 시스템이 중단되는 요소

 

· 선언적 특징의 단점: 

1. (1.15 이전 버전에서는) 재시작 같은 단순한 작업을 쿠버네티스에서 할 수 없다.  앱 재시작은 쿠버네티스 시스템 내부 동작으로 사용자가 제어할 수 없기 때문이다.

 

2. 워크로드 분리

· 분산 시스템을 개발할 때 분산된 프로세스 각각이 잘 실행되는지, 이상이 생겼을 때는 어떻게 처리해야 하는지 등 시스템 안정성에 관한 고민을 많이 해야 한다. 이때 쿠버네티스는 운영체제처럼 분산된 프로세스의 관리를 추상화하는 레이어가 되므로 시스템 운영에 관한 고민을 덜어 준다. 

 

3. 어디서나 실행 가능

4. 활성화된 커뮤니티

 

출처

시작하세요! 도커/쿠버네티스

쿠버네티스 입문