리뷰 : 레드햇 아토믹 호스트 “도커를 해결하는 수준 높지만 어려운 방법”

클러스터 전체의 컨테이너를 관리하기 위해 쿠버네티스를 사용하는 것이 한 대의 호스트 상에서 도커를 실행하는 것보다 훨씬 더 복잡하기는 하지만, 훨씬 더 큰 복잡성에 따른 훨씬 더 큰 신뢰성과 기능이 있다. 쿠버네티스를 사용하면 이 시스템이 대규모 실제 업무 환경에서 (구글에서) 실제로 시험되었다는 사실에 따른 안도감도 얻을 수 있다.

쿠버네티스 마스터(master)를 설정하기 위한 쉬운 방법은 존재하지 않는다. 문서는 여러 프로젝트 웹사이트에 산재되어 있고, 많은 경우 문서들은 세부사항을 다른 사이트로 넘기고 있기 때문에, 문서를 읽고, 추적하며, 실험하는 데 많은 시간을 소비할 각오를 해야한다. 노력의 대부분은 몇 개의 /etc 디렉토리에 흩어져있는 열두어 가지 정도의 파일을 수정하는 것이다. 물론 요령은 그런 수정사항들이 뭔지를 파악하는 것이다. 쿠버네티스는 컨테이너를 사용한 간단한 실험용으로 만들어진 것이 결코 아니다. 쿠버네티스는 진지한 실제 업무용이다.

쿠버네티스, 인증서, 서비스, 그리고 플란넬 오버레이 네트워크로 마스터를 구성한 다음, flannneld, kubelet, 그리고 Etcd를 설치한 다음에야 비로소 다섯 개의 노드로 구성된 컨테이너 클러스터를 실행할 수 있었다. 불행하게도, 이 작업은 많은 양의 메모리를 사용해서 필자는 랜처OS나 VM웨어 포톤에서 시험했던 것처럼, 단일 노드를 사용해서 시험할 수 있는 방법을 찾아내지 못했다.

이 시점에서, 서비스와 애플리케이션을 캡슐화하는 컨테이너 그룹인 팟을 실행시키고 관리하는데 쿠버네티스를 사용할 수 있다.

아토믹 호스트 스토리지와 네트워킹
대부분 컨테이너 호스트 운영체제와 마찬가지로, 아토믹 호스트는 호스트를 실행하기에 충분한 디스크 공간만이 포함된, 최소한의 접근방식을 취하고 있다. 이는 일반적인 클러스터가 실행되는 여러 개의 도커를 수용하기에는 충분하지 않은 공간만 남기게 되어서, 이 용도로 호스트에 외장 스토리지를 부착할 필요가 있다.

도커에서 이미지와 관련 파일들은 대개 /var/lib/docker에 저장되고, 대부분의 표준 운영체제에서는 스토리지를 추가하기 위해 이 시점에서 하나의 기기를 파일시스템에 그냥 마운트할 것이다. 그렇지만, 아토믹은 도커 이미지와 메타파일을 저장하기 위해 디바이스 매퍼(Device Mapper) 백엔드를 통해서 Direct LVM(Linux Volume Manager) 볼륨을 사용한다. 즉 /dev/atomicos/docker-data와 /dev/atomicos/docker-meta를 사용하는데, 이는 아토믹 호스트에 공간을 추가하기 위해서 LVM과 볼륨에 대해 조금은 공부할 필요가 있다는 의미이다.

아토믹에서 스토리지 관리의 출발점은 설정 스크립트 /etc/sysconfig/docker-storage-setup이다. 아토믹 호스트는 도커 스토리지용으로 스토리지 풀을 가지고 있어서, 여기서의 요령은 새로운 기기를 이 풀에 추가하는 것이다. 다음과 같이 파일에 기기 목록을 추가하면 된다:

DEVS="/dev/vdb /dev/vdc"

그 다음에는 헬퍼 스크립트 /usr/bin/docker-storage-setup를 실행한다. 모든 것이 제대로 진행되면, 디스크가 풀에 추가되고, 아토믹 호스트는 도커용 공간을 확보하게 된다. 실제 업무에서는 LVM이 기존 관리 도구를 사용하거나 앤서블/솔트/셰프/퍼펫(Ansible/Salt/Chef/Puppet) 스크립트 같은 것으로 관리될 것이기 때문에, 대형 데이터센터 환경에서 작업하고 있는 관리자들에게는 더 일반적으로 보일 것이라 생각한다.

프로젝트 아토믹은 Etcd를 통해서 컨테이너 오버레이 네트워크를 제공하기 위해 플란넬을 사용한다. 컬(Curl) 같은 도구를 사용해서, JSON 구성 파일을 Etcd 키-값 저장소에 넣음으로써 이 작업을 구성한다. 컨테이너에 대한 서브넷을 구성하기 위해, 다음과 같은 JSON 파일을 생성할 수 있다:

{
“Network”: “172.16.0.0/12”,
“SubnetLen”: 24,
“Backend”: {
“Type”: “vxlan”
}
}

그리고 이 파일을 Etcd 마스터에 넣기 위해, 이것을 네트워크 구성 키에 넣는다:

curl -L http://localhost:2379/v2/keys/atomic.io/config -XPUT --data-urlencode value@flanneld-conf.json

다소 성가시기는 하지만, 할 수는 있다. 이런 구성 명령어들을 atomic ifconfig…, atomic route…, 등 같이 유닉스 관리자에게 좀 더 직관적으로 만들어주는 래퍼(Wrapper)가 있었으면 한다.

여기에 강조할 가치가 있는 또 다른 차이점이 있다. 팟과 서비스에 대한 쿠버네티스의 개념이 그것이다. 팟은 비교적 강하게 결합된(tightly coupled: 강결합) 컨테이너 그룹이다. 팟에 있는 모든 컨테이너는 동일한 호스트와 동일한 IP 주소를 공유하며, 동시에 생성되고 소멸한다. 사용자가 실행하고 싶은 팟의 인스턴스 개수를 지정하면, 쿠버네티스가 명령을 수행한다. 어떤 인스턴스가 중지되거나 장애를 일으키면, 원했던 상태에 일치시키기 위해 쿠버네티스가 또 다른 인스턴스를 스핀업(Spin Up)시킨다.

쿠버네티스 서비스는 논리적인 팟 세트와 팟에 액세스하는 정책을 정의하는 추상화 계층이다. 이는 (마이크로) 서비스에 팟 라이프사이클에 걸쳐 하나의 안정적인 이름과 주소를 제공한다. 더 많은 것들이 있지만, 이 정도만으로도 네트워크를 관리하기 위해 별도의 구성요소가 필요한 이유를 이해하는 데는 도움이 될 것이다. 아토믹 호스트에서는 이 구성요소가 바로 플란넬이다.

아토믹 호스트 업그레이드와 다운그레이드
아토빅 호스트는 RPM-OS트리라는 패키지 관리자를 사용하는데, 전통적인 RPM과 OS트리의 기능을 결합한 것이다. RPM-OS트리는 프로세스가 (데이터베이스에서 사용되는 단어로) “최소단위 작업(atomic)”이기 때문에, 안정적으로 작업 수행(Roll Forward) 그리고 작업 취소(Roll Backward)를 할 수 있는 역량을 제공한다. RPM-OS트리는 업데이트에 대해 안정적인 트랜잭션을 제공한다 즉, 운영하고 있는 시스템을 망가뜨릴 가능성이 없다는 의미이다. 컨테이너들에 대한 명령어들처럼, 호스트 업그레이드와 롤백은 아토믹 관리 시스템을 의미하는 atomic이란 명령어가 앞에 붙는다:

atomic host upgrade
atomic host rollback

필자는 롤백할 것이 아무것도 없어서, 롤백은 시험하지 않았음에 유의하라.

레드햇 아토믹 호스트는 레드햇 기술과 인프라에 많은 투자를 한 조직에 가장 적합하다. 다른 각도에서 시작하는 기업이라면 다른 옵션을 고려해 볼 수도 있다. 쿠버네티스가 포함되어 있고, 대규모 프로덕션 환경에서 레드햇의 이력이 갖는 영향력 때문에 아토믹 호스트는 엔터프라이즈에서 컨테이너화된 워크로드를 실행하기 위한 “낙하산 솔루션”이 될 것이 거의 확실하다. 그렇지만, 필자는 개발자들이 아토믹 호스트를 자신들이 선택한 도커 플랫폼으로 여길 거라고는 보지 않는다.  editor@itworld.co.kr