OpenStack과 Container의 만남 - 2편

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

1편의 내용에 이어서 진행합니다.

3.7.1 Raw Resources

Raw-Resources-1 슬라이드 하단에 위치한 네모는 서버를 나타냅니다. 여러분은 VM 이나 Baremetal 만을 제공하고 다른 사람이 kubernetes를 설치하여 컨테이너화된 어플리케이션을 운영하는 시나리오 입니다.

Raw-Resources-2 다른 사람에게 VM을 제공하는 시나리오에서는 Nova, Cinder, Neutron, Glance, Keystone을 사용하게 됩니다.

Raw-Resources-3 만약 Baremetal을 다른 사람에게 제공하는 시나리오의 경우 Ironic을 추가로 사용하게 됩니다.

위에 살펴본 경우는 가장 단순한 형태의 서비스 입니다. 기본적인 인프라만 제공을 하고 Orchestration Engine의 설치 및 운영은 남에게 맡기는 것이죠.

3.7.2 COEaaS

COEaaS-1 COEaaS는 Container-Orchestration-Engine-as-a-Service의 줄임말 입니다. 우리 자신에게 Kubernetes를 배포할 필요 없이 Kubernetes를 다른 사람에게 직접적으로 제공하고 싶을 수 있습니다.

COEaaS-2 이러한 시나리오 에서는 Raw Resources에서 사용했던 구성에 Magnum과 Heat를 추가로 사용합니다. orchestration을 위한 Heat와 orchestration engine을 as-a-service 형태로 제공할 수 있게 해 주는 Magnum을 사용하게 됩니다.

3.7.3 Run This Container

Run-This-Container-1 "왜 Kubernetes 같은걸 사용하나요? 저는 단순히 container만 실행시키고 싶은데요? 나는 Docker Hub에 있는 이미지를 사용해서 container를 실행시키고 싶은게 다입니다."

Run-This-Container-2 이런 시나리오를 위해 "Zun" 이라는 프로젝트가 존재합니다. Nova와 Ironic을 사용해서 baremetal 서버를 provision 하고, 그 위에 컨테이너를 실행시킵니다. 컨테이너의 사용이 끝나면 kill해 버리면 됩니다. 정말 단순히 Zun은 baremetal 위에서 컨테이너를 실행시키는 역할을 담당합니다.

3.7.4 Shared Networking and Storage

Shared-Networking-and-Storage

앞서 언급한 프로젝트들은 모두 공유된 네트워크와 스토리지를 사용합니다. Kuryr bridges의 경우 VM이 이미 Neutron에 의해 제공받고 있는 동일한 network를 container에게도 제공합니다.
(글쓴이: Kuryr project의 경우 기회가 되면 관련 발표영상을 정리해서 올려보겠습니다! 아주 좋은 의도를 가진 project인것 처럼 느껴졌거든요)

이제는 Kubernetes에서 native 하게 cinder volume을 지원합니다. Kubernetes pods에도 cinder를 통해 block storage를 mount 할 수 있습니다.

3.7.5 Stackube

Stackube-1 만약 단순히 Kubernetes를 배포하고 싶지만, network가 필요하고, identity management가 필요하고, block storage가 필요하다면 이미 OpenStack 커뮤니티가 개발한 드라이버 및 plug-in을 활용할 수 있습니다.

Kubernetes의 동작을 방해하지 않으면서 OpenStack의 project의 기능을 사용할 수 있을까요? Stackube라는 프로젝트가 시작되었고 OpenStack Project에 포함되기 위해 작업중에 있습니다.이것은 Kubernetes와 OpenStack project 사이의 중간층 역할을 하는 plug-in을 제공하는 것입니다. 그 외에 Kubernetes에게 multi-tenancy를 제공하는 기능도 구현하려고 합니다.

3.8 Inception 인셉션

Inception-1 우리는 지금까지 OpenStack 위에서 container를 동작시키는 것에 대해서 이야기를 했습니다. 이러한 기술들은 앞으로 많은것들을 변화 시킬겁니다. 한 가지 더 짚어 볼 것은, OpenStack을 Kubernetes위에서 동작시킬수 있다고 이야기 하는 사람들의 말입니다.

Inception-2 OpenStack은 아주 복잡한 어플리케이션 입니다. Scale-out micro-services로 구성되어 있으며, 동작하는 구성요소가 많고 업그레이드가 힘듭니다. 업그레이드를 위해서 서비스를 중단 할 수는 없으니까요.
OpenStack 어플리케이션의 배포를 위한 하위 어플리케이션이 이러한 복잡하고 힘든 업그레이드를 담당하는것은 새로운 문제는 아닙니다.

우리는 이미 TripleO 프로젝트를 통해서 undercloud Openstack를 만들어 사용자가 사용할 수 있는 Overcloud OpenStack을 배포하는 시도를 했습니다.

Inception-3

여기서 container를 잠깐 되짚어 봅시다. container의 특징을 보면 OpenStack을 배포하는데 아주 좋은 기술처럼 보입니다. 우리는 container를 package 포멧으로 사용할 수 있을겁니다.

Inception-4 OpenStack-Ansible 이라는 프로젝트는 OS와 같은 "fat" container에 Ansible을 사용하여 openstack을 배포하는 방법을 개발하고 있습니다.

오리지널 Kolla 프로젝트는 Docker container 기술과 Ansible을 사용하여 OpenStack을 배포하는 방법을 모색하고 있습니다.

Inception-5 Kubernetes를 다시 짚어보면, 컨테이너화 된 어플리케이션을 배포하는 플랫폼이자 Google의 운영 노하우가 녹아들어가 있습니다. lifecycle과 scaling 까지 관리해 주지요.

이것은 OpenStack의 배포, 관리, 업그레이드를 단순화 하는데에 유용할 것 같아 보입니다.

Inception-5

Kolla-Kubernetes는 Kolla 프로젝트에서 파생되어 나온 프로젝트로 Kubernetes 위에 Docker container 사용하여 OpenStack을 배포하는 프레임워크의 가능성을 탐색해보고 있습니다.

OpenStack Helm
Helm Charts와 Helm Client를 사용하여 Kubernetes위에 OpenStack을 배포하는 방법을 연구하고 있습니다. 이것은 OpenStack을 Kubernetes 위에 배포한다는 동일한 목적을 가지고 있지만, 다른 접근 방식을 취하는 것입니다.

3.9 요약

Summary

3.9.1 containers

유용한 도구가 같이 제공되는 packaging 포멧입니다. 어플리케이션 개발자의 필요를 충족시킵니다.

3.9.2 Kubernetes

좋은 방식들이 녹아들어 있는 어플리케이션 배포 시스템 입니다. 어플리케이션 운영자들의 필요를 충족시킵니다.

3.9.3 OpenStack

오픈 인프라 프레임워크이며 인프라 제공자의 다양한 필요를 충족시킵니다.

3.9.4 Containers on OpenStack

OpenStack이 제공하는 인프라 위에서 container를 동작시키면서 네트워크, 스토리지, 컴퓨트 리소스를 공유합니다.

3.9.5 Kubernetes on OpenStack

OpenStack 위에서 Kubernetes clusters를 배포하고 Kubernetes pods와 인프라를 공유합니다.

3.9.6 OpenStack on Containers and Kubernetes

OpenStack 운영자는 container와 Kubernetes 기술을 활용하여 OpenStack의 배포와 관리를 용이하게 할 수 있습니다.