컨테이너가 기존 VM(가상 머신)과 어떻게 다른지 알아보면 컨테이너를 더 잘 이해할 수 있습니다. 온프레미스든 클라우드든, 기존 가상화에서는 하이퍼바이저를 사용하여 물리적 하드웨어를 가상화합니다. 그런 다음 각 VM에는 애플리케이션 및 관련 라이브러리 및 종속성과 함께 게스트 OS와 OS 실행에 필요한 하드웨어의 가상 복사본이 포함됩니다.

컨테이너는 기본 하드웨어를 가상화하는 것이 아니라 운영 체제(일반적으로 Linux)를 가상화하므로 각 개별 컨테이너에는 오직 애플리케이션과 해당 라이브러리 및 종속성만 포함되어 있습니다. 컨테이너는 게스트 OS가 없어서 매우 가볍기 때문에 빠르고 휴대성이 뛰어납니다.

이 비교에 대한 자세한 내용은 '컨테이너와 VM: 차이점은 무엇인가요?'를 참조하세요.

VM과 비교할 때 컨테이너의 가장 큰 장점은 가볍고 이식 가능한 추상화 수준을 제공한다는 것입니다. 주요 장점은 다음과 같습니다.

경량: 컨테이너는 머신 OS 커널을 공유하므로 애플리케이션당 전체 OS 인스턴스가 필요하지 않으며 컨테이너 파일을 작게 만들어 리소스를 쉽게 사용할 수 있습니다. 특히 VM에 비해 크기가 작기 때문에 컨테이너는 빠르게 가동되고 수평적으로 확장되는 클라우드 네이티브 애플리케이션을 더 잘 지원할 수 있습니다.

이식 가능성 및 플랫폼 독립성: 컨테이너는 모든 종속성을 가지고 있으므로 소프트웨어를 한 번 작성하고 나면 다시 구성할 필요 없이 노트북, 클라우드 및 온프레미스 컴퓨팅 환경 전반에서 실행할 수 있습니다.

최신 개발 및 아키텍처 지원: 컨테이너는 플랫폼 전반에 걸친 배포 이식성/일관성과 작은 크기의 조합 덕분에  DevOps, 서버리스 및 정기적인 코드 배포를 조금씩 사용하여 구축되는 마이크로서비스와 같은 최신 개발 및 애플리케이션 패턴에 이상적입니다.

활용도 향상: 기존의 VM과 마찬가지로 컨테이너 역시 개발자와 운영자가 물리적 머신의 CPU 및 메모리 사용률을 개선하는 데 도움을 줍니다. 컨테이너는 마이크로서비스 아키텍처도 지원하기 때문에 애플리케이션 구성 요소를 더 세밀하게 배포하고 확장할 수 있다는 점에서 더욱 발전했다고 할 수 있습니다. 이는 단일 구성 요소의 부하로 인해 전체 모놀리식 애플리케이션을 확장해야 하는 것에 비교하면 매력적인 대안입니다.

최근 IBM 설문조사에서 개발자와 IT 경영진은 컨테이너 사용의 여타 많은 장점을 보고했습니다.

보고서 전문 다운로드: 엔터프라이즈 내 컨테이너

컨테이너는 특히 클라우드 환경에서 점점 더 중요해지고 있습니다. 애플리케이션과 워크로드를 위한 범용 컴퓨팅 플랫폼으로 VM을 대체하기 위해 컨테이너를 고려하는 조직이 많아지고 있습니다. 그러나 이러한 광범위한 범위 중에서도 컨테이너가 특히 중요하게 여겨지는 사용 사례가 있습니다.

• 마이크로서비스: 컨테이너는 작고 가볍기 때문에 애플리케이션이 느슨하게 결합되고 독립적으로 배포 가능한 여러 개의 작은 서비스로 구성된 마이크로서비스 아키텍처와 잘 어울립니다.
• DevOps: 아키텍처로서의 마이크로서비스와 플랫폼으로서의 컨테이너의 조합은 소프트웨어를 빌드, 배포 및 실행 방식으로 DevOps를 채택하는 많은 팀에게 공통된 기반입니다.
• 하이브리드 및 멀티클라우드: 컨테이너는 노트북, 온프레미스, 클라우드 환경 등 어디서나 일관되게 실행될 수 있기 때문에 조직이 자체 데이터 센터와 함께 여러 퍼블릭 클라우드를 혼합하여 운영하는 하이브리드 클라우드 및 멀티 클라우드 시나리오에 가장 적합한 기본 아키텍처입니다.
• 애플리케이션 현대화 및 마이그레이션: 애플리케이션 현대화를 위한 가장 일반적인 접근 방식 중 하나는 클라우드 마이그레이션에 대비하여 애플리케이션을 컨테이너화하는 것입니다.
  

컨테이너를 활용하기 위해서는 소프트웨어를 다르게 설계하고 패키징해야 하며, 이 프로세스를 일반적으로 컨테이너화라고 합니다.

애플리케이션을 컨테이너화할 때는 관련 환경 변수, 구성 파일, 라이브러리 및 소프트웨어 종속성으로 애플리케이션을 패키징하는 것이 프로세스에 포함됩니다. 그 결과, 컨테이너 플랫폼에서 실행할 수 있는 컨테이너 이미지가 생성됩니다.

Kubernetes를 사용한 컨테이너 오케스트레이션

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

이러한 문제를 해결하기 위해 수명 주기 전반에 걸쳐 대량의 컨테이너를 관리하는 방법으로 컨테이너 오케스트레이션이 등장했습니다.

• 프로비저닝
• 이중화
• 상태 모니터링
• 리소스 할당
• 확장 및 로드 밸런싱
• 물리적 호스트 간 이동

많은 컨테이너 오케스트레이션 플랫폼(예: Apache Mesos, Nomad 및 Docker Swarm)이 출시되었지만, Google이 2014년에 도입한 오픈 소스 프로젝트인 Kubernetes가 순식간에 가장 인기 있는 컨테이너 오케스트레이션 플랫폼이자 업계 대다수가 표준화의 기반으로 삼고 있는 플랫폼이 되었습니다.

Kubernetes를 사용하면 개발자와 운영자가 YAML 파일을 통해 전체 컨테이너 환경의 원하는 상태를 선언할 수 있으며, 그러면 Kubernetes는 특정 애플리케이션 또는 워크로드의 지정된 수의 인스턴스 배포, 해당 애플리케이션이 실패할 경우 재부팅, 로드 밸런싱, 자동 확장, 다운타임 제로 배포 등의 활동을 통해 해당 상태를 설정하고 유지하는 모든 처리 작업을 수행합니다.

Kubernetes는 현재 Linux Foundation의 후원을 통해 제공업체에 구애받지 않는 업계 그룹인 Cloud Native Computing Foundation(CNCF)가 운영하고 있습니다.

컨테이너가 애플리케이션을 패키징하고 실행하는 인기 있는 방법으로 계속 탄력을 받으면서 프로덕션 사용 사례를 수용하고 확장하도록 설계된 도구 및 프로젝트의 에코시스템이 계속 성장하고 있습니다. Kubernetes 외에도 컨테이너 에코시스템에서 가장 인기 있는 두 가지 프로젝트는 Istio와 Knative입니다.

Istio

개발자가 컨테이너를 사용하여 마이크로서비스 아키텍처를 구축하고 실행하면서, 관리 문제가 개별 컨테이너의 수명 주기 고려 사항을 넘어 수많은 소규모 서비스들이 서로 연결되고 관련되는 방식((흔히 '서비스 메시'라고 함) )에까지 영향을 미칩니다. Istio는 개발자가 검색, 트래픽, 모니터링, 보안 등과 관련된 문제를 더 쉽게 관리할 수 있도록 하기 위해 만들어졌습니다. 

Istio에 대해 자세히 알아보기

Knative

서버리스 아키텍처는 특히 클라우드 네이티브 커뮤니티 내에서 인기가 계속 높아지고 있습니다. 예를 들어 Knative는 컨테이너화된 서비스를 서버리스 기능으로 배포할 수 있다는 점에서 상당한 가치를 제공합니다.

서버리스 기능은 서버처럼 항상 실행되면서 필요할 때만 응답하는 대신, 요청이 없으면 아예 실행되지 않는 '제로 스케일링'이 가능합니다. 수만 개의 컨테이너에 이 모델을 적용하면 막대한 양의 컴퓨팅 성능을 절약할 수 있습니다.