2019.11.01

'쿠버네티스, 도커, 컨테이너, 오케스트레이션' 바로 알기

Serdar Yegulalp | InfoWorld
소프트웨어 개발의 최신 동향을 관심 있게 지켜본 사람이라면 틀림없이 여러 번 접했을 두 가지 용어가 있다. 바로 도커(Docker)와 쿠버네티스(Kubernetes)다. 도커와 쿠버네티스는 사실상 ‘컨테이너(container)’와 ‘오케스트레이션(orchestration)’의 약칭이다.
 
ⓒGetty Images Bank

도커 컨테이너는 개발과 테스트를 거쳐 생산 단계로의 애플리케이션 이동 과정을 단순화했다. 반면, 도커와 쿠버네티스는 둘 다 애플리케이션의 구축 및 배치 방식을 새롭게 바꿨다. 즉, 하나의 스택이 아닌 마이크로서비스들의 모음 방식인 것이다.

도커와 쿠버네티스가 중요한 이유는 무엇인가? 도커와 쿠버네티스는 소프트웨어 개발을 어떻게 바꾸고 있나? 그 과정에서 각자 어떤 역할을 하나? 이 질문들에 대해 아래와 같이 답변해 보고자 한다.

도커와 컨테이너
컨테이너는 리눅스, 윈도우 등 최신 운영체제에서 지원된다. 운영체제와 격리되어 있으며 자체 완비된 초소형 환경에서 소프트웨어가 실행되게 하는 것이 컨테이너이다. VM에 비유되곤 했으나 VM은 아니다. VM에 비해 훨씬 군살이 적고 시작과 중단 속도가 빠르며 유연성과 이동성 역시 훨씬 뛰어나다. 불과 몇 초 안에 스핀 업과 다운은 물론 확장이 가능하기 때문에 클라우드와 같은 탄력적인 환경에서 앱을 실행하기 쉽게 만들어 준다. 

컨테이너화된 앱이 리눅스 등의 운영체제에 지원되기 시작한 지는 오래되었지만 컨테이너 작업이 사용자 친화적이라고 보기는 어려웠다. 반면, 오픈소스에서나 상업화된 형태에서나 도커라는 소프트웨어는 컨테이너를 사용자 친화적이고 개발자 친화적으로 만들어준다. 도커는 앱들을 컨테이너 이미지에 넣은 후 조직 등 어느 곳에서도 손쉽게 배치하여 재사용할 수 있도록 컨테이너용 공통 도구와 은유 방식을 제공한다.

즉, 컨테이너 이미지를 만들어 버전을 매긴 후 공유 및 이동은 물론 도커와 호환되는 호스트에 실행 컨테이너로 배치하는 작업을 눈 깜짝할 사이에 하게 해 주는 것이 도커다. 

도커와 컨테이너는 언제 사용하나?
도커와 컨테이너를 사용하기 가장 적합한 경우는 다음과 같은 특징이 하나 이상 있는 워크로드를 다룰 때이다. 

탄력적 확장성. 수요를 충족하려면 앱의 인스턴스를 몇 개나 실행해야 하는지 모르는 경우다. 컨테이너화된 앱이나 서비스는 수요를 충족하기 위한 확장이나 축소가 자유롭다. 배치하는 컨테이너의 인스턴스 수를 조절하면 되기 때문이다.
격리. 앱이 다른 앱들을 방해하는 것을 원하지 않는 경우다. 여러 개의 API 개정판을 충족하기 위해서 앱의 여러 버전을 나란히 실행 중인 경우일 수 있다. 아니면, 기본 시스템을 깨끗하게 유지하고 싶은 경우(언제나 좋은 생각)이다.
이동성. 다양한 환경에서 이 앱을 실행해야 하고 각각의 설정을 재현해야 하는 경우다. 해당 애플리케이션의 런타임 환경 전체를 컨테이너에 넣을 수 있다. 따라서, 개발자 데스크탑, 품질보증 테스트 시스템, 로컬 컴퓨터, 원격 클라우드 등 도커가 호환되는 호스트라면 어디든지 쉽게 해당 앱을 배치할 수 있다.

쿠버네티스와 컨테이너 오케스트레이션
컨테이너의 주요 목적은 프로세스나 애플리케이션을 상호 간에는 물론 기본 시스템과도 분리하는 것이다. 개별 컨테이너를 만들어서 배치하는 것은 쉽다. 그런데 만일 여러 개의 컨테이너(예: 데이터베이스, 웹 프론트엔드, 컴퓨터 백엔드)를 각각 배치, 연결, 관리, 확장하는 것에 신경 쓸 필요 없이 대형 애플리케이션 안에 넣어 하나의 기기로 관리하고 싶다면 어떨까? 그 모든 부분을 기능성 있는 전체로 편성(오케스트레이션)하는 방식이 필요할 것이다.

이 일을 하는 것이 바로 쿠버네티스다. 컨테이너가 유람선 승객이라면 쿠버네티스는 유람선 책임자에 해당된다.

구글에서 만들어진 프로젝트에 기반한 쿠버네티스는 컨테이너가 여러 개인 애플리케이션을 여러 개의 호스트에 배치하고 관리하는 작업을 자동화해 준다. 각각의 컨테이너를 직접 관리할 필요가 없다. 각각의 컨테이너가 네트워킹과 스토리지를 사용하는 방식 등과 같은 세부 내역을 비롯해 여러 컨테이너에 걸친 애플리케이션의 레이아웃을 개발자가 기술해 주면 쿠버네티스가 나머지 부분을 런타임에 처리해 준다. 비밀과 앱 구성과 같은 성가신 세부 내용의 관리도 쿠버네티스가 처리해 준다.

쿠버네티스를 제대로 사용하려면 일정 수준의 전문지식이 필요하지만, 예전보다는 훨씬 더 일괄적인 방식의 솔루션이다. 사용하기 쉬워진 이유 중에는 일반적인 애플리케이션을 만드는 방법을 쉽게 구할 수 있게 되었다는 점도 있다(예: 헴(Helm) 차트). 또 다른 이유는, 인기 있는 애플리케이션 스택과 개발 프레임워크들과 밀접하게 작업하는 유명 회사들(레드햇, 캐노니컬, 도커)이 만들어낸 쿠버네티스 배포판들이 풍부하기 때문이다. 

쿠버네티스와 컨테이너 오케스트레이션은 언제 사용하나?
컨테이너화된 앱 중에서 사용자 수가 적은 간단한 것은 일반적으로 오케스트레이션이 필요 없다. 쿠버네티스는 말할 것도 없다. 단, 앱의 기능이나 사용자 수가 사소한 수준을 넘어선다면, 오케스트레이션 시스템이 제공하는 도구를 새롭게 만들지 않을 수 없다. 언제 오케스트레이션을 활용해야 할지 판단하기 위한 대략적인 규칙들은 다음과 같다.

• 앱들이 복잡한 경우. 컨테이너가 2개 이상 관련된 애플리케이션이라면 복잡하다고 할 수 있다. 따라서, 사용자 수가 적은 보통의 앱들은 쿠버네티스보다는 도커 스웜 모드처럼 보다 최소한의 솔루션을 통해 오케스트레이션할 수 있다.
• 확장과 탄력성에 대한 수요가 높은 앱들인 경우. 쿠버네티스를 비롯한 오케스트레이션 도구들은 작업량의 균형을 잡아주고 컨테이너들을 스핀 업하여 수요를 충족시킬 수 있다. 변하는 조건에 대한 반응을 직접 코딩하는 대신에 시스템의 원하는 상태를 기술하는 방식으로 가능하다.
• 최신 CI/CD 기법을 최대한 활용하고 싶은 경우. 오케스트레이션 시스템들은 블루/그린 배치 또는 단계적 업그레이드들을 사용하는 앱들을 위한 배치 패턴을 지원한다. 

더욱 친화적인 개념이 등장해서 도커와 쿠버네티스가 무색해지거나 더 우아하게 컨테이너를 만들고 관리하는 방법으로 대체될 날이 올지도 모른다. 그러나 지금으로서는 도커와 쿠버네티스를 알고 이해하는 것이 필수적이다. ciokr@idg.co.kr


 



2019.11.01

'쿠버네티스, 도커, 컨테이너, 오케스트레이션' 바로 알기

Serdar Yegulalp | InfoWorld
소프트웨어 개발의 최신 동향을 관심 있게 지켜본 사람이라면 틀림없이 여러 번 접했을 두 가지 용어가 있다. 바로 도커(Docker)와 쿠버네티스(Kubernetes)다. 도커와 쿠버네티스는 사실상 ‘컨테이너(container)’와 ‘오케스트레이션(orchestration)’의 약칭이다.
 
ⓒGetty Images Bank

도커 컨테이너는 개발과 테스트를 거쳐 생산 단계로의 애플리케이션 이동 과정을 단순화했다. 반면, 도커와 쿠버네티스는 둘 다 애플리케이션의 구축 및 배치 방식을 새롭게 바꿨다. 즉, 하나의 스택이 아닌 마이크로서비스들의 모음 방식인 것이다.

도커와 쿠버네티스가 중요한 이유는 무엇인가? 도커와 쿠버네티스는 소프트웨어 개발을 어떻게 바꾸고 있나? 그 과정에서 각자 어떤 역할을 하나? 이 질문들에 대해 아래와 같이 답변해 보고자 한다.

도커와 컨테이너
컨테이너는 리눅스, 윈도우 등 최신 운영체제에서 지원된다. 운영체제와 격리되어 있으며 자체 완비된 초소형 환경에서 소프트웨어가 실행되게 하는 것이 컨테이너이다. VM에 비유되곤 했으나 VM은 아니다. VM에 비해 훨씬 군살이 적고 시작과 중단 속도가 빠르며 유연성과 이동성 역시 훨씬 뛰어나다. 불과 몇 초 안에 스핀 업과 다운은 물론 확장이 가능하기 때문에 클라우드와 같은 탄력적인 환경에서 앱을 실행하기 쉽게 만들어 준다. 

컨테이너화된 앱이 리눅스 등의 운영체제에 지원되기 시작한 지는 오래되었지만 컨테이너 작업이 사용자 친화적이라고 보기는 어려웠다. 반면, 오픈소스에서나 상업화된 형태에서나 도커라는 소프트웨어는 컨테이너를 사용자 친화적이고 개발자 친화적으로 만들어준다. 도커는 앱들을 컨테이너 이미지에 넣은 후 조직 등 어느 곳에서도 손쉽게 배치하여 재사용할 수 있도록 컨테이너용 공통 도구와 은유 방식을 제공한다.

즉, 컨테이너 이미지를 만들어 버전을 매긴 후 공유 및 이동은 물론 도커와 호환되는 호스트에 실행 컨테이너로 배치하는 작업을 눈 깜짝할 사이에 하게 해 주는 것이 도커다. 

도커와 컨테이너는 언제 사용하나?
도커와 컨테이너를 사용하기 가장 적합한 경우는 다음과 같은 특징이 하나 이상 있는 워크로드를 다룰 때이다. 

탄력적 확장성. 수요를 충족하려면 앱의 인스턴스를 몇 개나 실행해야 하는지 모르는 경우다. 컨테이너화된 앱이나 서비스는 수요를 충족하기 위한 확장이나 축소가 자유롭다. 배치하는 컨테이너의 인스턴스 수를 조절하면 되기 때문이다.
격리. 앱이 다른 앱들을 방해하는 것을 원하지 않는 경우다. 여러 개의 API 개정판을 충족하기 위해서 앱의 여러 버전을 나란히 실행 중인 경우일 수 있다. 아니면, 기본 시스템을 깨끗하게 유지하고 싶은 경우(언제나 좋은 생각)이다.
이동성. 다양한 환경에서 이 앱을 실행해야 하고 각각의 설정을 재현해야 하는 경우다. 해당 애플리케이션의 런타임 환경 전체를 컨테이너에 넣을 수 있다. 따라서, 개발자 데스크탑, 품질보증 테스트 시스템, 로컬 컴퓨터, 원격 클라우드 등 도커가 호환되는 호스트라면 어디든지 쉽게 해당 앱을 배치할 수 있다.

쿠버네티스와 컨테이너 오케스트레이션
컨테이너의 주요 목적은 프로세스나 애플리케이션을 상호 간에는 물론 기본 시스템과도 분리하는 것이다. 개별 컨테이너를 만들어서 배치하는 것은 쉽다. 그런데 만일 여러 개의 컨테이너(예: 데이터베이스, 웹 프론트엔드, 컴퓨터 백엔드)를 각각 배치, 연결, 관리, 확장하는 것에 신경 쓸 필요 없이 대형 애플리케이션 안에 넣어 하나의 기기로 관리하고 싶다면 어떨까? 그 모든 부분을 기능성 있는 전체로 편성(오케스트레이션)하는 방식이 필요할 것이다.

이 일을 하는 것이 바로 쿠버네티스다. 컨테이너가 유람선 승객이라면 쿠버네티스는 유람선 책임자에 해당된다.

구글에서 만들어진 프로젝트에 기반한 쿠버네티스는 컨테이너가 여러 개인 애플리케이션을 여러 개의 호스트에 배치하고 관리하는 작업을 자동화해 준다. 각각의 컨테이너를 직접 관리할 필요가 없다. 각각의 컨테이너가 네트워킹과 스토리지를 사용하는 방식 등과 같은 세부 내역을 비롯해 여러 컨테이너에 걸친 애플리케이션의 레이아웃을 개발자가 기술해 주면 쿠버네티스가 나머지 부분을 런타임에 처리해 준다. 비밀과 앱 구성과 같은 성가신 세부 내용의 관리도 쿠버네티스가 처리해 준다.

쿠버네티스를 제대로 사용하려면 일정 수준의 전문지식이 필요하지만, 예전보다는 훨씬 더 일괄적인 방식의 솔루션이다. 사용하기 쉬워진 이유 중에는 일반적인 애플리케이션을 만드는 방법을 쉽게 구할 수 있게 되었다는 점도 있다(예: 헴(Helm) 차트). 또 다른 이유는, 인기 있는 애플리케이션 스택과 개발 프레임워크들과 밀접하게 작업하는 유명 회사들(레드햇, 캐노니컬, 도커)이 만들어낸 쿠버네티스 배포판들이 풍부하기 때문이다. 

쿠버네티스와 컨테이너 오케스트레이션은 언제 사용하나?
컨테이너화된 앱 중에서 사용자 수가 적은 간단한 것은 일반적으로 오케스트레이션이 필요 없다. 쿠버네티스는 말할 것도 없다. 단, 앱의 기능이나 사용자 수가 사소한 수준을 넘어선다면, 오케스트레이션 시스템이 제공하는 도구를 새롭게 만들지 않을 수 없다. 언제 오케스트레이션을 활용해야 할지 판단하기 위한 대략적인 규칙들은 다음과 같다.

• 앱들이 복잡한 경우. 컨테이너가 2개 이상 관련된 애플리케이션이라면 복잡하다고 할 수 있다. 따라서, 사용자 수가 적은 보통의 앱들은 쿠버네티스보다는 도커 스웜 모드처럼 보다 최소한의 솔루션을 통해 오케스트레이션할 수 있다.
• 확장과 탄력성에 대한 수요가 높은 앱들인 경우. 쿠버네티스를 비롯한 오케스트레이션 도구들은 작업량의 균형을 잡아주고 컨테이너들을 스핀 업하여 수요를 충족시킬 수 있다. 변하는 조건에 대한 반응을 직접 코딩하는 대신에 시스템의 원하는 상태를 기술하는 방식으로 가능하다.
• 최신 CI/CD 기법을 최대한 활용하고 싶은 경우. 오케스트레이션 시스템들은 블루/그린 배치 또는 단계적 업그레이드들을 사용하는 앱들을 위한 배치 패턴을 지원한다. 

더욱 친화적인 개념이 등장해서 도커와 쿠버네티스가 무색해지거나 더 우아하게 컨테이너를 만들고 관리하는 방법으로 대체될 날이 올지도 모른다. 그러나 지금으로서는 도커와 쿠버네티스를 알고 이해하는 것이 필수적이다. ciokr@idg.co.kr


 

X