본문 바로가기

Home > 열린마당 > 공개SW 소식

공개SW 소식

2017년 7월 15일 (토)

ⓒ CIO Korea, Serdar Yegulalp | InfoWorld



어떤 혁신이든 '새로운 문제(복잡성)'가 수반된다. 컨테이너는 애플리케이션을 편리한 이동형 폼 팩터에 넣어 실행할 수 있도록 해준다. 그러나 대규모로 컨테이너를 관리하기란 절대 쉬운 일이 아니다.

Credit:GettyImages


구글 내부의 문제를 해결하면서 나온 산물인 쿠베르네티스는 전체 클러스터의 컨테이너 운영 방식을 관리하는 단일 프레임워크를 제공하는 것이 특징이다. 제공하는 서비스를 축약해 표현하면, 일명 '오케스트레이션(Orchestration)'이다. 그러나 컨테이너 스케줄링, 컨테이너 간 서비스 발견, 시스템의 로드 밸런싱, 롤링 업데이트/롤백, 높은 가용성 등 여러 기능과 특징을 포함하고 있다.

이 기사에서는 쿠베르네티스를 설치하고, 컨테이너 기반 애플리케이션과 함께 배포하는 방법의 기초 사항을 소개한다. 쿠베르네티스 개념만 설명할 의도는 없다. 쿠베르네티스를 운영하는 간단한 사례와 함께 적용되는 개념을 소개한다.

쿠베르네티스 호스트 선택
쿠베르네티스는 리눅스 컨테이너를 관리하기 위해 개발됐다. 그러나 쿠베르네티스 1.5부터 쿠베르네티스 제어 영역에서 계속 리눅스를 실행하기는 해야 하지만, 윈도우 서버 컨테이너를 지원하고 있다. 물론 가상화를 이용하면 어느 플랫폼이나 쿠베르네티스를 시작할 수 있다.

하드웨어나 VM에서 쿠베르네티스를 실행하는 가장 흔한 방법의 하나는 쿠베르네티스를 '번들'로 제공하는 리눅스 배포판을 구하는 것이다. 이렇게 하면 다운로드 받아 설치할 수 있다. 이때 특정 배포판에 맞게 쿠베르네티스를 설정할 필요는 없다. 그렇지만 이 경우에도 구성과 관리 프로세스가 일부 존재한다.

대표적인 관리 프로세스로는 코어OS 테크토닉(CoreOS Tectonic)이 있다. 코어 OS 테크토닉은 컨테이너와 쿠베르네티스에 초점이 맞춰져 있어 다운로드, 설치, 설정 등이 필요 없다. 랜처OS(RancherOS)도 마찬가지다. 위와 유사하게 대부분 '설정'이 자동으로 돼 있다. 둘 다 베어 메탈, 아마존 AWS VM, 구글 컴퓨터 엔진, 오픈 스택 등 다양한 환경에 설치할 수 있다.

또 다른 방법은 기존 리눅스 배포판에서 쿠베르네티스를 실행하는 것이다. 이 방법에는 통상 수동으로 처리할 부분이 더 많다. 예를 들어, 레드햇 엔터프라이즈 리눅스(Red Hat Enterprise Linux)의 패키지 저장소에도 쿠베르네티스가 있다. 레드햇은 테스트 목적으로 이용하라고 권장한다. 직접 통합을 시도하는 대신, 오픈시프트(OpenShift) PaaS를 통해 쿠베르네티스를 이용하라고 권장한다. 오픈시프트가 기본 오케스트레이터로 쿠베르네티스를 사용하고 있기 때문이다.

기존의 많은 리눅스 배포판들이 쿠베르네티스와 다른 대형 소프트웨어 스택을 설정할 수 있는 전용 도구를 제공하고 있다. 우분투의 경우 '컨저-업(Conjure-up)'이라는 도구를 제공한다. 쿠베르네티스 업스트림 버전을 클라우드와 베어 메탈 인스턴스에 배포할 때 사용할 수 있는 도구다.

쿠베르네티스 클라우드 선택
구글 클라우드 플랫폼(GCP)의 기본 기능으로 인식되고 있지만, 사실 많은 클라우드가 쿠베르네티스를 '표준 품목'으로 지원하고 있다. GCP는 두 가지 방법으로 쿠베르네티스를 실행할 수 있다. 가장 간편하게 통합할 수 있는 방법은 구글 컨테이너 엔진(Google Container Engine)을 이용하는 것이다. 쿠베르네티스의 명령어 도구를 이용해 생성한 클러스터를 관리할 수 있다.

또 컴퓨터 클러스터를 설정하고, 쿠베르네티스를 수동으로 적용하기 위해 구글 컴퓨트 엔진을 사용할 수도 있다. 이 방법은 더 많은 노력이 필요하지만, 컨테이너 엔진으로는 불가능한 맞춤화를 처리할 수 있다 컨테이너만 시작하려면 컨테이너 엔진을 사용하는 것이 좋다. 익숙해져서 고도화된 방식으로 사용하고 싶을 때(예, 자신이 수정한 맞춤 쿠베르네티스 버전), 쿠베르네티스 배포판이 실행되는 VM을 배포할 수 있다.

아마존 EC2는 컨테이너를 기본 지원한다. 그러나 쿠베르네티스를 컨테이너 오케스트레이션 시스템으로 기본 지원하지는 않는다. AWS의 쿠베르네티스 실행은 구글 컴퓨트 엔진과 유사하다. 컴퓨터 클러스터를 구성한 후, 수동으로 쿠베르네티스를 적용한다.

AWS 설정에 대한 상세한 설명서가 있는 쿠베르네티스 배포판이 많다. 예를 들어, 코어OS 테크토닉에는 그래픽 설치 도구가 포함되어 있지만, 또한 지원한다. 테라폼(Terraform) 인프라 프로비저닝 도구를 대안으로 쿠베르네티스 콥스(Kps) 도구를 사용, AWS에 제네릭 VM 클러스터를 프로비저닝 할 수도 있다(통상 데비안 리눅스를 사용하지만, 다른 리눅스 배포판도 부분적으로 지원).

마이크로소프트 애저(Microsoft Azure)는 애저 컨테이너 서비스(Azure Container Service)를 통해 쿠베르네티스를 지원했다. 그러나 쿠베르네티스가 애저에 호스팅 된 서비스라는 점에서 '기본(네이티브)' 지원은 아니다. 애저 리소스 매니저(Azure Resource Manager) 탬플릿을 이용해 쿠베르네티스를 배포한다. 애저는 도커 스웜(Docker Swarm)과 메소스피어(Mesosphere) DC/OS 같은 다른 컨테이너 오케스트레이션 프레임워크도 같은 방식으로 지원한다. 여기에서 설명한 다른 클라우드도 마찬가지이지만, 완전한 통제를 원한다면 애저 가상 머신에 쿠베르네티스에 초점이 맞춰진 배포판을 설치하면 된다.

클라우드 등 다양한 환경에 단순한 쿠베르네티스 클러스터를 빨리 프로비저닝 하는 방법의 하나는 쿠베르네티스 애니웨어(Kubernetes Anywhere)라는 프로젝트를 사용하는 것이다. 이 스크립트는 구글 컴퓨트 엔진, 마이크로소프트 애저, VM웨어 vSphere(vCenter가 필요)를 지원한다. 설정이 어느 정도 자동화됐다는 것이 공통점이다.

자신만의 작은 쿠베르네티스 노드
(전체 쿠베르네티스 환경 구현 없이)개발용 시스템 등 로컬 환경에서만 쿠베르네티스를 운영하고 싶을 수도 있다. 이런 용도의 '설정'을 위한 몇 가지 방법들이 있다.

그중 한 가지는 쿠베르네티스 개발팀이 직접 제공하는 미니쿠베(Minikube)이다. 이를 실행하면 선택한 가상화 호스트에 싱글 노드 쿠베르네티스 클러스터가 배포될 것이다. 미니쿠베에는 '전제 조건'이 몇 가지 있다. Kubectl 명령어 인터페이스와 버츄얼박스(VirtualBox) 같은 가상화 환경이 여기에 해당된다. 그러나 모두 맥OS, 리눅스, 윈도우용 바이너리로 즉시 입수해 사용할 수 있다.

맥OS의 코어OS 사용자들은 코어OS VM에 기반을 두고 있고, 빠른 관리에 도움을 주는 Status Bar 앱을 제공하는 쿠베르네티스 솔로(Kubernetes Solo)를 사용할 수 있다. 솔로에는 쿠베르네티스용으로 패키징 된 애플리케이션을 쉽게 설정할 수 있는 쿠베르네티스 패키지 관리 도구인 헴(Helm, 아래 상세 설명)도 포함되어 있다.

컨테이너 클러스터 확대
쿠베르네티스를 실행시킨 후, 컨테이너 배포 및 관리를 시작할 수 있다. 많은 컨테이너 기반 앱 데모를 이용, 쉽게 컨테이너를 운영할 수 있다.

기존 컨테이너 기반 앱 데모를 가져와, 유용한 상태가 될 때까지 구성 및 배포, 수정 방법을 확인 및 테스트한다. 미니쿠베를 이용하기로 했다면. 헬로우 미니쿠베(Hello Minikube) 튜토리얼을 사용해, 싱글 노드 쿠베르네티스 데모에 단순한 Node.js 앱이 포함된 도커 컨테이너를 생성할 수 있다. 그리고 개념과 방법을 파악한 후, 자신의 컨테이너로 교체한 후, 배포를 연습할 수 있다.

다음 단계는 '생산화 단계'에 사용하는 것과 유사한 예제 애플리케이션을 배포하는 것이다. 그리고 포드(애플리케이션을 구성하는 하나 이상의 컨테이너), 서비스(포드 논리 세트), 복제 세트(머신에 문제가 있을 때 스스로 해결하는 기능을 제공), 배포(애플리케이션 버전 처리) 같은 고급 쿠베르네티스 개념을 학습한다. 워드프레스/마이MySQL(WordPress/MySQL) 샘플 애플리케이션을 예로 들면, 이를 쿠베르네티스에 적용해 실행하는 방법 이상을 확인할 수 있다. 또 생산화 단계 쿠베르네티스 애플리케이션에서 사용하는 많은 개념의 구현과 관련된 세부 사항을 확인할 수 있다. 여기에 더해 애플리케이션 상태를 보존하기 위해 영구 볼륨(persistent volumes)을 설정하는 방법, 서비스를 이용해 포드를 서로, 그리고 외부에 노출하는 방법, 애플리케이션 암호와 API 키를 안전하게 저장하는 방법 등을 학습할 수 있다.

위브웍스(Weaveworks)에는 쿠베르네티스에 애플리케이션을 구성하기 위해 마이크로서비스 패턴을 사용하는 방법을 보여주는 예제 앱인 삭 숍(Sock Shop)이 있다. 삭 숍은 기반이 되는 기술들인 Node.js, Go키트, Spring Boot 등에 친숙한 사람들에게 가장 유용하다. 그러나 핵심 원칙은 특정 프레임워크에 제한되지 않고, 클라우드 네이티브 기술을 설명해 준다.

워드프레스/마이SQL 애플리케이션을 본 후, 자신의 필요 사항에 부합하는 쿠베르네티스 앱이 기본 탑재되어 있다는 생각을 가질 수도 있다. 이는 어쩌면 맞는 생각일지 모른다. 쿠베르네티스에는 쿠베르네티스 애플리케이션의 패키징, 버전, 공유를 지원하는 애플리케이션 정의 시스템인 헴(Helm)이 들어있기 때문이다. GitLab과 워드프레스 등 인기 앱과 앱 구성 요소(MySQL, Nginx) 등 다수가 Kubeapps 포털을 통해 즉시 입수할 수 있는 헴 차트를 가지고 있다.

쿠베르네티스 탐색
쿠베르네티스는 포드와 서비스 같은 강력한 추상화로 컨테이너 관리를 단순화시킨다. 또 포드와 서비스, 배포를(배포 및 스테이징, 생산 워크로드 역시 마찬가지) 분리할 때 사용할 수 있는 네임스페이스(namespaces)와 라벨 같은 메커니즘을 통해 많은 유연성을 제공한다.

위 예제 중 하나를 가져와 여러 네임스페이스에 여러 인스턴스를 설정하면, 각 네임스페이스의 구성요소를 독립적으로 변경할 수 있다. 이후 배포를 이용, 이렇게 업데이트 한 사항을 해당 네임스페이스의 여러 포드에 적용할 수 있다.

다음으로 중요한 부분은 이런 '연습'을 넘어선다. 다름 아닌, 관리용 도구로 쿠베르네티스 자체를 활용하는 방법을 학습하는 것이다. 예를 들어, 푸펫(Puppet)에는 쿠베르네티스에서 리소스를 생성 및 조정할 수 있는 모듈이 있다. 또 해시코프(HashiCorp)의 테라폼은 아직 초기 단계이지만 쿠베르네티스를 하나의 리소스로 지원하는 추세다. 이런 리소스 관리 도구를 사용할 계획이라면, 도구마다 테이블에 대한 가정이 크게 다르다는 점을 명심해야 한다. 푸펫과 테라폼의 경우 각각 변경할 수 있는 인프라, 변경할 수 없는 인프라를 사용하도록 기본 설정돼 있다. 이런 차이가 필요한 쿠베르네티스를 얼마나 쉽게 설정할 수 있는지 결정한다.



※ 본 내용은 한국IDG(주)(http://www.itworld.co.kr)의 저작권 동의에 의해 공유되고 있습니다.
Copyright ⓒITWORLD. 무단전재 및 재배포 금지


[원문출처 : http://www.ciokorea.com/news/34879]

맨 위로
맨 위로