Kubernetes의 탄생 배경

Docker 기반 개발방식의 가속화

불과 몇년전만 하여도 Docker 기반의 App 구동은 선택적이었으나 이제는 거의 당연시 되어가고 있다.
Docker 를 이용함으로서 얻는 이점이 너무 많기 때문에. 그리고 많은 레퍼런스가 나오면서 사용하기도 그닥 어렵지 않다.

Docker 활용의 장점은 다음과 같다.

• 기민한 애플리케이션 생성과 배포 : VM 이미지 사용 대비 효율적.
• 지속적인 개발, 통합 및 배포 : 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다.
• 개발과 운영의 관심사 분리 : 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다. 가시성은 OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
• 개발, 테스팅 및 운영 환경에 걸친 일관성 : 랩탑에서도 클라우드에서와 동일하게 구동된다.
• 클라우드 및 OS 배포판 간 이식성 : Ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다.
• 애플리케이션 중심 관리 : 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS 상에서 애플리케이션을 실행하는 수준으로 추상화 수준이 높아진다.
• 느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스 : 애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 관리될 수 있다.
• 리소스 격리 : 애플리케이션 성능을 예측할 수 있다.

컨테이너 관리 툴의 필요성 대두

처음에는 몇개의 컨테이너만 관리하면 되었지만, 계속해서 서비스가 커지고 그 서비스를 도커라이징하여 만들고 띄우게 되면서 수십 수백개의 컨테이너를 관리해야 하는 경우가 생기게 되었다. 때문에 여러 서버들을 클러스터링하고, 클러스터링된 환경 내에서 필요시에 네트워크 환경을 격리하고, 내부 DNS 를 구성하거나, 내가 원하는 서비스에 대한 컨테이너를 배포 또는 수정한다거나, 상태를 관리 및 모니터링 할 수 있는 기능이 필요하게 되었다.

이러한 필요성 때문에 이른바 '컨테이너 오케이스트레션 툴' 들이 등장하게 되었다.

초반에는 Docker Swam, AWS 의 ECS(Elastic Container Service), Mesos 의 Marathon 등 여러 툴들을 사용하였으나 Kubernetes(이하 쿠버) 가 등장 하게되고 지금에 와서는 컨테이너 오케이스트레이션 툴의 표준이 되었다. 이는 대규모 컨테이너를 관리했던 구글의 노하우 및 확장성, MS, Red Hat, IBM 은 기업들의 참여 및 잘 짜인 설계가 있었기에 가능했다.

쿠버의 주요 기능

• 여러 호스트에 걸쳐 컨테이너를 오케스트레이션 -> 클러스터링
• 하드웨어를 최대한 활용하여 엔터프라이즈 애플리케이션을 실행하는 데 필요한 리소스를 극대화.
• 애플리케이션 배포 및 업데이트를 제어하고 자동화.
  
• 스토리지를 장착 및 추가해 스테이트풀(stateful) 애플리케이션을 실행.
• 컨테이너화된 애플리케이션과 해당 리소스를 즉시 확장.
• 하나의 클러스터를 논리적으로 구분하여 유연하고 확장성 있는 리소스 관리 가능.
  
• 자동 배치, 자동 재시작, 자동 복제, 자동 확장을 사용해 애플리케이션 상태 확인 및 자동복구 수행.
• Federation, Multi Cluster : 클라우드의 쿠버와 자체서버의 쿠버를 묶어서 하나로 사용 가능.

** 참고자료
Subicura 블로그 : https://subicura.com/2019/05/19/kubernetes-basic-1.html
Kubernetes 공식 사이트 : https://kubernetes.io/ko/docs/concepts/overview/what-is-kubernetes/
Redhat 공식 사이트 : https://www.redhat.com/ko/topics/containers/what-is-kubernetes