컨테이너와 쿠버네티스 소개: 도커와 오케스트레이션

 한 4차례 정도 이 제목과 관련된 주제로 글을 복사 했었다. 그 글은 Rancher의 공식 사이트에 있는 글을 그대로 가져왔었다. 이번 시간에는 그 글들을 통합해서 하나의 글로 적어보려고 한다.

 

 컨테이너 기술과 도커

컨테이너는 직,간접적으로 많이 들어봤을 것이다. 개인적으로 이름을 잘 정했다고 생각한 만큼, 이해하기가 쉽다고 생각한다. 컨테이너는 다음과 같은 사진으로 설명할 수 있다.
왼쪽은 컨테이너를 설명한 사진이고, 오른쪽은 os를 설명한 사진이다.

뭐가 다르다고는 말은 못하겠어도, 무언가가 다르다라는 것은 느낄 것이다.

왼쪽 사진은 Application이 7개가 있는데, 이 앱들을 오른쪽에서는 Applications라고 칭할 수 있다는 것도 맞는 말이다.

그럼 생각해보자. 왜 왼쪽 사진은 앱들이 네모칸에 분리되어 존재하는가? 

그건 바로 버전에서 오는 호환성 차이라고 말할 수 있겠다.

아래 그림을 통해서 확인해보자

'App1'은 Java8 버전에 의해서 동작 중이고, 'App2'는 Java11 버전에 의해서 동작 중이다.

독자의 무의식 중에 이런 생각이 있을 수 있다.
'최신 버전을 적용하면 당연히 좋은 거 아냐?'

그러나 이건 틀린 말이다. 예를 들어 App1과 App2가 Java8 버전으로 개발 되었고 상용화가 되고 있는 상황이라고 생각해보자. 이때 Java가 11버전으로 업데이트를 해야 되는 상황이다. App1과 App2 모두 Java8에서 동작 했던 것 그대로 동작 할 수 있을 보장은 없다. 오히려 이슈만 생길 것이다. 그런데, 막상 업데이트를 해보니, App2는 Java8때보다 더 좋은 성능을 보이지만, App1은 그렇지 않았다. 여기서 영감을 얻은 것이다.

 

App이 구동할 수 있는 최선의 환경을 마련해보자!

 

그래서 각 공간을 마련하고, 이름을 컨테이너라고 지었다. 기존의 서버를 '화물선'이라고 칭하면 '컨테이너'를 배에 올림으로써 컨테이너 안에 있는 것들이 손상 없이, 보존이 가능한 것이다. 

 

it가 아닌 실제 컨테이너를 기준으로, 과일을 생각해보자. 만약 컨테이너가 없었다면, 과일 별로 정리가 안 될것이다. 하나의 배에 사과, 바나나, 레몬과 포도 등 섞여 있을 테지만, 컨테이너가 있음으로써 과일의 종류별로 정리가 된 상태로 안전하게 배송할 수 있다. 즉, 다시 it 컨테이너로 되돌아오면, 하나의 앱을 안전하게 구동 시키는 환경을 만든 공간이라고 생각할 수 있다.

 

그럼 실제 물리 컨테이너도 결국은 컨테이너를 제조를 한 사람이 있다. 그렇기에 컨테이너가 만들어진 것이다.

it에서는, 컨테이너 제조업자를 docker라고 부른다.  즉, docker가 있어서 컨테이너를 이용할 수 있는 것이다.이를 그림으로 표현하면 다음과 같다.

 

os에서 docker를 설치하면, 컨테이너를 만들 수 있는 것이다.

 

쿠버네티스, 컨테이너의 관리자

쿠버네티스 역시 많이 들어본 용어일 것이다.

개인적으로 쿠버네티스를 가장 잘 설명한 사진은 이 사진이라고 생각한다.

파랑 옷을 입은 남자가 컨테이너를 드느라 애를 쓰고 있는 사진이다. 이 사진을 보고 쿠버네티스의 기능을 알아보자.

 

1. 컨테이너를 분산 배치

하나의 서버에 컨테이너가 10개가 저장 되어 있다면, 쿠버네티스를 통해 여러대의 서버로 분산 시켜서 관리가 가능하다.

 

2. 컨테이너의 모니터링

컨테이너들의 상태를 지속적으로 확인, 자동 복구, 재시작 등이 가능하다.

 

3. 컨테이너의 자원을 제한

컨테이너가 소모를 할 수 있는 자원을 제한해서, 컨테이너 간에 자원을 공유를 시킬 수 있다

 

정확히는, 쿠버네티스는 컨테이너의 오케스트레이션 종류 중 1개이다.

여기서, 오케스트레이션은 원래 음악 용어이다. 음악에서의 오케스트레이션 뜻은 연주자들이 합주를 이루어서, 음악을 만드는 것을 말한다. 이걸 도커로 가져오면, 쿠버네티스라는 지휘자를 통해 it인프라가 잘 갖춰져 있는 상황을 볼 수 있겠다.

 

이런 배경을 알고보니, 이 사진은 참 많은 의미를 가지는 것 같다.