Brief Intro
간단하게 쿠버네티스 는, 컨테이너 런타임 활용에 대한 서비스를 지원하는 오케스트레이션 플랫폼이다.
컨테이너 기술이 새로운 국면을 맞이하게된 시점으로 돌아가보자.
당시에는 배포 가능한 애플리케이션 구성 요소의 수가 많아지고 있었고, 이에 따라 앱의 모든 구성 요소의 관리가 점점 어려워지는 바람에 구글은 골머리를 썩고 있었다.
하이퍼바이저가 적용된 베어메탈에서 여러 개의 앱을 띄운다고 생각해보자.
( 하이퍼 바이저는 physical server 즉 베어 메탈로 하여금 리소스를 분배하여 가상 머신을 만들 고 실행 시킬수 있도록 해주는 프로세서라고 생각하면 된다.)
첫 번째 방법으로는, 서비스마다 VM 을 띄우는 것 (모든 마이크로서비스가 한 개의 VM에 집약되어 관리되는 모놀리스 방식) , 두 번째 방법으로는 VM 이 아닌 리눅스 '컨테이너' 를 활용하여 리눅스 커널단에서 직접적인 배포 라는 두 가지 옵션이 있을 것이다.
전자의 경우 도커와 컨테이너가 유행하기 이전까지 전형적인 앱 배포 방식이었다. 배포해야 할 서비스의 수가 늘어날 수록 리소스 관리 측면에 있어서 어려움이 있을 수 밖에 없는 것은 당연한 일이었다. 이에 반해, 이동성과 리소스 효율성이 뛰어났던 컨테이너의 경우 최신 클라우드 네이티브 애플리케이션의 컴퓨팅 단위가 되었다.
Details
왜? 라는 질문을 했다면... 좋은 자세다. 굿.
컨테이너 기술이 가상 머신 (VM)을 통한 애플리케이션 배포보다 우수한 이유는 크게 다섯 가지 측면에서 나타난다.
이동성 (Portability)
컨테이너는 응용 프로그램과 필요한 모든 종속성을 패키지로 묶어 이식성이 뛰어나다. 컨테이너는 호스트 시스템의 운영체제와 상관없이 동일한 환경에서 실행될 수 있으며, 개발 환경과 프로덕션 환경 간에 쉽게 이동할 수 있다. 컨테이너는 하나의 패키지다. 앱을 run 하기 위한 명령, meta-data가 모두 포함된 하나의 패키지 덩어리이기 때문에 어떠한 앱을 다른 워크 노드에서 띄우는데 문제가 전혀 없다. ( run app A on B node, -> run app B on C node (o) )
리소스 효율성 (Resource Efficiency)
가상 머신은 전체 운영체제를 가상화하고 별도의 커널을 사용하기 때문에 무겁고, 높은 오버헤드가 발생한다. 반면, 컨테이너는 호스트 시스템의 커널을 공유하므로 가벼우면서도 빠르게 시작되고 중지될 수 있다. 이로써 더 적은 메모리와 디스크 공간을 사용하며, 빠른 배포와 확장이 가능하다. (반대로 생각하면? 별도의 커널이나 OS설정이 필요한 애플리케이션의 경우 컨테이너를 활용할 수 없다)
시스템 관리 용이성 (Management Ease)
컨테이너는 이미지로서 애플리케이션 및 종속성을 패키징하므로, 관리 및 배포가 훨씬 간단하다. 이는 개발, 테스트, 그리고 프로덕션 환경에서 일관성 있는 운영을 가능케 한다.
자동화와 스케일링 (Automation and Scaling)
컨테이너 오케스트레이션 도구들 (예: Kubernetes, Docker Swarm)을 활용하면 컨테이너를 자동으로 배포하고 관리할 수 있다. 이는 애플리케이션의 자동 확장과 고가용성을 쉽게 구현할 수 있게 한다. ( 간단하게 말하면, 컨테이너와 관련된 여러 툴들이 이미 많이 있기 때문에 직접 VM 안에서 배포를 위해 이것저것 만지지 않아도 된다는 뜻이다)
개발자와 운영팀 간 협업 (DevOps Collaboration)
컨테이너는 애플리케이션과 인프라스트럭처를 분리함으로써 개발자와 운영팀 간의 협업을 강화한다. 개발자는 애플리케이션을 개발하고 패키징하고, 운영팀은 컨테이너를 관리하고 배포하는 데 중점을 둘 수 있다.
다른 모종의 이유들도 많겠지만, 위의 큼지막한 다섯 가지 이유만으로도 컨테이너 기술은 현대의 애플리케이션 배포 및 관리에서 매우 인기 있는 선택지가 되었다 정도 알고 있으면 좋을 것 같다.
Linux / Kubernetes 와 관련된 디테일은 차차 공부하며 정리하도록 하고, 내일은 Container와 뗄레야 뗄 수 없는 Docker 에 대해서 잠깐 정리하고 지나가고자 한다.