2018.10.30

“오픈소스 세계의 혁신을 이끌” 쿠버네티스의 차세대 플랫폼에 대한 5가지 답

BrandPost Sponsored by Redhat Brandpost
Brian Gracely | Redhat

 



최근 쿠버네티스 아키텍처와 기능에 많은 관심이 모이고 있다. 여기에 더해 오픈소스 커뮤니티에서 이루어지고 있는 혁신에 대한 논의, 그리고 이 혁신이 어떻게 레드햇 오픈시프트 컨테이너 플랫폼으로 이어지는지에 대해 질의 응답식으로 알아보았다.

Q1. 서비스형 컨테이너(CaaS, Container as a Service)란 무엇인가? 서비스형 플랫폼(PaaS)은 표준화된 플랫폼을 제공하고 사용자들이 애플리케이션을 구동하는 것을 뜻하는데, 서비스형 컨테이너는 컨테이너를 서비스로 제공하는 것인가? 
2011년 미국 국립표준기술연구소가 클라우드 컴퓨팅을 최초로 정의할 당시에 서비스형 인프라(IaaS), 서비스형 플랫폼(PaaS), 그리고 클라우드 환경에서 운영되는 애플리케이션 서비스(SaaS)를 정의했다. 당시 IaaS는 애플리케이션 패키징 및 격리 단위가-가장 널리 사용되던 기술이었기 때문에-가상머신(VM)이라는 것을 의미했다. 그 후 리눅스 컨테이너는 사용처도 늘어나고 성숙을 거듭했다. 따라서 컨테이너(Kubernetes 사용)에 대한 관리 프레임워크를 제공하는 플랫폼(예 : Red Hat OpenShift Container Platform)은 IaaS 라고 부를 수 있다.

그러나, 이런 표현이 시장에서는 혼동을 일으킬 수 있으므로 오늘날에는 대체로 CaaS라는 표현을 사용해서 패키징과 격리가 컨테이너를 사용해서 이루어짐을 나타내고 있다. 추가로, 레드햇 오픈시프트 컨테이너 플랫폼은 개발 효율을 향상시키는 PaaS 기능 역시 제공하고 있으므로, 개발 및 운영 부서의 선택에 따라 CaaS이면서 동시에 PaaS라고도 볼 수 있을 것이다.

Q2. 우리 회사는 컨테이너 보안에 대한 우려가 있다. 레드햇 오픈시프트 컨테이너 플랫폼은 레지스트리 거버넌스와 쿠버네티스 사이의 간극을 채울 수 있는가?
이 질문에 대한 답은 두 가지로 해야 할 것 같다. 첫째는 레지스트리 안에 존재하고 레지스트리에 추가되는 컨테이너 이미지내의 컨텐츠에 대한 보안이고, 둘째는 컨테이너가 구동되고 있는 플랫폼의 보안이다. 

첫번째 질문에 대해 답을 하자면, 시중에 있는 컨테이너 레지스트리는 대체로 (취약점을 찾는)이미지 스캐닝과 이미지 서명을 가지고 제공된다. 이러한 기능은 레드햇 오픈시프트 컨테이너 레지스트리에도 레드햇 Quay 및 다수의 오픈시프트 커먼즈(OpenShift Commons) 생태계 파트너에서 모두 제공한다. 또한, 레드햇 컨테이너 카탈로그(RHCC)는 가장 최신이고 인증받은 안전한 컨테이너 이미지 소스를 제공한다. 

두번째 질문에 대한 답으로는, 레드햇은 면밀한 방어 전략을 신뢰하며 컨테이너화한 애플리케이션에 대한 올바른 방어는 여러 겹의 보안이 있어야만 한다고 본다. 좀 더 자세한 내용은 백서(whitepaper)를 참고하자.

Q3. 쿠버네티스로 컨테이너화되지 않은 애플리케이션을 총괄할 수 있는가?
현재 쿠버네티스는 컨테이너화한 애플리케이션에 한하여 오케스트레이션을 제공한다. 그러나 현재 “쿠브버트”(“Kubevirt”)라는 오픈소스 프로젝트는 쿠버네티스로 가상머신도 관리할 수 있는 가상화된 API를 개발하고 있다. 레드햇은 이 API를 컨테이너 네이티브 가상화(CNV, Container Native Virtualization)라는 이름으로 제공할 예정이다.

Q4: 마이크로서비스와 서버리스는 무슨 관계인가? 쿠버네티스는 이 두 개념을 어떻게 다루며 바꾸고 있는가?
마이크로서비스란 상대적으로 작은 요소에서 애플리케이션을 만드는 것이다. 보통은 하나의 특정한 작업으로 국한되기에 넓은 시스템에서 독립적으로 개별 업데이트를 하는 것이 가능하다. 이는 대부분 혹은 모든 기능이 서로 밀접하게 연관되어 있어서 새로운 기능을 업데이트하거나 추가하기 어려웠던 "모놀리식(monolithic)" 애플리케이션과는 다르다. 마이크로서비스가 새로운 클라우드 네이티브 애플리케이션과 함께 사용되는 경우도 있다.

서버리스는 애플리케이션 플랫폼 개념 중 하나로, 애플리케이션 개발자가 하부 인프라 자원이나 자원의 스케일링에 대한 고려를 할 필요가 없는 플랫폼을 의미한다. 서버리스 환경에 존재하는 애플리케이션들은 "함수(functions)" 혹은 특정 기능이나 작업을 하는 코드로 정의된다. 그렇기에 서버리스와 서비스형 함수(FaaS)는 흔히 상호 보완적으로 혹은 같은 의미로 사용된다. 쿠버네티스는 이런 마이크로서비스 애플리케이션에 관한 패턴과 프레임워크를 1.0 버전부터 지원해왔다. 

최근에는 쿠버네티스에서 구동되는 몇가지 서버리스 프로젝트(Fission, Fn, Kubeless, Nuclio, OpenFaaS, OpenWhisk, Riff 등)가 만들어졌다. 레드햇에서는 오픈시프트 상 오픈위스크(OpenWhisk)를 강조하고 오픈위스크를 바탕으로 한 레드햇 오픈시프트 클라우드 펑션(Red Hat OpenShift Cloud Functions)이라는 서버리스 제품을 개발자용으로 시연한 적이 있다.

Q5: 쿠버네티스는 도커(Docker) 없이 존재할 수 있는가? 이는 어떠한 방향으로 진화할 것인가?
쿠버네티스 초기 버전에서 지원되는 컨테이너 런타임은 오로지 도커였다. 그 후 서서히 다른 컨테이너 런타임이 출범했다. 예를 들면 OCI(Open Container Initiative)는 다양한 컨테이너 런타임을 표준화하고 CRI(Container Runtime Interface)라는 개념을 만드는 데 앞장섰다. 그러면서 다양한 컨테이너 런타임(CRI-O, containerd 등)의 표준 인터페이스와 개략화를 제공했다. 필자는 향후 Buildah, Podman, Skopeo 등을 사용하면 쿠버네티스를 도커 없이 구동할 수 있으리라고 예측하고 있다.  


2018.10.30

“오픈소스 세계의 혁신을 이끌” 쿠버네티스의 차세대 플랫폼에 대한 5가지 답

BrandPost Sponsored by Redhat Brandpost
Brian Gracely | Redhat

 



최근 쿠버네티스 아키텍처와 기능에 많은 관심이 모이고 있다. 여기에 더해 오픈소스 커뮤니티에서 이루어지고 있는 혁신에 대한 논의, 그리고 이 혁신이 어떻게 레드햇 오픈시프트 컨테이너 플랫폼으로 이어지는지에 대해 질의 응답식으로 알아보았다.

Q1. 서비스형 컨테이너(CaaS, Container as a Service)란 무엇인가? 서비스형 플랫폼(PaaS)은 표준화된 플랫폼을 제공하고 사용자들이 애플리케이션을 구동하는 것을 뜻하는데, 서비스형 컨테이너는 컨테이너를 서비스로 제공하는 것인가? 
2011년 미국 국립표준기술연구소가 클라우드 컴퓨팅을 최초로 정의할 당시에 서비스형 인프라(IaaS), 서비스형 플랫폼(PaaS), 그리고 클라우드 환경에서 운영되는 애플리케이션 서비스(SaaS)를 정의했다. 당시 IaaS는 애플리케이션 패키징 및 격리 단위가-가장 널리 사용되던 기술이었기 때문에-가상머신(VM)이라는 것을 의미했다. 그 후 리눅스 컨테이너는 사용처도 늘어나고 성숙을 거듭했다. 따라서 컨테이너(Kubernetes 사용)에 대한 관리 프레임워크를 제공하는 플랫폼(예 : Red Hat OpenShift Container Platform)은 IaaS 라고 부를 수 있다.

그러나, 이런 표현이 시장에서는 혼동을 일으킬 수 있으므로 오늘날에는 대체로 CaaS라는 표현을 사용해서 패키징과 격리가 컨테이너를 사용해서 이루어짐을 나타내고 있다. 추가로, 레드햇 오픈시프트 컨테이너 플랫폼은 개발 효율을 향상시키는 PaaS 기능 역시 제공하고 있으므로, 개발 및 운영 부서의 선택에 따라 CaaS이면서 동시에 PaaS라고도 볼 수 있을 것이다.

Q2. 우리 회사는 컨테이너 보안에 대한 우려가 있다. 레드햇 오픈시프트 컨테이너 플랫폼은 레지스트리 거버넌스와 쿠버네티스 사이의 간극을 채울 수 있는가?
이 질문에 대한 답은 두 가지로 해야 할 것 같다. 첫째는 레지스트리 안에 존재하고 레지스트리에 추가되는 컨테이너 이미지내의 컨텐츠에 대한 보안이고, 둘째는 컨테이너가 구동되고 있는 플랫폼의 보안이다. 

첫번째 질문에 대해 답을 하자면, 시중에 있는 컨테이너 레지스트리는 대체로 (취약점을 찾는)이미지 스캐닝과 이미지 서명을 가지고 제공된다. 이러한 기능은 레드햇 오픈시프트 컨테이너 레지스트리에도 레드햇 Quay 및 다수의 오픈시프트 커먼즈(OpenShift Commons) 생태계 파트너에서 모두 제공한다. 또한, 레드햇 컨테이너 카탈로그(RHCC)는 가장 최신이고 인증받은 안전한 컨테이너 이미지 소스를 제공한다. 

두번째 질문에 대한 답으로는, 레드햇은 면밀한 방어 전략을 신뢰하며 컨테이너화한 애플리케이션에 대한 올바른 방어는 여러 겹의 보안이 있어야만 한다고 본다. 좀 더 자세한 내용은 백서(whitepaper)를 참고하자.

Q3. 쿠버네티스로 컨테이너화되지 않은 애플리케이션을 총괄할 수 있는가?
현재 쿠버네티스는 컨테이너화한 애플리케이션에 한하여 오케스트레이션을 제공한다. 그러나 현재 “쿠브버트”(“Kubevirt”)라는 오픈소스 프로젝트는 쿠버네티스로 가상머신도 관리할 수 있는 가상화된 API를 개발하고 있다. 레드햇은 이 API를 컨테이너 네이티브 가상화(CNV, Container Native Virtualization)라는 이름으로 제공할 예정이다.

Q4: 마이크로서비스와 서버리스는 무슨 관계인가? 쿠버네티스는 이 두 개념을 어떻게 다루며 바꾸고 있는가?
마이크로서비스란 상대적으로 작은 요소에서 애플리케이션을 만드는 것이다. 보통은 하나의 특정한 작업으로 국한되기에 넓은 시스템에서 독립적으로 개별 업데이트를 하는 것이 가능하다. 이는 대부분 혹은 모든 기능이 서로 밀접하게 연관되어 있어서 새로운 기능을 업데이트하거나 추가하기 어려웠던 "모놀리식(monolithic)" 애플리케이션과는 다르다. 마이크로서비스가 새로운 클라우드 네이티브 애플리케이션과 함께 사용되는 경우도 있다.

서버리스는 애플리케이션 플랫폼 개념 중 하나로, 애플리케이션 개발자가 하부 인프라 자원이나 자원의 스케일링에 대한 고려를 할 필요가 없는 플랫폼을 의미한다. 서버리스 환경에 존재하는 애플리케이션들은 "함수(functions)" 혹은 특정 기능이나 작업을 하는 코드로 정의된다. 그렇기에 서버리스와 서비스형 함수(FaaS)는 흔히 상호 보완적으로 혹은 같은 의미로 사용된다. 쿠버네티스는 이런 마이크로서비스 애플리케이션에 관한 패턴과 프레임워크를 1.0 버전부터 지원해왔다. 

최근에는 쿠버네티스에서 구동되는 몇가지 서버리스 프로젝트(Fission, Fn, Kubeless, Nuclio, OpenFaaS, OpenWhisk, Riff 등)가 만들어졌다. 레드햇에서는 오픈시프트 상 오픈위스크(OpenWhisk)를 강조하고 오픈위스크를 바탕으로 한 레드햇 오픈시프트 클라우드 펑션(Red Hat OpenShift Cloud Functions)이라는 서버리스 제품을 개발자용으로 시연한 적이 있다.

Q5: 쿠버네티스는 도커(Docker) 없이 존재할 수 있는가? 이는 어떠한 방향으로 진화할 것인가?
쿠버네티스 초기 버전에서 지원되는 컨테이너 런타임은 오로지 도커였다. 그 후 서서히 다른 컨테이너 런타임이 출범했다. 예를 들면 OCI(Open Container Initiative)는 다양한 컨테이너 런타임을 표준화하고 CRI(Container Runtime Interface)라는 개념을 만드는 데 앞장섰다. 그러면서 다양한 컨테이너 런타임(CRI-O, containerd 등)의 표준 인터페이스와 개략화를 제공했다. 필자는 향후 Buildah, Podman, Skopeo 등을 사용하면 쿠버네티스를 도커 없이 구동할 수 있으리라고 예측하고 있다.  


X