My IBM 로그인 구독하기

Kubernetes의 역사

2023년 11월 2일

7분 분량

최신 IT 인프라와 관련하여 컨테이너화된 소프트웨어 애플리케이션(앱) 및 서비스의 배포, 관리 및 확장을 자동화하는 오픈 소스 컨테이너 오케스트레이션 플랫폼인 Kubernetes의 역할은 과소평가할 수 없습니다.

클라우드 네이티브 컴퓨팅 재단(CNCF) 보고서에 따르면(ibm.com 외부 링크), Kubernetes는 Linux에 이어 세계에서 두 번째로 큰 오픈 소스 프로젝트이며, Fortune 100대 기업 중 71%가 사용하는 기본 컨테이너 오케스트레이션 툴이라고 합니다. Kubernetes가 어떻게 클라우드 컴퓨팅마이크로서비스 시장을 장악하게 되었는지 이해하려면 Kubernetes의 역사를 살펴봐야 합니다.

Kubernetes의 진화

고대 그리스어로 '조종사' 또는 '조타수'(배를 조종하는 사람)를 뜻하는 Kubernetes의 역사는 2013년 Google의 엔지니어 3인방인 Craig McLuckie, Joe Beda, Brendan Burns가 오픈소스 컨테이너 관리 시스템을 구축하자는 아이디어를 내놓은 때로 거슬러 올라갑니다. 이 기술 선구자들은 Google의 내부 인프라 전문 지식을 대규모 클라우드 컴퓨팅 영역에 도입하고 Google이 당시 클라우드 제공업체 중 타의 추종을 불허하는 선두 주자인 Amazon Web Services(AWS)와 경쟁하도록 지원할 방법을 찾고 있었습니다.

기존 IT 인프라와 가상 IT 인프라 비교

 

하지만 '숫자 기반 단어'(ibm.com 외부 링크)인 “Kube” 또는 “K8s”라고도 하는 Kubernetes의 역사를 제대로 이해하려면 기존 IT 인프라와 가상 IT 인프라의 관점에서 컨테이너를 살펴봐야 합니다.

과거에는 조직이 물리적 서버(Bare Metal Servers라고도 함)에서만 앱을 실행했습니다. 하지만 이러한 앱의 시스템 리소스 경계를 유지할 방법이 없었습니다. 예를 들어, 물리적 서버가 여러 애플리케이션을 실행할 때마다 하나의 애플리케이션이 해당 서버의 모든 처리 능력, 메모리, 저장 공간 또는 기타 리소스를 소모할 수 있습니다. 이러한 일이 발생하지 않도록 기업은 각 애플리케이션을 서로 다른 물리적 서버에서 실행합니다. 그러나 여러 서버에서 앱을 실행하면 활용도가 낮은 리소스가 발생하고 확장할 수 없는 문제가 발생합니다. 게다가 많은 수의 물리적 머신을 보유하면 공간을 많이 차지하고 비용이 많이 듭니다.

가상화

 

그런 다음 클라우드 컴퓨팅의 기반을 형성하는 프로세스인 가상화가등장했습니다. 가상화 기술의 역사는 1960년대 후반으로 거슬러 올라갈 수 있지만 2000년대 초반까지는 널리 채택되지 않았습니다.

가상화는 하이퍼바이저라고 알려진 소프트웨어에 의존합니다. 하이퍼바이저는 여러 가상 머신(VM)이 단일 물리적 서버의 중앙 처리 장치(CPU)에서 실행될 수 있도록 하는 가벼운 소프트웨어 형태입니다. 각 가상 머신에는 게스트 운영 체제(OS)가 있으며, OS를 실행하는 데 필요한 하드웨어의 가상 복사본과 함께 애플리케이션 및 관련 라이브러리 및 종속성이 있습니다. 

VM은 물리적 서버보다 하드웨어 리소스를 더 효율적으로 사용하여 앱을 실행하지만 여전히 많은 양의 시스템 리소스를 차지합니다. 특히 동일한 물리적 서버에서 각각 고유한 게스트 운영 체제를 사용하는 수많은 가상 머신이 실행되는 경우에 특히 그렇습니다.

컨테이너

 

컨테이너 기술을 도입하세요. 컨테이너 개발의 역사적 마일스톤은 1979년 Unix 버전 7 운영 체제의 일부인 chroot(ibm.com 외부 링크)의 개발과 함께 이루어졌습니다. Chroot는 애플리케이션의 파일 액세스를 특정 디렉터리(루트)와 그 하위 프로세스(또는 하위 프로세스)로 제한하여 프로세스 격리라는 개념을 도입했습니다.

현대의 컨테이너는 애플리케이션 코드가 모든 라이브러리 및 종속성과 함께 패키징되는 소프트웨어 단위로 정의됩니다. 이를 통해 데스크톱, 프라이빗 데이터 센터 또는 퍼블릭 클라우드의 온프레미스 또는 오프프레미스 등 모든 환경에서 애플리케이션을 빠르게 실행할 수 있습니다.

컨테이너는 VM과 같이 기본 하드웨어를 가상화하는 대신 일반적으로 Linux 또는 Windows와 같은 운영 체제를 가상화합니다. 게스트 OS가 없기 때문에 컨테이너는 VM보다 가볍고 빠르며 이식성이 뛰어납니다.

Borg: Kubernetes의 전신

2000년대 초반, Google은 성장하는 인프라를 지원하고 퍼블릭 클라우드 플랫폼을 제공하기 위해 가상 서버의 성능을 극대화할 방법이 필요했습니다. 이로 인해 최초의 통합 컨테이너 관리 시스템인 Borg가 탄생했습니다. 2003년부터 2004년에 개발된 Borg 시스템은 스타트렉의 외계인 그룹인 Borg의 이름을 딴 것으로, 이는 '집단'이라는 집단 의식(집단 마인드)을 공유하여 기능하는 사이버네틱 유기체입니다.

Borg라는 이름은 Google 프로젝트에 잘 맞았습니다. Borg의 대규모 클러스터 관리 시스템은 기본적으로 데이터 센터 전반에서 컨테이너화된 워크로드를 실행하기 위한 중심 두뇌 역할을 합니다. Google의 검색 엔진과 함께 실행되도록 설계된 Borg는 Gmail, Google Docs, Google Search, Google Maps 및 YouTube를 포함한 Google의 인터넷 서비스를 구축하는 데 사용되었습니다.

Borg를 통해 Google은 여러 시스템에서 다양한 애플리케이션을 통해 수십만 개의 작업을 실행할 수 있었습니다. 이를 통해 Google은 대규모 워크로드에 대한 높은 리소스 활용도, 내결함성 및 확장성을 달성할 수 있었습니다. Borg는 오늘날에도 Google의 주요 내부 컨테이너 관리 시스템으로 사용되고 있습니다.

2013년 Google은 2세대 컨테이너 관리 시스템인 Omega를 출시했습니다. Omega는 Borg 에코시스템을 한 단계 더 발전시켜 대규모 컴퓨터 클러스터를 위한 유연하고 확장 가능한 스케줄링 솔루션을 제공했습니다. 2013년에는 Kubernetes 역사에서 핵심적인 역할을 한 Docker가 등장했습니다.

오픈 소스 컨테이너화를 선도하는 Docker

서비스형 플랫폼(PaaS) 기술 회사인 dotCloud에서 개발한 Docker는 온라인 소프트웨어 개발자가 컨테이너화된 애플리케이션을 구축, 배포 및 관리할 수 있는 오픈 소스 소프트웨어 도구로 2013년에 출시되었습니다.

Docker 컨테이너 기술은 Linux 커널(운영 체제의 기본 구성 요소)과 커널 기능을 사용하여 프로세스를 분리하여 독립적으로 실행할 수 있도록 합니다. 혼동을 피하기 위해 설명하자면, Docker라는 이름은 오픈 소스 컨테이너화 플랫폼을 기반으로 구축된 생산성 도구를 개발하는 Docker, Inc.(구 dotCloud, ibm.com 외부 링크)와 Docker 오픈 소스 에코시스템 및 커뮤니티(ibm.com 외부 링크)를 가리키기도 합니다.

경량 컨테이너 런타임을 대중화하고 애플리케이션을 머신에 패키징, 배포 및 배포하는 간단한 방법을 제공함으로써 Docker는 Kubernetes 설립자에게 씨앗 또는 영감을 제공했습니다. Docker가 등장했을 때 Google 직원인 Craig McLuckie, Joe Beda, Brendan Burns는 개별 컨테이너를 구축하고 개별 머신에서 실행할 수 있는 Docker의 기능에 흥분했습니다.

Docker는 클라우드 네이티브 인프라의 판도를 바꿨지만, 단일 노드에서 실행되도록 구축되었기 때문에 자동화가 불가능하다는 한계가 있었습니다. 예를 들어, 앱이 수천 개의 개별 컨테이너용으로 구축되었기 때문에 다양한 환경에서 앱을 관리하는 것은 개별 개발마다 수동으로 패키징해야 하는 어려운 작업이 되었습니다. Google 팀은 여러 머신에 여러 컨테이너를 배포하고 관리할 수 있는 컨테이너 오케스트레이터의 필요성과 기회를 발견했습니다. 이렇게 해서 Google의 3세대 컨테이너 관리 시스템인 Kubernetes가 탄생했습니다.

Kubernetes의 탄생

Kubernetes 개발자 중 다수는 Borg 개발에 참여했으며, Borg 및 Omega 시스템의 설계 및 개발을 통해 배운 모든 것을 통합하여 사용자 친화적인 인터페이스(UI)를 갖춘 덜 복잡한 오픈 소스 툴을 제작하는 컨테이너 오케스트레이터를 구축하고자 했습니다. 이들은 Borg에 대한 경의를 표하기 위해 Borg의 드론이었던 스타트렉: 보이저 캐릭터의 이름을 따서 이를 프로젝트 세븐 오브 나인(Project Seven of Nine)으로 명명했습니다. 원래 프로젝트 이름은 그대로 유지되지는 않았지만, Kubernetes 로고의 7개의 점으로 이를 기념했습니다(ibm.com 외부 링크).

Kubernetes 클러스터 내부

Kubernetes 아키텍처는 여러 머신과 환경에서 컨테이너를 실행할 수 있도록 하는 실행 클러스터를 기반으로 구축됩니다. 각 클러스터는 일반적으로 다음과 같은 두 가지 클래스의 노드로 구성됩니다.

  • 컨테이너화된 애플리케이션을 실행하는 워커 노드.
  • 클러스터를 제어하는 컨트롤 플레인 노드.

컨트롤 플레인은 기본적으로 Kubernetes 클러스터의 오케스트레이터 역할을 하며 API 서버(Kubernetes와의 모든 상호 작용을 관리), 제어 관리자(모든 제어 프로세스 처리), 클라우드 컨트롤러 관리자(클라우드 공급자의 API와의 인터페이스) 등 여러 구성 요소를 포함합니다. 워커 노드는 Docker와 같은 컨테이너 런타임을 사용하여 컨테이너를 실행합니다. 클러스터에서 배포 가능한 가장 작은 단위인 파드는 하나 이상의 앱 컨테이너를 보유하고 스토리지 및 네트워킹 정보와 같은 리소스를 공유합니다.

Kubernetes 공개

2014년에 Kubernetes는 Borg의 오픈 소스 버전으로 데뷔했으며, Microsoft, RedHat, IBM, Docker가 Kubernetes 커뮤니티의 초기 멤버로 합류했습니다. 이 소프트웨어 툴에는 다음과 같은 컨테이너 오케스트레이션을 위한 기본 기능이 포함되어 있습니다.

  • 애플리케이션의 여러 인스턴스를 배포하기 위한 복제
  • 로드 밸런싱 및 서비스 검색
  • 기본 상태 확인 및 복구
  • 여러 머신을 함께 그룹화하고 작업을 분배하기 위한 스케줄링

2015년, O'Reilly 오픈소스 컨벤션(OSCON)(ibm.com 외부 링크)에서 Kubernetes 창립자들은 Kubernetes의 확장되고 개선된 버전인 Kubernetes 1.0을 공개했습니다. 얼마 지나지 않아 Red Hat OpenShift 팀의 개발자들이 Google 팀에 합류하여 프로젝트에 엔지니어링 및 엔터프라이즈 경험을 제공했습니다.

Kubernetes와 클라우드 네이티브 컴퓨팅 재단의 역사

Google은 2015년 Kubernetes 1.0 출시와 동시에 비영리 단체인 Linux Foundation의 일부인 클라우드 네이티브 컴퓨팅 재단(CNCF)(ibm.com 외부 링크)에 Kubernetes를 기증했습니다. CNCF는 Docker, Google, Microsoft, IBM 및 Red Hat을 포함한 세계 유수의 컴퓨팅 회사의 수많은 구성원이 공동으로 설립했습니다. CNCF의 사명(ibm.com 외부 링크)은 "클라우드 네이티브 컴퓨팅을 보편화하는 것"입니다.

2016년에 Kubernetes는 CNCF의 첫 번째 호스팅 프로젝트가 되었으며, 2018년에는 Kubernetes가 CNCF의 첫 번째 프로젝트가 되었습니다. 적극적으로 기여하는 기업의 수는 700개 이상으로 빠르게 증가했고, Kubernetes는 역사상 가장 빠르게 성장하는 오픈 소스 프로젝트 중 하나가 되었습니다. 2017년에는 Docker Swarm과 Apache Mesos와 같은 경쟁사를 앞지르며 컨테이너 오케스트레이션의 업계 표준이 되었습니다.

Kubernetes 및 클라우드 네이티브 애플리케이션

클라우드 이전에는 소프트웨어 애플리케이션이 실행 중인 하드웨어 서버에 연결되어 있었습니다. 하지만 2018년에 Kubernetes와 컨테이너가 클라우드 벤딩 조직의 관리 표준이 되면서 클라우드 네이티브 애플리케이션이라는 개념이 자리를 잡기 시작했습니다. 이를 통해 클라우드 기반 소프트웨어의 연구 개발을 위한 관문이 열렸습니다.

Kubernetes는 클라우드 네이티브 마이크로서비스 기반 프로그램 개발을 지원하고 기존 애플리케이션의 컨테이너화를 허용하여 더 빠른 애플리케이션 개발을 가능하게 합니다. 또한 Kubernetes는 여러 애플리케이션을 동시에 효율적으로 관리하는 데 필요한 자동화 및 관측 가능성을 제공합니다. Kubernetes의 선언적 API기반 인프라는 클라우드 기반 개발팀이 독립적으로 운영하고 생산성을 높일 수 있도록 해줍니다.

Kubernetes의 지속적인 영향

Kubernetes의 역사와 컨테이너화된 워크로드 및 마이크로서비스를 관리하기 위한 이식 가능하고 확장 가능한 오픈 소스 플랫폼으로서의 역할은 계속해서 발전하고 있습니다.

Kubernetes가 2016년에 CNCF에 가입한 이후 기여자 수는 8,012명으로 늘어났습니다. 이는 996% 증가한 수치입니다(ibm.com 외부 링크). CNCF의 대표적인 글로벌 컨퍼런스인 KubeCon + CloudNativeCon(ibm.com 외부 링크)은 수천 명의 참석자를 유치하고 Kubernetes 및 기타 DevOps 트렌드에 대한 개발자 및 사용자의 정보와 인사이트를 제공하는 연례 포럼을 개최합니다.

클라우드 전환 및 애플리케이션 현대화 측면에서 Kubernetes의 도입은 둔화될 조짐이 보이지 않습니다. Gartner의 보고서인 컨테이너 및 Kubernetes에 대한 CTO 가이드(ibm.com 외부 링크)에 따르면, 2027년까지 전 세계 조직의 90% 이상이 컨테이너화된 애플리케이션을 운영 환경에서 실행할 것으로 예상된다고 합니다.

IBM 및 Kubernetes

2014년, IBM은 Kubernetes 오픈 소스 커뮤니티와 힘을 합쳐 컨테이너 오케스트레이션을 엔터프라이즈에 도입한 최초의 주요 기업 중 하나였습니다. 오늘날 IBM은 Kubernetes 컨테이너 오케스트레이션과 기타 클라우드 기반 관리 솔루션을 구현하여 기업이 진행 중인 클라우드 여정을 탐색할 수 있도록 돕고 있습니다.

클라우드 네이티브 애플리케이션 개발, 대규모 앱 배포 또는 마이크로서비스 관리 등 목표가 무엇이든, Kubernetes와 그 다양한 사용 사례를 활용할 수 있도록 도와드릴 수 있습니다.

Red Hat OpenShift on IBM Cloud는 OpenShift 개발자가 Kubernetes 클러스터에서 엔터프라이즈 워크로드를 컨테이너화하고 배포할 수 있는 빠르고 안전한 방법을 제공합니다.

완전 관리형 서버리스 플랫폼인 IBM Cloud Code Engine을 사용하면 완전 관리형 컨테이너 런타임에서 컨테이너, 애플리케이션 코드 또는 일괄처리 작업을 실행할 수 있습니다.

 

작가