컨테이너

컨테이너란?

컨테이너는 데스크탑, 기존의 IT 또는 클라우드 등 어디서나 실행될 수 있도록 애플리케이션 코드가 해당 라이브러리 및 종속 항목과 함께 패키징되어 있는 소프트웨어 실행 유닛입니다.

이를 수행하기 위해 컨테이너는 OS의 기능(Linux 커널의 경우, 이름 공간 및 cgroups 프리미티브)을 활용하여 프로세스를 격리하고 해당 프로세스가 액세스할 수 있는 CPU, 메모리 및 디스크의 양을 제어하는 운영 체제(OS) 가상화의 형식을 활용합니다.

가상 머신과는 달리 컨테이너는 모든 인스턴스에 게스트 OS를 포함할 필요가 없으며, 그 대신 호스트 OS의 기능과 리소스를 간편하게 활용할 수 있습니다. 따라서 컨테이너는 소형이고, 빠르며, 이식성이 뛰어납니다.

컨테이너는 FreeBSD Jails 및 AIX Workload Partitions 등의 버전으로 수십 년 전에 처음 소개되었지만, 최신 개발자들 중 대부분은 Docker의 소개에 따라 2013년에 최신 컨테이너 시대가 도래했다고 기억합니다.

 

-> Docker 가 Container Environment 를 이끌면서 시대가 도래했다고 인식하는 경향이 많다. 실제적으로 이후에 Docker의 전체적인 DevOps 적 Mainternance를 위해서 Orchestration Tools 인 K8s 가 도입되었고, 많은 부분에서 정식적으로 K8s 에 대한 정식지원 발표로 인하여, K8s 가 대표적인 Tool 이 되었다.

 

 

컨테이너 vs. 가상 머신(VM)

컨테이너를 보다 잘 이해하는 한 가지 방법은 기존의 가상 머신(VM)과의 차이점을 살펴보는 것입니다. 온프레미스에 있건 혹은 클라우드에 있건 이와 무관하게, 기존의 가상화에서는 하이퍼바이저를 활용하여 물리적 하드웨어를 가상화합니다. 그리고 각각의 VM에는 애플리케이션, 이와 연관된 라이브러리 및 종속 항목과 함께 OS가 실행해야 하는 하드웨어의 가상 사본인 게스트 OS가 포함됩니다.

기반 하드웨어를 가상화하는 대신, 컨테이너는 운영 체제(일반적으로 Linux)를 가상화함으로써 각 개별 컨테이너에는 오직 애플리케이션과 함께 해당 라이브러리와 종속 항목만 포함됩니다. 게스트 OS의 부재는 컨테이너가 경량이며 빠르고 포터블한 이유를 설명합니다.

이러한 비교를 좀더 자세히 살펴보려면 "컨테이너 vs. VM: 차이점"을 참조하세요.

 

- 간단하게 요약하자면 VM에서는 하이퍼바이저를 활용하여 물리적 하드웨를 가상화한다는 소리는 Partition의 일부를 떼어 실제적으로 가상환경을 꾸릴 수 있게 가상화를 꾸린다고 설명하는 것이다.

그리고 이에 대한 Dependencies 인 Library, Guest OS(상주하는 OS)를 올린다고 생각하면 되는 듯 하다.

 

- Container 의 경우 Application 과 함께 Dependencies 만 올라간다. 그러니까 Guest OS 가 탑재되지 않은 상태에서 초경량 상태로 올라가기 때문에 K8s 는 이를 활용하여 replication 을 구축하고 일정 처리속도를 담아 지속적인 무중단 서비스를 운영할 수 있다.

 

컨테이너의 이점

특히 VM과 비교하여, 컨테이너의 주요 장점은 경량화와 이식성을 제공하는 추상화 레벨을 제공하는 것입니다.

• 경량: 컨테이너는 시스템 OS 커널을 공유함으로써 애플리케이션마다 전체 OS 인스턴스가 필요하지 않으며, 리소스에서 컨테이너 파일의 소형화와 간편함을 제공합니다. 특히 가상 머신과 비교하여 더 작아진 크기로 덕분에 수평 확장되는 클라우드 네이티브 애플리케이션을 보다 잘 지원하며 신속한 스핀업이 가능합니다.
  
  - 이 말인 즉슨, 시스템 OS Kernel 을 Sharing 한다는 부분에서, System OS Kernel (미리 컴파일된 커널이 상시 대기중인 상태로 base 로 공유됨 으로 진지구축을 빠르게 할 수 있따는 것이다.
  
  
• 이식성 및 플랫폼 독립성: 컨테이너가 모든 종속 항목들을 자신과 함께 전달하므로, 일단 소프트웨어를 한 번만 작성하면 랩탑, 클라우드 및 온프레미스 컴퓨팅 환경에서 이를 재구성하지 않고도 바로 실행할 수 있습니다.
• 최신형 개발 및 아키텍처 지원: 플랫폼 간의 배치 이식성/일관성 및 소형 크기의 조합 덕분에, 컨테이너는 최신형 개발에 매우 이상적입니다. 또한 DevOps, 서버리스 및 마이크로서비스 등의 빌드되어 있는 애플리케이션 패턴은 소규모 증분의 일반 코드 배치입니다.
• 활용도 향상: 이전의 VM처럼, 컨테이너를 사용하여 개발자와 운영자는 물리적 시스템의 CPU 및 메모리 활용도를 향상시킬 수 있습니다. 컨테이너의 보다 큰 장점은 마이크로서비스 아키텍처도 허용하므로 애플리케이션 컴포넌트를 보다 미세하게 배치 및 스케일링할 수 있다는 점입니다. 이는 단일 컴포넌트의 과중한 로드로 인해 전체 모놀리식 애플리케이션을 확장해야 하는 데 대한 매력적인 대안이 될 수 있습니다.

 

컨테이너에 대한 유스케이스

컨테이너는 특히 클라우드 환경에서 점점 더 두각을 나타내고 있습니다. 많은 기업들은 심지어 자체 애플리케이션과 워크로드에 대한 범용 컴퓨팅 플랫폼으로서 VM의 대용으로 컨테이너를 고려하고 있습니다. 그러나 이러한 광범위한 분야 내에서, 컨테이너가 특히 의미가 있는 주요 유스케이스가 있습니다.

• 마이크로서비스: 컨테이너는 소형이고 경량입니다. 따라서 이는 애플리케이션이 다수의 느슨하게 결합되고 독립적인 배치가 가능한 소형 서비스들로 구성되는 마이크로서비스 아키텍처에 매우 적절합니다.
• DevOps: 아키텍처로서 마이크로서비스와 플랫폼으로서 컨테이너의 결합은 소프트웨어의 구축, 장착 및 실행 방안으로서 DevOps를 채택하는 많은 팀들의 공통 기반입니다.
• 하이브리드, 멀티클라우드: 컨테이너가 랩탑, 온프레미스 및 클라우드 환경의 어디서나 일관되게 실행될 수 있으므로, 이는 기업들이 자체 데이터 센터와 결합하여 다수의 혼합형 퍼블릭 클라우드에서 운영을 수행하는 하이브리드 클라우드 및 멀티클라우드 시나리오의 이상적인 기반 아키텍처입니다.
• 애플리케이션 현대화 및 마이그레이션: 애플리케이션 현대화의 가장 일반적인 접근 방법 중 하나는 클라우드로의 마이그레이션이 가능하도록 이를 컨테이너화함으로써 시작됩니다.
  
  - 이 부분이 가장 중요한 핵심 포인트라 생각한다. 일반적인 접근 방법 중 하나라고 하지만, Container 화를 한다는 것은 Application 현대화 (말이 좀 거창하지) 하여 빨리 빨리 진지구축을 할 수 있도록 한다는 것이다.

컨테이너화

컨테이너를 활용하려면 소프트웨어를 서로 다르게 설계 및 패키징해야 하며, 이러한 프로세스를 통상적으로 컨테이너화라고 합니다.

애플리케이션을 컨테이너화하는 경우, 해당 프로세스에는 이와 관련된 환경 변수, 구성 파일, 라이브러리 및 소프트웨어 종속 항목과 함께 애플리케이션을 패키징하는 작업이 포함됩니다. 최종 결과물은 이후에 컨테이너 플랫폼에서 실행될 수 있는 컨테이너 이미지입니다. 자세한 정보를 얻으려면 아래의 "컨테이너화 설명" 동영상(08:09)을 시청하세요.

 

- 예를 들어, Root Base 인 Container 가 있다고 생각하고 이후에 파생된 Container 에서는 B형태 C형태 등으로 일부 소프트웨어가 구분되어 사용되어 질 수 있다. 그러니까 일일히 하나씩 쪼갠다고 생각하면 된다.

 

Kubernetes의 컨테이너 오케스트레이션

기업들이 종종 최신형 클라우드 네이티브 아키텍처의 일부로서 컨테이너를 채택하기 시작하면서, 개별 컨테이너의 단순성은 분산형 시스템에서 수백 개(심지어 수천 개)의 컨테이너를 관리하는 복잡성과 충돌하기 시작했습니다.

이러한 문제를 해결하기 위해, 다음을 포함하여 해당 라이프사이클 전체에서 방대한 볼륨의 컨테이너를 관리하는 방법으로서 컨테이너 오케스트레이션이 부상하게 되었습니다.

• 프로비저닝
• 중복성
• 상태 모니터링
• 리소스 할당
• 스케일링 및 로드 밸런싱
• 물리적 호스트 간의 이동

이러한 문제들의 해결을 지원하고자 많은 컨테이너 오케스트레이션 플랫폼(예: Apache Mesos, Nomad 및 Docker Swarm)이 구축되었지만, 2014년에 Google에서 소개한 오픈 소스 프로젝트인 Kubernetes는 순식간에 가장 인기 있는 컨테이너 오케스트레이션 플랫폼의 자리를 차지했습니다. 또한 이는 업계의 대부분이 관련 표준화 작업을 수행하는 플랫폼이기도 합니다.

Kubernetes를 이용하여 개발자와 운영자는 YAML 파일을 통해 전체 컨테이너 환경의 원하는 상태를 선언할 수 있습니다. 그 이후에는, Kubernetes가 해당 애플리케이션이나 워크로드에 대한 지정된 수의 인스턴스 배치, 실패 시에 해당 애플리케이션의 재부팅, 로드 밸런싱, 자동 스케일링, 제로 다운타임 배치 등을 포함한 활동을 통해 해당 상태를 설정 및 유지하는 온갖 힘든 작업들을 수행합니다.

Kubernetes에 대해 자세히 알아보려면, Kubernetes의 개요에 대한 Sai Vennam의 설명을 제시하는 아래의 동영상(10:59)을 시청하세요.

 

 

Kubernetes는 현재 Linux Foundation의 후원을 받는 벤더 애고니스틱 산업 그룹인 CNCF(Cloud Native Computing Foundation)에서 운영하고 있습니다.

 

 

Istio, Knative 및 확장형 컨테이너 에코시스템

컨테이너가 애플리케이션의 패키징과 실행을 위한 인기 있는 방법으로 지속적으로 성장함에 따라, 프로덕션 유스케이스를 강화하고 확장하도록 설계된 툴과 프로젝트의 에코시스템 또한 지속적인 증가세를 보이고 있습니다. Kubernetes 외에도, 컨테이너 에코시스템에서 가장 인기 있는 2개의 프로젝트는 바로 Istio 및 Knative입니다.

 

- K8s 이외에 가장 인기있는게 저거 2개라고 하는데 솔직히 잘 모르겠다.

 

 

Istio

개발자가 컨테이너를 활용하여 마이크로서비스 아키텍처를 빌드하고 실행하므로, 관리 문제는 이제 개별 컨테이너의 라이프사이클 고려사항을 벗어나서 엄청난 수의 소형 서비스(이를 종종 "서비스 메시"라고 함)들이 서로 간에 연결되고 서로 간에 관련되는 방식으로 이동하고 있습니다. Istio는 개발자가 검색, 트래픽, 모니터링, 보안 등과의 연관된 문제들을 보다 손쉽게 관리할 수 있도록 만들어졌습니다. Istio에 대해 자세히 알아보려면, "Istio의 정의"를 살펴보고 아래의 "Istio 설명" 동영상(05:06)을 시청하세요.

 

 

Knative

서버리스 아키텍처 역시 특히 클라우드 네이티브 커뮤니티 내에서 지속적으로 늘어나는 인기를 실감하고 있습니다. Knative의 엄청난 가치는 컨테이너형 서비스를 서버리스 기능으로 배치할 수 있는 능력입니다.

항상 실행되면서 필요 시에 응답(서버 작동과 유사함)하는 대신, 서버리스 기능은 "제로(0)로 스케일링"될 수 있습니다. 즉, 이는 호출되지 않는 한 전혀 실행되지 않습니다. 수만 개의 컨테이너에 적용되는 경우, 이 모델은 엄청난 양의 컴퓨팅 파워를 절감할 수 있습니다.

Knative에 대해 자세히 알아보려면 아래의 "Knative 정의" 동영상(07:58)을시청하세요.