Magnum을 소개합니다 - 1편

본 내용은 Adrian Otto가 2017년 OpenStack Boston Summit에서 발표한 내용을 요약한 것입니다. (글의 흐름을 위해 의역과 수정이 들어갔습니다.)

1. 개요

원 제목은 Magnum 101 입니다. 제목대로 Magnum 프로젝트가 무엇인지에 대해서 쉽게 잘 설명하고 있습니다. Magnum 프로젝트는 OpenStack의 설치 및 관리 보다는, OpenStack으로 관리되는 인프라를 남들에게 제공할때 좀 더 편리하게 할 수 있는 방법을 제시합니다.

2. 감상평

발표 내용중에 가장 핵심이 되는 한 마디를 꼽자면 바로 이것이 아닐까요?

처음 Magnum을 접하는 사람들은 묻습니다. Magnum과 Kubernetes의 다른점은 무엇인가요?

Container Orchestration Engine의 역할은 어플리케이션을 관리하는 것입니다. Magnum은 여러분의 인프라 클러스터를 관리하는 역할을 담당합니다.

Magnum은 여러분의 인프라에서 Kubernetes 혹은 Docker를 구동하고 싶은 사람들에게 그들이 알아서 간단하고 빠르게 만들어 쓸 수 있도록 도움을 주는 OpenStack 프로젝트 라고 요약 할 수 있겠습니다.

개인적으로 Magnum은 조금 늦게 시작한 프로젝트 일 줄 알았습니다. 하지만, 2015년 1월 부터 시작이 된걸 보면 벌써 2년 반이 지난 프로젝트네요.

3. 내용요약

3.1 Magnum은 무엇인가요?

1.What-is-Magnum

  • OpenStack API Service that allows creation of container clusters - container 클러스터를 생성할 수 있게 하는 OpenStack API 서비스.

  • Use your keystone credentials - Keystone 인증 활용.
    Openstack 클라우드와 communicate 할때 사용하는 인증방식과 동일한 인증 방식을 container에도 사용할 수 있게 해 줍니다.

  • You choose your cluster type - cluster의 종류 선택 가능 (Kubernetes, 혹은 docker swarm 등).
    하나의 기술만을 지원하는게 아니라, 여러 기술을 사용할 수 있습니다.

  • Multi-Tenancy - Multi-Tenancy를 지원.
    Control plane 부터 data plane까지 완벽하게 분리합니다.

  • Quickly create new clusters with advanced features such as multi-master - multi-master 같은 상위 기능을 사용하는 cluster를 빠르게 생성.
    Kubernetes 를 사용해 보셨다면, security configuration이나 multi-master configuration을 올바로 하기가 참으로 힘들다는 것을 경험할 수 있습니다. Magnum을 통하면, Kubernetes를 쓰고 싶어하는 사용자들이 손쉽게 cluster를 생성하여 사용할 수 있습니다.

3.2 용어 - COE

2.Terminology-COE

  • COE - Container Orchestration Engine
  • Example - Kubernetes, Docker Swarm, Apache Mesos, DC/OS

오늘 내용을 이해하기 위해 숙지해야 할 첫 단어는 COE 입니다. magnum은 다양한 종류의 COE 를 지원합니다.
(글쓴이: 발표자가 Container Orchestration Engine에 대한 자세한 설명을 하지 않았습니다. 저도 따로 하지는 않겠습니다. 네이버에서 Kubernetes나 Docker swarm에 대한 자료를 참고하세요!)

3.3 용어 - Magnum Cluster

3.Terminology-Magnum Cluster

  • Magnum Cluster는 Nova instance, Neutron networks, security groups, 그 외 resources로 구성된 API resource 이며, Heat stack을 사용하여 생성 됨
  • node를 추가하거나 제거하여 클러스터를 scale up 하거나 down 할 수 있음. Heat가 이런 설정과 scale을 실행함.
  • 이러한 Magnum cluster 안에서 여러분의 COE가 동작함.

실제로 container를 동작시키는것은 Magnum cluster안에 들어있는 COE 입니다. Magnum cluster는 container를 직접적으로 실행하지 않습니다.

슬라이드 하단에 있는 그림에는 가장 기본적인 구성요소인 Nova instance 만 포함시켰으며, 다른 리소스는 포함하지 않았습니다.

3.4 용어 - Cluster Template

4.Terminology-Cluster-Template

  • Cluster Template은 Cluster resource를 생성하기 위한 model. 이것으로 부터 만들어진 모든 cluster들에 대한 공통된 정보를 담고 있음.
  • 각각의 cluster는 cluster type을 정하는 driver를 사용함 (swarm, kubernetes, mesos 등)

Cluster template는 cluster를 찍어내는데 사용하는 도장입니다.

Cluster template안에 DNS, 네트워크 대역, Key Pair, 혹은 여러분이 runtime시 설정하는 하는 모든정보(사용자, 비밀번호 등등)를 저장할 수 있습니다. Template 안에 어느 항목을 규정해 놓으면 그에 대한 값을 템플릿 안에 포함시킬수도 있고, 생성시에 입력 할 수도 있습니다.

다시말해, cluster의 실사용자들이 cluster를 손쉽게 생성 할 수 있도록 operator들이 미리 작업을 해놓는 것입니다.

3.5 용어 - Native Client

5.Terminology-Native-Client

  • COE와 함께 배포되는 client. 예를 들면 docker 또는 kubectl 명령어
  • native client는 openstack client가 아님. TLS를 사용하여 인증

Native client란 COE가 native 하게 사용하는 도구 입니다.

OpenStack 도구를 이야기 하는것이 아닙니다. Kubernetes를 사용한다면 native client는 'kubectl' 입니다. Docker swarm을 사용한다면 native client는 'docker' 입니다.

Magnum은 사용자들이 OpenStack 도구를 사용하는것이 아니라 native client를 사용하도록 디자인 되었습니다.

3.6 Magnum이 다른점

제가 많이 받는 질문중 하나가, Magnum을 통해서 COE를 동작하는것과 그냥 물리적 서버 위에서 COE를 동작시키는 것이 어떻게 다르냐는 것입니다.

그 차이점을 4개로 요약해 보았습니다.

3.6.1 Multi-tenant

multi-tenant의 의미는, 서로가 서로에게 적대적일수 있는 workload를 동일한 resources에서 동작 시킨다는 의미입니다.

다시말해, 고객1과 고개2는 서로 관련이 없는 완전히 다른 고객이지만, 동일한 resources 위에서 동작시킬때 고객1이 고객2에게 영향을 끼치는 상황(혹은 그 반대의 상황)이 발생할 수 있습니다. 그렇기 때문에 고객 1과 고객2를 분리시키는 안전한 벽이 있어야 합니다.

Cloud resources 위에 단순히 COE를 얹어버리면, 어떠한 분리도 없이 모든 container 가 하나의 resource 상에서 동작하게 됩니다.

Magnum의 경우에는 Nova를 사용하여 클러스터를 생성 한 후, 각각의 cluster안에는 하나의 tenant만 수용합니다. 이렇게 옆 tenant와 같은 host kernel을 사용하지 않게 하여 쉽고 빠르게 multi-tenancy를 구현해 냅니다.

3.6.2 Choice of COE

Magnum이 처음 시작할때만 해도 Docker가 굉장한 관심을 받았지만, 지금은 Kubernetes가 굉장히 핫합니다. 만약 여러분이 Docker만을 사용했다가 Kuberenetes를 사용하고 싶다고 모든것을 새로 설치해야 한다면, 그건 별로 반가운 상황은 아니지요.

또한, 어떤 종류의 workload를 실행하는지에 따라서 다른 COE를 선택해야 될 떄도 있습니다. 만약 Cloud-Native workload를 실행한다면 Kubenetes를 사용하는것이 좋습니다만, legacy application을 조금 손을 봐서 cloud에서 실행한다면kubernetes에서는 큰 헤택을 못볼수도 있습니다. 그럴때는 조금 더 단순한 docker를 사용하는것이 좋을수도 있습니다.
(글쓴이: legacy application을 '조금 손본다'의 영어 원문 표현은 fork-lift your legacy application 입니다.)

Magnum 에서는 여러분이 클러스터를 생성하면서 원하는 도구를 선택을 할 수 있습니다. 만약 미래에 새로운 기술이 생겨난다고 해도 Magnum은 plugin 형태로 그 새로운 기술을 물려서 여러분의 cluster에 사용할 수 있게 해 줍니다.

3.6.3 VM이냐 Baremetal이냐

Magnum cluster는 여러분이 VM을 사용하는지 baremetal을 사용하는지 신경쓰지 않습니다. Magnum은 Nova가 지원하는 종류의 서버를 사용할 수 있습니다.

여러분은 container를 동작할때 baremetal로 구성된 클러스터 또는 VM으로 구성된 클러스터, 또는 container로 구성된 클러스터까지도 사용할 수 있습니다.(이러한 경우 우리는 container on container 라고 부르지요)

Magnum은 기본적으로 이런것들을 지원하도록 만들어졌습니다.

3.6.4 OpenStack과의 통합

Magnum은 OpenStack의 일부로 통합되어 있습니다. 만약 Keystone에 등록이 되어있는 사용자라면 Magnum cluster를 사용하기 위해서 또 등록을 할 필요가 없습니다.

(글쓴이: Magnum cluster내에 동작하는 COE가 Keystone을 사용할 수 있다는 것은 큰 장점 이라는 뉘앙스도 있는것 같습니다.)

3.7 왜 이것들이 중요한가요?

7.Why-This-Matters

  1. 선택권 - 하나의 container orchestration tool에 lock in 되는것을 막아줍니다.

  2. 빠른 속도 - 다른 도구가 제공할 수 없는 속도와 단순함으로 cluster를 생성할 수 있게 해줍니다.

  3. 신속함 - 개발자들이 수동으로 직접하는것보다 더 빠르고 단순하게 여러분의 software을 iterate할 수 있도록 합니다. (다시말해, software의 순환 싸이클을 더 빠르게 돌릴 수 있게 합니다.)

3.8 Magnum과 Kubernetes는 겹치나요?

8.Overlap

처음 Magnum을 접하는 사람들은 묻습니다. 'Magnum과 Kubernetes의 다른점은 무엇인가요?' 라고.

Container Orchestration Engine의 역할은 어플리케이션을 관리하는 것입니다. Magnum은 여러분의 인프라 클러스터를 관리하는 것입니다.

여러분이 Container Orchstration cluster을 동작시키기 위해서는 인프라의 lifecycle, scale 같은 인프라 클러스터의 요소를 먼저 관리해야 합니다. 새로운 버전의 COE가 나오면 설치를 해야만하고, 이럴때 설치는 쉬울수록 좋습니다.

3.9 클라우드 운영자

9.Cloud-Operator

클라우드 운영자는 Magnum을 통해 Cluster Template을 생성합니다. 'magnum cluster-template-create' 명령어를 통해 생성 작업을 할 수 있습니다. Cluster template에는 아래와 같은 정보를 포함시킬 수 있습니다.

  • base 이미지
  • keypair
  • 네트워크
  • DNS
  • Flavor
  • 스토리지
  • 네트워크 드라이버
  • 어떤 종류의 COE
  • 어떤 Volume Driver
  • Public 혹은 Private

3.10 클라우드 사용자

10.Cloud-User

사용자 입장에서는 cluster-create 명령어를 사용해서 cluster를 생성할 수 있습니다.

슬라이드에 보이는 명령어는 kubernetes라는 이름을 가진 template을 사용하여 cluster를 생성하는 내용입니다. master node 3개와 cluster node 8개, 총11개의 node를 생성 합니다. TLS 설정도 자동을 되고, security 구성도 자동으로 처리 됩니다.

모든 사용자는 cluster별로 자신만의 CA 인증서를 가지고 있습니다. 각각의 cluster는 원치않는 다른 cluster 사용자의 접속을 걱정할 필요가 없습니다.

이번 예제의 경우는 Kubernetes를 COE로 사용한다고 가정하였기 때문에, cluster가 생성이 되고 나면 사용자는 바로 Kubernetes 명령어를 실행할 수 있습니다.

다음 슬라이드는 docker swarm을 사용하는 경우 입니다. 11.CloudUser-Docker

magnum cluster-create를 사용하여 docker swarm을 사용하는 cluster를 생성해서 사용하면 됩니다.

4. 다음편 예고

2부에서는 Ocata에 포함된 Magnum의 새 기능과 앞으로의 개발 로드맵에 대한 내용을 보시게 될겁니다.