오픈스택 재단(OSF: OpenStack Foundation)은 현지 시각 11월 13일부터 15일까지 독일 베를린 시티큐브 베를린(Citycube Berlin)에서 ‘오픈스택 서밋 베를린(OpenStack Summit Berlin)’을 개최했다. 이번 ‘오픈스택 서밋 베를린’은 ‘오픈 인프라스트럭처(Open Infrastructure)’를 기조로, 35개 이상의 프로젝트에서 200개 이상의 세션과 워크샵들이 50여개 국에서 참석한 전문가 및 관계자들과 함께 진행되었다.
이번 ‘오픈스택 서밋 베를린’은 클라우드 뿐 아니라 엣지 컴퓨팅, CI/CD, AI, 네트워크 가상화(NFV), 컨테이너 인프라에 이르기까지 다양한 형태의 ‘오픈 인프라스트럭처’에서의 혁신 기술들과 사례들에 대해 다루며, 35개 이상의 오픈소스 프로젝트에서 200개 이상의 세션과 워크샵들이 마련되었다. 특히 이번 서밋이 열리는 독일은 오픈스택이 가장 활발하게 사용되는 지역으로도 꼽히는데, 대형 통신사나 엔터프라이즈, 퍼블릭 클라우드 서비스 사업자들이 오픈스택 기반 환경을 활발히 활용하고 있으며, 커뮤니티 규모와 활동 면에서도 활발한 모습을 보이는 지역으로 꼽힌다.
이번 서밋에서는 재단의 ‘파일럿 프로젝트’ 들에 대해 소개하는 다양한 세션이 진행되었다. ‘카타 컨테이너(Kata Containers)’ 또한 오픈스택 재단의 파일럿 프로젝트 중 하나로, 호스트 커널을 공유하는 컨테이너 환경에서 VM 수준의 격리성과 컨테이너 수준의 성능 효율을 양립하고자 하는 것을 목표로 하고 있다. 이번 서밋에서 인텔 OTC(Open Source Technology Center) 의 시니어 소프트웨어 엔지니어 Graham Whaley 가 진행한 ‘Kata Containers: An introduction and overview’ 세션은 이러한 카타 컨테이너에 대한 전반적인 소개를 위해 마련되었으며, 이 기술의 특징과 장점, 향후의 발전 방향 등을 소개했다.
▲Graham Whaley 인텔 OTC 시니어 소프트웨어 엔지니어
▲카타 컨테이너는 ‘컨테이너에 가까운 VM’의 모습을 보여 준다
카타 컨테이너(Kata Containers)는 가상 머신(VM)과 컨테이너의 사이 쯤에 있는 기술이며, 가상 머신은 확실한 격리성을 갖추었지만 성능이 낮고, 컨테이너는 성능 효율이 높지만 호스트의 커널을 공유하면서 격리성 측면에서 떨어지는 특징을 가지고 있다. 이에 카타 컨테이너는 가상 머신 수준의 격리성과 컨테이너에 준하는 성능을 양립하는 것을 목표로 하며, 이에 하드웨어 기반의 가상화를 통한 격리성과 보안성을 확보하고, 아주 가벼운 VM을 기반으로 해 컨테이너의 성능에 가깝도록 했으며, 기존 도커(Docker)나 쿠버네티스(Kubernetes), 혹은 준(Zun) 컨테이너 관리 체계에도 쉽게 통합할 수 있게 했다고 소개했다.
카타 컨테이너는 현재 오픈스택 재단이 주도하는 파일럿 프로젝트 중 하나로 진행되고 있으며, 프로젝트의 시작은 Hyper.SH의 runV와 인텔의 Clear Containers 프로젝트가 합쳐진 것이 계기가 되었다. 이 프로젝트의 1.0 버전은 2018년 5월 22일 공개되었으며, 2018년 10월 22일 v1.3.1이 공개된 바 있다. 이 프로젝트의 목표는 기존 컨테이너 환경에서 각 컨테이너가 호스트 커널을 공유하는 데서 오는 부족한 격리성을 해결하면서, 기존 컨테이너 환경이 제공하는 성능 수준을 유지하는 것이다. 이를 통해 기존에 격리성 확보를 위해 사용자별 VM 위에 컨테이너 환경을 올리는 비효율을 해결할 수 있다.
카타 컨테이너에서의 컨테이너는 아주 가벼운 커널을 내장하고, 호스트 커널과는 하드웨어 가상화 기술로 연결되는데, 이는 기존의 가상 머신이 가지는 구조와 비슷하며, 이를 통해 서로 호스트 커널을 공유하지 않게 해 네임스페이스간 격리성을 확보한다. 또한 오케스트레이션 레벨에서는 베어메탈 호스트의 쿠버네티스 배포 환경 등에 기술을 통합해, 컨테이너 운영 환경과 동일하게 운영할 수 있다. 물론 이 때, 카타 컨테이너는 여타 컨테이너와 동일한 형태로 운영되어, 별다른 조치를 취할 필요도 없다.
카타 컨테이너를 구성하는 주요 기술로는 가상화 기술 ‘QEMU’와 런타임, 커널, Rootfs 이미지, 에이전트, Shim, 프록시 등이 꼽혔다. 그리고 카타 컨테이너에서 커널은, 컨테이너의 용도에 따라 특별한 커널이 필요하다면 이를 반영할 수 있다. 또한 독자적인 커널을 가지고 부팅이라는 과정이 있기 때문에 일반적인 컨테이너와는 달리 아주 작지만 Rootfs 이미지가 존재하고, 이를 통해 내부 VM에서 컨테이너 구동 환경을 준비한다. 이 외에도 에이전트는 네트워크, 메모리 리소스, C그룹 등의 마운트 포인트 관리를 위해 사용한다고 덧붙였다.
▲카타 컨테이너의 구성은 대략 이런 모습
▲향후 지원 예정 기능으로는 더 다양한 하이퍼바이저와 비 리눅스 워크로드 지원도 꼽혔다
카타 컨테이너에서, 컨테이너 관리 체계와 VM간 커맨드는 런타임을 통해, I/O는 Shim을 통해 VM과 연결되어, 하이퍼바이저를 거쳐 에이전트로 연결되는 모습을 갖추고 있다. 그리고 이 때, 구조적인 특징으로 전통적인 컨테이너 상태 확인 방법을 사용할 수 없고, I/O를 제공하는 Shim을 통해 VM 외부에서 필요한 정보를 전달할 수 있다고 언급했다. 또한 쿠버네티스 환경에서, 카타 컨테이너와 기존 컨테이너 환경은 같은 CRI(Container Runtime Interface)를 사용하며, 컨테이너의 구동 시 신뢰 수준에 따라 runc 혹은 카타 컨테이너를 통한 VM 내부 실행 등을 선택, 설정할 수 있을 것이라 덧붙였다.
네트워킹 측면에서는, 대부분의 경우에서 컨테이너는 L3 레벨로 움직이고, VM은 L2 레벨로 움직이는데, 이 레벨을 맞춰 주는 작업으로 큰 문제 없이 사용할 수 있게 된다고 소개되었다. 그리고 특별한 요건이 있는 경우, DPDK 등을 직접 VM에 연결하는 형태로 이 네트워크 레벨의 변환이 가능하고, 가속 스택을 사용한 VM으로의 직접 경로를 확보할 수 있다고 밝혔다. 또한 SR-IOV나 물리적인 인터페이스까지 카타 컨테이너에 직접 할당할 수 있다고 덧붙였다.
스토리지에서는, 간편하게 접목해 사용할 수 있는 9pfs를 오버레이를 통해 사용하거나, 디바이스 매퍼를 활용해 블록 디바이스를 연결할 수도 있다. 또한 NVDIMM의 이미지 파일을 직접 연결할 수 있는 방법도 제공하고 있으며, Rootfs를 통해 캐시를 생략하고, VM과 메모리를 바로 연결할 수 있다고 소개했다. 이 외에도 Ceph, 글러스터(gluster) 등의 네트워크 스토리지 연결도 어렵지 않게 가능하다고 덧붙였다.
향후 로드맵에서 강조되는 부분은 ‘보안’과 ‘격리성’으로, 컨테이너 차원에서는 ‘Seccomp’의 적용을 꼽았으며, 호스트 측면에서는 C그룹 격리와 네임스페이스 격리성 향상, 루트리스 QEMU, SELinux 정책 등을 꼽았다. 또한 네트워킹에서는 호환성을 강화하면서 성능 영향을 최소화하는 TC 미러링과 함께 기본 경로 최적화, 도커 스웜(swarm) DNS 지원, CNI 플러그인 지원 향상 등을 꼽았으며, 파일시스템에서는 Virtio-FS, NFS-vsock, 성능 개선을 위한 캐시 향상 등을 소개했다. 이 외에도 기능적 측면에서는 라이브 업그레이드, 더 많은 디바이스 매핑, 더 다양한 하이퍼바이저와 비 리눅스 워크로드 지원과 함께, 언제나 크기와 성능 측면을 중요하게 생각하고 있다고 강조했다. |
등록안내
