2018.03.30

콘테이너 혁명 이끈다··· 쿠버네티스 배포판 12가지

Serdar Yegulalp | InfoWorld
쿠버네티스(Kubernetes)는 대규모 콘테이너 오케스트레이션(orchestration)이 필요한 상황이라면 최우선적으로 검토해야 할 프로젝트로 자리잡았다. 구글에서 나온 이 오픈소스 콘테이너 시스템은 제대로 된 지원 속에서 빠르게 발전하고 있다.

동시에 쿠버네티스는 복잡하며 설치와 구성이 까다롭다. 어려운 작업의 많은 부분을 최종 사용자가 직접 해야 한다. 따라서 혼자서 하기보다는 쿠버네티스가 지원, 관리되는 구성요소로 포함되어 있는 전체적인 콘테이너 솔루션을 찾는 방안이 추천되고 있다.

오늘날 두각을 나타내는 쿠버네티스 제품 12가지를 선정해봤다. 쿠버네티스와 콘테이너 도구가 통합된 배포판들이다. 다양한 업체들이 리눅스(Linux) 커널과 그 유저랜드(userland)를 제공하는 것과 유사하다.

이 선정 목록에는 아마존 EKS(Amazon EKS)나 구글 쿠버네티스 엔진(Google Kubernetes Engine)과 같은 전용 클라우드 서비스가 빠져 있다. 그 대신, 로컬에서 실행되거나 클라우드 호스트 옵션으로 실행될 수 있는 소프트웨어 배포판이 주로 포함되어 있다.

코어OS 텍토닉
코어OS(CoreOS)는 콘테이너 중심의 리눅스 배포판(도커와 호환되지만 독단적인 이미지 형식과 자체 런타임이 있음)과 ‘엔터프라이즈급 쿠버네티스’ 배포판을 제공한다. 이 두 개가 합쳐진 것이 코어OS 텍토닉(Tectonic) 스택의 기반을 형성한다.

코어OS 운영 체제인 콘테이너 리눅스(Container Linux)는 콘테이너화된 구성요소의 모음으로 제공된다는 점에서 차별점을 지닌다. 이러한 방식은 실행 중인 애플리케이션을 중단할 필요 없이 OS에 대한 자동화된 업데이트를 가능하게 해 준다. 코어OS는 ‘한 번의 클릭’으로 쿠버네티스로 업데이트가 가능하다는 장점도 있다. 코어OS 텍토닉은 아마존 웹 서비스(AWS), 마이크로소프트 애저, 베어 메탈에서 실행된다.

캐노니컬 쿠버네티스 배포판
우분투 리눅스 제조사 캐노니컬(Canonical)은 자체적인 쿠버네티스 배포판을 제공한다. 캐노니컬 쿠버네티스 배포판의 큰 장점 가운데 하나는 그 근간에 인기 우분투 리눅스 배포판이 있다는 점이다. 캐노니컬은 자신의 스택이 그 어떤 클라우드나 온프레미스 배치에서도 작동할 것이라고 주장한다. GPU로 가동되는 워크로드와 GPU로 가동되는 워크로드 모두 지원된다. 유료 고객은 캐노니컬 엔지니어들이 제공하는 쿠버네티스 클러스터 원격 관리 서비스를 받을 수 있다.

캐노니컬과 랜처 랩스(Rancher Labs)는 클라우드 네이티브 플랫폼(Cloud Native Platform)이라는 제품을 공동으로 관리한다. 캐노니컬 쿠버네티스 배포판을 랜처의 콘테이너 관리 플랫폼과 결합시킨 제품이다. 쿠버네티스를 이용해 각 클러스터에서 실행되는 콘테이너를 관리하고 랜처를 이용해 여러 개의 쿠버네티스 클러스터를 관리하려는 것이다. 클라우드 네이티브 플랫폼은 랜처 2.0 과 함께 사용 가능하게 될 예정이다. 랜처 2.0은 현재 베타 릴리즈 형태로 이용할 수 있다.

도커 커뮤니티 에디션/도커 엔터프라이즈
많은 이들에게는 도커야말로 콘테이너다. 2014년 이래 도커는 자체 클러스터링 및 오케스트레이션 시스템인 도커 스웜(Docker Swarm)을 보유해 왔다. 최근까지만 해도 쿠버네티스의 대항마였다. 그런데 2017년 10월, 도커가 쿠버네티스를 추가하겠다고 발표했다. 즉, 수정하지 않은 바닐라(vanilla) 상태로 표준 팩인(pack-in)으로 도커 커뮤니티 에디션(Docker Community Edition)과 도커 엔터프라이즈(Docker Enterprise) 모두에 추가하겠다는 것이다.

간단히 말해 도커 사는 콘테이너 오케스트레이션의 불길한 징조를 파악했고 대규모의 복잡한 콘테이너 환경을 관리함에 있어 스웜보다 쿠버네티스가 더 적합하다는 것을 인정한 것이다. 그러나 도커에는 여전히 “스웜 모드”가 포함되어 있다. 보다 평범한 클러스터링 작업을 위한 것이다. 예를 들면, 크기가 많이 늘어날 가능성이 없는 방화벽 뒤의 로컬 애플리케이션이다.

헵티오 쿠버네티스 서브스크립션
쿠버네티스를 만든 크레이그 맥루키(Craig McLuckie)와 조 베다(Joe Beda)는 쿠버네티스를 중심으로 한 서비스와 제품을 제공하기 위해 헵티오(Heptio)를 창립했다. 이들의 첫 주요 작품이 헵티오 쿠버네티스 서브스크립션(Heptio Kubernetes Subscription)(HKS)이다. 이는 헵티오의 유료 지원이 24시간 제공되는 쿠버네티스 배치판으로, 가격은 월 2,000달러에서 시작한다.

헵티오는 업체에 구속되지 않는 엔터프라이즈급 쿠버네티스라는 것이 주요 장점이다. 배치판은 퍼블릭 클라우드나 개인 하드웨어에서 실행 가능하다. 쿠버네티스 구성 관리용으로 헵티오에서 제공하는 모든 도구는 오픈소스이며 해결책은 지원되는 클러스터로 직접 전달된다.

메소피어 DC/OS
메소피어(Mesosphere) DC/OS는 아파치 메소(Apache Meso)를 이용해 기계 클러스터를 단일 자원으로 바꾼다. 이는 동적으로 분할되어 복수의 애플리케이션에 사용 가능하다. DC/OS 상의 많은 애플리케이션 패키지 중 하나로 쿠버네티스가 지원된다. 따라서 DC/OS 클러스터에 걸쳐 쿠버네티스를 설치, 실행, 업데이트 할 수 있다.

DC/OS가 쿠버네티스 배포판인지 여부는 논란의 소지가 있다. 쿠버네티스가 DC/OS의 일부는 아니지만 다른 지원되는 애플리케이션과 같이 DC/OS를 통해 배치될 수 있기 때문이다. 리눅스 애플리케이션이 리눅스 배포판의 패키지 관리 시스템을 통해 사용 가능하게 되는 것과 비슷하다.

그럼에도 불구하고, 메소피어의 쿠버네티스에 대한 접근법은 쿠버네티스의 작동 방식을 밀접하게 따른다. 즉, 쿠버네티스의 주류 커뮤니티 배포판을 활용함으로써 기존 도구들과의 고도의 호환성을 보장한다.

미란티스 클라우드 플랫폼
미란티스(Mirantis) 클라우드 플랫폼은 오픈스택, 쿠버네티스 또는 이 둘을 합친 것을 “애자일 인프라 플랫폼”(미란티스의 표현)용 기판(substrate)으로 통합시킨다. 간단히 말하면, 미란티스 클라우드 플랫폼은 VM, 콘테이너, 베어 메탈 서버의 오케이스트레이션을 위한 단일 통합 솔루션이다.

플랫폼에 배치되는 애플리케이션은 ‘데브옵스 스타일’로 수명주기에 걸쳐 관리된다. 이때 구성 관리 도구로 솔트(Salt)를 사용하고 애플리케이션이 정확하게 배치될 수 있도록 통합 CI/CD 지원이 제공된다.

미란티스 클라우드 플랫폼은 베어메탈 상에서, 오픈스택 클러스터에서, 또는 퍼블릭 클라우드 상에서 직접 쿠버네티스를 실행할 수 있다. 미란티스의 주장에 따르면, 미란티스 클라우드 플랫폼은 쿠버네티스와 작업을 쉽게 만들어 준다고 한다. 왜냐하면 쿠버네티스 밑의 인프라 프로비저닝 작업은 최종 사용자 몫이 아니기 때문이다.

플랫폼9 매니지드 쿠버네티스
대부분의 쿠버네티스 배포판은 쿠버네티스를 안팎으로 그리고 위아래로 관리 가능하게 만드는 것에 초점을 맞추고 있다. 플랫폼9 매니지드 쿠버네티스는 다양한 환경(로컬 베어메탈, 원격 퍼블릭 클라우드 등)에서도 실행되지만 플랫폼9의 엔지니어들에 의해 서비스 형태로 원격 관리된다.

플랫폼9는 매니지드 쿠버네티스에 대한 업데이트를 약 6주에 한번씩 고객 감시 하에 내보낸다. 보통은 쿠버네티스 클러스터에 수동으로 추가해야 하는 함수들(예: 멀티 테넌시(multi-tenancy) 시나리오를 위한 사용자 할당량)이 플랫폼9에 의해 제공된다. 플랫폼9의 피션(Fission) 프로젝트와의 통합도 포함되어 있다. 이 프로젝트는 서버리스 컴퓨트(severless compute) 또는 서비스로서의 함수(FaaS) 시스템이라고도 하는데 거의 대부분의 프로그래밍 언어와 콘테이너화된 런타임으로 작동한다.

랜처 2.0
랜처 랩스는 쿠버네티스를 콘테이너 관리 플랫폼 내부로 통합시켰다. 이 플랫폼은 간단히 랜처라고 한다. 버전 2.0은 현재 베타 상태이다.

랜처 2.0은 다른 쿠버네티스 배포판에 비해 높은 수준에서 작동한다. 리눅스 호스트, 도커 콘테이너, 쿠버네티스 노드 위에 자리잡고 위치나 인프라와 관계 없이 이들을 모두 가까운 거리에서 관리한다. 심지어는 아마존 EKS, 구글 쿠버네티스 엔진, 애저 콘테이너 서비스, 기타 서비스로서의 쿠버네티스 클라우드에서 쿠버네티스 클러스터를 관리할 수 있다.

랜처에는 자체 쿠버네티스 배포판도 포함되어 있다. 랜처는 쿠버네티스 클러스터를 설치하고 쿠버네티스를 특정 환경에 맞게 맞추는 과정에서 힘든 일을 많이 없애면서도 그러한 맞춤 과정이 쿠버네티스로의 원활한 업그레이드에 방해되지 않도록 설계됐다. 빠르게 움직이고 끊임없이 업데이트 되는 프로젝트에서는 중요하게 고려되는 사안이다.

레드햇 오픈시프트
레드햇 오픈시프트(Red Hat OpenShift)는 레드햇의 PaaS 제품이다. 원래는 애플리케이션을 패키지 하기 위해 헤로쿠(Heroku) 빌드팩(buildpack)같은 “카트리지(cartridge)”를 사용했다. 패키징 된 애플리케이션은 “기어(gear)”라고 하는 콘테이너에 배치됐다.

그러다 도커가 등장했고, 오픈시프트는 새로운 콘테이너 이미지와 런타임 표준을 활용하기 위해 재작업을 거쳤다. 어쩔 수 없이 레드햇도 쿠버네티스를 오픈시프트 내 오케스트레이션 기술로 채택했다.

오픈시프트는 PaaS의 모든 요소에 추상화와 자동화를 제공하기 위해 개발됐다. 이 추상화와 자동화는 쿠버네티스에도 확장된다. 쿠버네티스는 여전히 관리 부담이 꽤 크다. 따라서 오픈시프트는 PaaS 배치라는 더 큰 임무의 일환으로 그러한 부담을 덜어주기 위해 사용될 수 있다.

스택큐브
콘테이너 실행을 위한 Hyper.sh 클라우드 서비스를 제공하는 업체인 하이퍼HQ(HyperHQ)는 “쿠버네티스 중심 오픈스택(OpenStack) 배포판”인 스택큐브(Stackube)를 개발했다. 보통 오픈스택은 컴퓨트 노드의 프로비저닝 및 관리를 위해 노바(Nova)라는 구성요소를 사용하지만 스택큐브는 그 대신 쿠버네티스를 사용한다. 그러나 그 외에는 “바닐라” 오픈스택과 쿠버네티스를 사용하고 오픈스택 플러그인에 의해 처리되는 모든 상세한 추가 내용이 포함된다.

하이퍼HQ에서 주장하는 스택큐브의 큰 장점은 어떤 콘테이너 런타임이 사용되느냐에 따라 다양한 정도의 멀티테넌시를 제공할 수 있다는 것이다. ‘소프트’한 멀티테넌시를 위해서라면 도커가 있다. 보다 강력한 자원의 분리를 위해서라면 하이퍼바이저(hypervisor)급 분리를 사용하는 하이퍼콘테이너(HyperContainer)가 있다.

서비스 플랫폼으로서의 수세 클라우드
유럽에서 널리 인기를 얻고 있는 리눅스 배포판으로 가장 잘 알려진 수세(SUSE) 역시 SUSE CaaS 플랫폼을 제공한다. 개념적으로는 코어OS 텍토닉을 연상시킨다. 콘테이너를 실행하는 베어메탈 “마이크로” OS, 콘테이너 오케스트레이션 시스템으로서의 쿠버네티스, 내장 이미지 레지스트리, 클러스터 구성 도구를 한 묶음으로 합쳐 놓은 것이다.

수세 CaaS 플랫폼은 로컬 베어메탈은 물론 퍼블릭 클라우드 상에서 실행 가능하다. 단, 수세에게는 “현재 근간이 되는 클라우드 인프라로의 통합을 전혀 지원하지 않는다”라는 원칙이 있다. 즉, 수세 CaaS 플랫폼은 아마존 EKS나 구글 쿠버네티스 엔진을 보완하는 것이 아닌 피해가기 위해 설계됐다. 따라서 복수의 클라우드와 데이터센터에 걸쳐 콘테이너를 실행하는 것이 가능하다.

텔레큐브
텔레포트(Teleport) SSH 서버를 만든 그래비테이셔널(Gravitational)은 텔레큐브(Telekube)도 만든다. 로컬 또는 원격 클러스터 상에서 실행되는 “생산 강화된(production hardened)” 쿠버네티스 배포판이다. 텔레큐브는 사설 SaaS 플랫폼을 위한 솔루션 역할을 하거나 쿠버네티스를 여러 지역 또는 호스팅 제공업체를 통해 서비스로 실행하기 위한 솔루션으로 고안됐다.

텔레큐브 상의 애플리케이션들은 쿠버네티스 상의 콘테이너에서 실행될 준비가 되어 있어야 한다. 이들은 또한 “번들”로 패키지화한 후 쿠버네티스 클러스터로 게시하여 배포되어야 한다. 번들화 하려면 콘테이너 기반 애플리케이션 배치에 필요한 다른 모든 준비 이외에도 추가 작업이 필요하지만, 번들 목록 이외에는 텔레큐브 관련 추가 내용 중에서 관리해야 할 것이 없다. ciokr@idg.co.kr 



2018.03.30

콘테이너 혁명 이끈다··· 쿠버네티스 배포판 12가지

Serdar Yegulalp | InfoWorld
쿠버네티스(Kubernetes)는 대규모 콘테이너 오케스트레이션(orchestration)이 필요한 상황이라면 최우선적으로 검토해야 할 프로젝트로 자리잡았다. 구글에서 나온 이 오픈소스 콘테이너 시스템은 제대로 된 지원 속에서 빠르게 발전하고 있다.

동시에 쿠버네티스는 복잡하며 설치와 구성이 까다롭다. 어려운 작업의 많은 부분을 최종 사용자가 직접 해야 한다. 따라서 혼자서 하기보다는 쿠버네티스가 지원, 관리되는 구성요소로 포함되어 있는 전체적인 콘테이너 솔루션을 찾는 방안이 추천되고 있다.

오늘날 두각을 나타내는 쿠버네티스 제품 12가지를 선정해봤다. 쿠버네티스와 콘테이너 도구가 통합된 배포판들이다. 다양한 업체들이 리눅스(Linux) 커널과 그 유저랜드(userland)를 제공하는 것과 유사하다.

이 선정 목록에는 아마존 EKS(Amazon EKS)나 구글 쿠버네티스 엔진(Google Kubernetes Engine)과 같은 전용 클라우드 서비스가 빠져 있다. 그 대신, 로컬에서 실행되거나 클라우드 호스트 옵션으로 실행될 수 있는 소프트웨어 배포판이 주로 포함되어 있다.

코어OS 텍토닉
코어OS(CoreOS)는 콘테이너 중심의 리눅스 배포판(도커와 호환되지만 독단적인 이미지 형식과 자체 런타임이 있음)과 ‘엔터프라이즈급 쿠버네티스’ 배포판을 제공한다. 이 두 개가 합쳐진 것이 코어OS 텍토닉(Tectonic) 스택의 기반을 형성한다.

코어OS 운영 체제인 콘테이너 리눅스(Container Linux)는 콘테이너화된 구성요소의 모음으로 제공된다는 점에서 차별점을 지닌다. 이러한 방식은 실행 중인 애플리케이션을 중단할 필요 없이 OS에 대한 자동화된 업데이트를 가능하게 해 준다. 코어OS는 ‘한 번의 클릭’으로 쿠버네티스로 업데이트가 가능하다는 장점도 있다. 코어OS 텍토닉은 아마존 웹 서비스(AWS), 마이크로소프트 애저, 베어 메탈에서 실행된다.

캐노니컬 쿠버네티스 배포판
우분투 리눅스 제조사 캐노니컬(Canonical)은 자체적인 쿠버네티스 배포판을 제공한다. 캐노니컬 쿠버네티스 배포판의 큰 장점 가운데 하나는 그 근간에 인기 우분투 리눅스 배포판이 있다는 점이다. 캐노니컬은 자신의 스택이 그 어떤 클라우드나 온프레미스 배치에서도 작동할 것이라고 주장한다. GPU로 가동되는 워크로드와 GPU로 가동되는 워크로드 모두 지원된다. 유료 고객은 캐노니컬 엔지니어들이 제공하는 쿠버네티스 클러스터 원격 관리 서비스를 받을 수 있다.

캐노니컬과 랜처 랩스(Rancher Labs)는 클라우드 네이티브 플랫폼(Cloud Native Platform)이라는 제품을 공동으로 관리한다. 캐노니컬 쿠버네티스 배포판을 랜처의 콘테이너 관리 플랫폼과 결합시킨 제품이다. 쿠버네티스를 이용해 각 클러스터에서 실행되는 콘테이너를 관리하고 랜처를 이용해 여러 개의 쿠버네티스 클러스터를 관리하려는 것이다. 클라우드 네이티브 플랫폼은 랜처 2.0 과 함께 사용 가능하게 될 예정이다. 랜처 2.0은 현재 베타 릴리즈 형태로 이용할 수 있다.

도커 커뮤니티 에디션/도커 엔터프라이즈
많은 이들에게는 도커야말로 콘테이너다. 2014년 이래 도커는 자체 클러스터링 및 오케스트레이션 시스템인 도커 스웜(Docker Swarm)을 보유해 왔다. 최근까지만 해도 쿠버네티스의 대항마였다. 그런데 2017년 10월, 도커가 쿠버네티스를 추가하겠다고 발표했다. 즉, 수정하지 않은 바닐라(vanilla) 상태로 표준 팩인(pack-in)으로 도커 커뮤니티 에디션(Docker Community Edition)과 도커 엔터프라이즈(Docker Enterprise) 모두에 추가하겠다는 것이다.

간단히 말해 도커 사는 콘테이너 오케스트레이션의 불길한 징조를 파악했고 대규모의 복잡한 콘테이너 환경을 관리함에 있어 스웜보다 쿠버네티스가 더 적합하다는 것을 인정한 것이다. 그러나 도커에는 여전히 “스웜 모드”가 포함되어 있다. 보다 평범한 클러스터링 작업을 위한 것이다. 예를 들면, 크기가 많이 늘어날 가능성이 없는 방화벽 뒤의 로컬 애플리케이션이다.

헵티오 쿠버네티스 서브스크립션
쿠버네티스를 만든 크레이그 맥루키(Craig McLuckie)와 조 베다(Joe Beda)는 쿠버네티스를 중심으로 한 서비스와 제품을 제공하기 위해 헵티오(Heptio)를 창립했다. 이들의 첫 주요 작품이 헵티오 쿠버네티스 서브스크립션(Heptio Kubernetes Subscription)(HKS)이다. 이는 헵티오의 유료 지원이 24시간 제공되는 쿠버네티스 배치판으로, 가격은 월 2,000달러에서 시작한다.

헵티오는 업체에 구속되지 않는 엔터프라이즈급 쿠버네티스라는 것이 주요 장점이다. 배치판은 퍼블릭 클라우드나 개인 하드웨어에서 실행 가능하다. 쿠버네티스 구성 관리용으로 헵티오에서 제공하는 모든 도구는 오픈소스이며 해결책은 지원되는 클러스터로 직접 전달된다.

메소피어 DC/OS
메소피어(Mesosphere) DC/OS는 아파치 메소(Apache Meso)를 이용해 기계 클러스터를 단일 자원으로 바꾼다. 이는 동적으로 분할되어 복수의 애플리케이션에 사용 가능하다. DC/OS 상의 많은 애플리케이션 패키지 중 하나로 쿠버네티스가 지원된다. 따라서 DC/OS 클러스터에 걸쳐 쿠버네티스를 설치, 실행, 업데이트 할 수 있다.

DC/OS가 쿠버네티스 배포판인지 여부는 논란의 소지가 있다. 쿠버네티스가 DC/OS의 일부는 아니지만 다른 지원되는 애플리케이션과 같이 DC/OS를 통해 배치될 수 있기 때문이다. 리눅스 애플리케이션이 리눅스 배포판의 패키지 관리 시스템을 통해 사용 가능하게 되는 것과 비슷하다.

그럼에도 불구하고, 메소피어의 쿠버네티스에 대한 접근법은 쿠버네티스의 작동 방식을 밀접하게 따른다. 즉, 쿠버네티스의 주류 커뮤니티 배포판을 활용함으로써 기존 도구들과의 고도의 호환성을 보장한다.

미란티스 클라우드 플랫폼
미란티스(Mirantis) 클라우드 플랫폼은 오픈스택, 쿠버네티스 또는 이 둘을 합친 것을 “애자일 인프라 플랫폼”(미란티스의 표현)용 기판(substrate)으로 통합시킨다. 간단히 말하면, 미란티스 클라우드 플랫폼은 VM, 콘테이너, 베어 메탈 서버의 오케이스트레이션을 위한 단일 통합 솔루션이다.

플랫폼에 배치되는 애플리케이션은 ‘데브옵스 스타일’로 수명주기에 걸쳐 관리된다. 이때 구성 관리 도구로 솔트(Salt)를 사용하고 애플리케이션이 정확하게 배치될 수 있도록 통합 CI/CD 지원이 제공된다.

미란티스 클라우드 플랫폼은 베어메탈 상에서, 오픈스택 클러스터에서, 또는 퍼블릭 클라우드 상에서 직접 쿠버네티스를 실행할 수 있다. 미란티스의 주장에 따르면, 미란티스 클라우드 플랫폼은 쿠버네티스와 작업을 쉽게 만들어 준다고 한다. 왜냐하면 쿠버네티스 밑의 인프라 프로비저닝 작업은 최종 사용자 몫이 아니기 때문이다.

플랫폼9 매니지드 쿠버네티스
대부분의 쿠버네티스 배포판은 쿠버네티스를 안팎으로 그리고 위아래로 관리 가능하게 만드는 것에 초점을 맞추고 있다. 플랫폼9 매니지드 쿠버네티스는 다양한 환경(로컬 베어메탈, 원격 퍼블릭 클라우드 등)에서도 실행되지만 플랫폼9의 엔지니어들에 의해 서비스 형태로 원격 관리된다.

플랫폼9는 매니지드 쿠버네티스에 대한 업데이트를 약 6주에 한번씩 고객 감시 하에 내보낸다. 보통은 쿠버네티스 클러스터에 수동으로 추가해야 하는 함수들(예: 멀티 테넌시(multi-tenancy) 시나리오를 위한 사용자 할당량)이 플랫폼9에 의해 제공된다. 플랫폼9의 피션(Fission) 프로젝트와의 통합도 포함되어 있다. 이 프로젝트는 서버리스 컴퓨트(severless compute) 또는 서비스로서의 함수(FaaS) 시스템이라고도 하는데 거의 대부분의 프로그래밍 언어와 콘테이너화된 런타임으로 작동한다.

랜처 2.0
랜처 랩스는 쿠버네티스를 콘테이너 관리 플랫폼 내부로 통합시켰다. 이 플랫폼은 간단히 랜처라고 한다. 버전 2.0은 현재 베타 상태이다.

랜처 2.0은 다른 쿠버네티스 배포판에 비해 높은 수준에서 작동한다. 리눅스 호스트, 도커 콘테이너, 쿠버네티스 노드 위에 자리잡고 위치나 인프라와 관계 없이 이들을 모두 가까운 거리에서 관리한다. 심지어는 아마존 EKS, 구글 쿠버네티스 엔진, 애저 콘테이너 서비스, 기타 서비스로서의 쿠버네티스 클라우드에서 쿠버네티스 클러스터를 관리할 수 있다.

랜처에는 자체 쿠버네티스 배포판도 포함되어 있다. 랜처는 쿠버네티스 클러스터를 설치하고 쿠버네티스를 특정 환경에 맞게 맞추는 과정에서 힘든 일을 많이 없애면서도 그러한 맞춤 과정이 쿠버네티스로의 원활한 업그레이드에 방해되지 않도록 설계됐다. 빠르게 움직이고 끊임없이 업데이트 되는 프로젝트에서는 중요하게 고려되는 사안이다.

레드햇 오픈시프트
레드햇 오픈시프트(Red Hat OpenShift)는 레드햇의 PaaS 제품이다. 원래는 애플리케이션을 패키지 하기 위해 헤로쿠(Heroku) 빌드팩(buildpack)같은 “카트리지(cartridge)”를 사용했다. 패키징 된 애플리케이션은 “기어(gear)”라고 하는 콘테이너에 배치됐다.

그러다 도커가 등장했고, 오픈시프트는 새로운 콘테이너 이미지와 런타임 표준을 활용하기 위해 재작업을 거쳤다. 어쩔 수 없이 레드햇도 쿠버네티스를 오픈시프트 내 오케스트레이션 기술로 채택했다.

오픈시프트는 PaaS의 모든 요소에 추상화와 자동화를 제공하기 위해 개발됐다. 이 추상화와 자동화는 쿠버네티스에도 확장된다. 쿠버네티스는 여전히 관리 부담이 꽤 크다. 따라서 오픈시프트는 PaaS 배치라는 더 큰 임무의 일환으로 그러한 부담을 덜어주기 위해 사용될 수 있다.

스택큐브
콘테이너 실행을 위한 Hyper.sh 클라우드 서비스를 제공하는 업체인 하이퍼HQ(HyperHQ)는 “쿠버네티스 중심 오픈스택(OpenStack) 배포판”인 스택큐브(Stackube)를 개발했다. 보통 오픈스택은 컴퓨트 노드의 프로비저닝 및 관리를 위해 노바(Nova)라는 구성요소를 사용하지만 스택큐브는 그 대신 쿠버네티스를 사용한다. 그러나 그 외에는 “바닐라” 오픈스택과 쿠버네티스를 사용하고 오픈스택 플러그인에 의해 처리되는 모든 상세한 추가 내용이 포함된다.

하이퍼HQ에서 주장하는 스택큐브의 큰 장점은 어떤 콘테이너 런타임이 사용되느냐에 따라 다양한 정도의 멀티테넌시를 제공할 수 있다는 것이다. ‘소프트’한 멀티테넌시를 위해서라면 도커가 있다. 보다 강력한 자원의 분리를 위해서라면 하이퍼바이저(hypervisor)급 분리를 사용하는 하이퍼콘테이너(HyperContainer)가 있다.

서비스 플랫폼으로서의 수세 클라우드
유럽에서 널리 인기를 얻고 있는 리눅스 배포판으로 가장 잘 알려진 수세(SUSE) 역시 SUSE CaaS 플랫폼을 제공한다. 개념적으로는 코어OS 텍토닉을 연상시킨다. 콘테이너를 실행하는 베어메탈 “마이크로” OS, 콘테이너 오케스트레이션 시스템으로서의 쿠버네티스, 내장 이미지 레지스트리, 클러스터 구성 도구를 한 묶음으로 합쳐 놓은 것이다.

수세 CaaS 플랫폼은 로컬 베어메탈은 물론 퍼블릭 클라우드 상에서 실행 가능하다. 단, 수세에게는 “현재 근간이 되는 클라우드 인프라로의 통합을 전혀 지원하지 않는다”라는 원칙이 있다. 즉, 수세 CaaS 플랫폼은 아마존 EKS나 구글 쿠버네티스 엔진을 보완하는 것이 아닌 피해가기 위해 설계됐다. 따라서 복수의 클라우드와 데이터센터에 걸쳐 콘테이너를 실행하는 것이 가능하다.

텔레큐브
텔레포트(Teleport) SSH 서버를 만든 그래비테이셔널(Gravitational)은 텔레큐브(Telekube)도 만든다. 로컬 또는 원격 클러스터 상에서 실행되는 “생산 강화된(production hardened)” 쿠버네티스 배포판이다. 텔레큐브는 사설 SaaS 플랫폼을 위한 솔루션 역할을 하거나 쿠버네티스를 여러 지역 또는 호스팅 제공업체를 통해 서비스로 실행하기 위한 솔루션으로 고안됐다.

텔레큐브 상의 애플리케이션들은 쿠버네티스 상의 콘테이너에서 실행될 준비가 되어 있어야 한다. 이들은 또한 “번들”로 패키지화한 후 쿠버네티스 클러스터로 게시하여 배포되어야 한다. 번들화 하려면 콘테이너 기반 애플리케이션 배치에 필요한 다른 모든 준비 이외에도 추가 작업이 필요하지만, 번들 목록 이외에는 텔레큐브 관련 추가 내용 중에서 관리해야 할 것이 없다. ciokr@idg.co.kr 

X