Kubernetes의 등장 배경
kubernetes는 "컨테이너 오케스트레이션 플랫폼"이다.
이게 뭔지를 이해하기 위해서는 등장배경부터 아는 것이 좋다.
kubernetes는 앞뒤 다 자르고 말하면 배포를 쉽게 도와주는 플랫폼이다.
배포란, 만들어진 소프트웨어를 사용자들이 접근할 수 있는 환경에 설치하고 공개하는 과정을 의미한다.
그래서 kubernetes의 등장을 이해하려면 그 이전 시대에는 배포를 어떻게 했는지 이해해야 한다.
- 전통적인 배포 - 2000년대 초반
과거에는 물리 서버에서 직접 애플리케이션을 배포했다.
이러한 방식에는 아래와 같은 단점이 있었다.
-
하나의 물리 서버에 여러 애플리케이션 배포 시 리소스 충돌 발생
-
서버 전체를 증설해야해서 scaling(확장)이 어려움
-
장애 시 복구가 복잡하고 시간 소요
- 가상화 기술 도입 - 2000년대 중후반
위의 문제를 극복하기 위해, VMware 등 가상화 솔루션이 등장하게 되었다.
가상화 기술은 물리 서버를 여러 가상머신으로 분할하여 리소스를 격리했고 이를 통해 효율성을 개선했다.
하지만 가상의 OS 위에서 동작하는 방식이었기에 무거웠고(=불필요한 리소스가 많이든다) 관리가 복잡했다.
- 클라우드와 마이크로서비스의 부상 - 2010년대 초반
AWS 등 Cloud 서비스가 확산되며 MSA가 새로운 아키텍처 트렌드로 자리잡게 되었다.
그에 따라 애플리케이션을 작은 서비스 단위로 분해하고 더 빠른 배포와 독립적인 확장이 필요해졌다.
- 컨테이너 기술의 등장 - 2013년
Docker라는 컨테이너 기반 오픈소스 가상화 플랫폼이 등장했다. Docker는
- 가볍고 빠른 애플리케이션 패키징
- "한 번 빌드하면 어디서든 실행"한다는 개념
- 개발환경과 운영환경의 일치
등의 장점이 있는 혁신적인 기술이다.
사실 기존에도 리눅스에서 컨테이너 관련 기술은 있었다. 하지만 진입 장벽이 높았는데 Docker가 개발·배포·운영에 필요한 모든 것을 대중적이고 사용하기 쉽게 표준화하며 컨테이너 기술이 대중화되었다.
- Kubernetes 의 탄생 - 2014년
구글은 여러 사업을 영위하며 10년 이상 Borg라는 내부 컨테이너 오케스트레이션 세스템을 운영하고 있었다.
수십억 개의 컨테이너를 매주 배포하며 해당 기간 동안 방대한 규모의 서비스 운영 경험을 축적하게 되었다.
하지만 이는 구글 내부 전용으로 설계되었고, 따라서 외부에 공개하기 어려운 기술이었다.
대신, 구글은 급속히 성장하는 컨테이너 생태계에 표준을 제공하고자 Borg의 경험을 바탕으로 오픈소스 버전을 개발하게 된다. 그것이 바로 클라우드 네이티브 애플리케이션 관리의 복잡성을 해결해준 kubernetes이다.
구글이 Kubernetes를 오픈소스로 공개한 이유는 kubernetes를 업계 표준으로 만들기 위함이었다. Kubernetes를 업계 표준으로 만들어 AWS와 Azure에 비해 클라우드 시장에서 뒤쳐져있던 GCP의 경쟁력을 높이고자 했고, 실제로 Kubernetes는 이후 업계 표준이 된다.
kubernetes는 아래의 문제들을 해결했다.
- 수백, 수천 개의 컨테이너 관리
- 자동 스케일링과 로드벨런싱
- 장애 복구와 자가 치유
- 롤링 업데이트와 배포 전략
- 서비스 디스커버리와 설정 관리
- 오픈소스 생태계에 수용 - 2015년
2015년, 리눅스 재단은 클라우드 네이티브 컴퓨팅을 위한 오픈소스 기술들을 육성하고 표준화 하기 위해 CNCF(Cloud Native Computing Foundation)를 창립한다. 이 때 구글이 Kubernetes를 중립적인 재단인 CNCF에 기증하면서 업계 전반의 신뢰와 참여를 이끌어 낼 수 있었고, Kubernetes는 점진적으로 사실상 표준으로 자리잡게 되었다.
kubernetes는 그리스어에서 유래되었으며 조타수(helmsman) 또는 파일럿(pilot)을 의미한다.
k와 s 사이의 글자가 8개여서 줄여서 k8s라고 부른다.
