제퍼넷 로고

Kubernetes의 역사 - IBM 블로그

시간

Kubernetes의 역사 - IBM 블로그




현대 건축

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

A에 따라 클라우드 네이티브 컴퓨팅 재단(CNCF) 보고서 (링크는 ibm.com 외부에 있음), Kubernetes는 두 번째로 큰 규모입니다. 오픈 소스 Linux 이후 세계에서 가장 인기 있는 프로젝트이자 Fortune 71대 기업 중 100%를 위한 기본 컨테이너 오케스트레이션 도구입니다. Kubernetes가 어떻게 업계를 지배하게 되었는지 이해하려면 클라우드 컴퓨팅마이크로 서비스 시장에서 우리는 그 역사를 조사해야 합니다.

쿠버네티스의 진화

"조종사" 또는 "조타수"(배를 조종하는 사람)를 뜻하는 고대 그리스어에서 이름이 유래된 Kubernetes의 역사는 Google의 엔지니어 2013인조(Craig McLuckie, Joe Beda, Brendan)가 XNUMX년에 설립한 때로 거슬러 올라갑니다. Burns—오픈 소스 컨테이너 관리 시스템을 구축하기 위한 아이디어를 제시했습니다. 이러한 기술 선구자들은 Google의 내부 인프라 전문 지식을 대규모 클라우드 컴퓨팅 영역으로 가져오고 Google이 당시 클라우드 제공업체 중 독보적인 리더였던 Amazon Web Services(AWS)와 경쟁할 수 있도록 하는 방법을 찾고 있었습니다.

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

하지만 "Kube" 또는 "K8s"라고도 불리는 Kubernetes의 역사를 진정으로 이해하려면 "숫자의” (ibm.com 외부 링크) - 우리는 기존 IT 인프라와 가상 IT 인프라의 맥락에서 컨테이너를 살펴봐야 합니다.

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

가상화

그럼 왔어. 가상화—클라우드 컴퓨팅의 기반을 형성하는 프로세스입니다. 가상화 기술은 1960년대 후반으로 거슬러 올라가지만 2000년대 초반까지는 널리 채택되지 않았습니다.

가상화는 다음과 같은 소프트웨어에 의존합니다. 하이퍼 바이저. 하이퍼바이저는 다양한 기능을 제공하는 경량 형태의 소프트웨어입니다. 가상 머신(VM) 단일 물리적 서버의 중앙 처리 장치(CPU)에서 실행됩니다. 각 가상 머신에는 게스트 운영 체제(OS), OS에서 실행하는 데 필요한 하드웨어의 가상 복사본, 애플리케이션, 관련 라이브러리 및 종속성이 있습니다. 

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

용기

엔터 버튼 컨테이너 기술. 컨테이너 개발의 역사적인 이정표는 1979년에 다음이 개발되면서 발생했습니다. chroot (링크는 ibm.com 외부에 있음), Unix 버전 7 운영 체제의 일부입니다. Chroot는 애플리케이션의 파일 액세스를 특정 디렉터리(루트)와 해당 하위 프로세스(또는 하위 프로세스)로 제한하여 프로세스 격리 개념을 도입했습니다.

최신 컨테이너는 애플리케이션 코드가 모든 라이브러리 및 종속성과 함께 패키지되는 소프트웨어 단위로 정의됩니다. 이를 통해 애플리케이션은 온프레미스든 오프프레미스든 상관없이 모든 환경에서 데스크탑, 개인 컴퓨터를 통해 빠르게 실행될 수 있습니다. 데이터 센터 또는 퍼블릭 클라우드.

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

Borg: Kubernetes의 전신

2000년대 초, Google은 최고의 성능을 얻을 수 있는 방법이 필요했습니다. 가상 서버 성장하는 인프라를 지원하고 퍼블릭 클라우드 플랫폼을 제공합니다. 이로 인해 최초의 통합 컨테이너 관리 시스템인 Borg가 탄생하게 되었습니다. 2003년에서 2004년 사이에 개발된 Borg 시스템은 다음 그룹의 이름을 따서 명명되었습니다. 스타 트렉 외계인(보그)은 "The Collective"라고 불리는 하이브 마인드(집단 의식)를 공유하여 기능하는 사이버네틱 유기체입니다.

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

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

2013년 Google은 2013세대 컨테이너 관리 시스템인 Omega를 출시했습니다. Omega는 Borg 생태계를 더욱 발전시켜 대규모 컴퓨터 클러스터를 위한 유연하고 확장 가능한 일정 관리 솔루션을 제공했습니다. Kubernetes 역사상 핵심 플레이어인 Docker가 등장한 것도 XNUMX년이었습니다.

Docker는 오픈 소스 컨테이너화를 안내합니다.

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

Docker 컨테이너 기술은 Linux 커널(운영 체제의 기본 구성 요소)과 커널 기능을 사용하여 프로세스를 분리하여 독립적으로 실행할 수 있도록 합니다. 혼란을 없애기 위해 Docker 이름은 다음을 참조합니다. 도커, Inc. (이전의 dotCloud, 링크는 ibm.com 외부에 있음)는 오픈 소스 컨테이너화 플랫폼을 기반으로 구축된 생산성 도구를 개발합니다. Docker 오픈소스 생태계 및 커뮤니티 (링크는 ibm.com 외부에 있습니다).

Docker는 경량 컨테이너 런타임을 대중화하고 애플리케이션을 시스템에 패키징, 배포 및 배포하는 간단한 방법을 제공함으로써 Kubernetes 창립자들에게 ​​씨앗이나 영감을 제공했습니다. Docker가 등장했을 때 Google 직원 Craig McLuckie, Joe Beda, Brendan Burns는 개별 컨테이너를 구축하고 이를 개별 시스템에서 실행하는 Docker의 능력에 흥미를 느꼈습니다.

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

Kubernetes와 Docker의 차이점과 유사점에 대해 자세히 알아보세요.

쿠버네티스의 탄생

많은 Kubernetes 개발자는 Borg를 개발하기 위해 노력했으며 Borg 및 Omega 시스템의 설계 및 개발을 통해 배운 모든 것을 통합하여 사용자 친화적인 인터페이스로 덜 복잡한 오픈 소스 도구를 생성하는 컨테이너 오케스트레이터를 구축하기를 원했습니다. (UI). Borg에 대한 찬사로 그들은 프로젝트 이름을 Project Seven of Nine으로 명명했습니다. 스타 트렉 : 보이저 전직 보그 드론이었던 캐릭터. 원래 프로젝트 이름은 붙지 않았지만 Kubernetes의 XNUMX가지 포인트로 기념되었습니다. 심벌 마크 (링크는 ibm.com 외부에 있습니다).

Kubernetes 클러스터 내부

Kubernetes 아키텍처는 컨테이너가 여러 시스템과 환경에서 실행될 수 있도록 하는 실행 중인 클러스터를 기반으로 합니다. 각 클러스터는 일반적으로 두 가지 클래스의 노드로 구성됩니다.

  • 작업자 노드, 컨테이너화된 애플리케이션을 실행합니다.
  • 제어 영역 노드, 클러스터를 제어합니다.

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

Kubernetes 클러스터 작동 방식에 대해 자세히 알아보세요.

쿠버네티스 공개

2014년에 Kubernetes는 Borg의 오픈 소스 버전으로 데뷔했으며 Microsoft, RedHat, IBM 및 Docker가 Kubernetes 커뮤니티의 초기 구성원으로 서명했습니다. 소프트웨어 도구에는 다음을 포함하여 컨테이너 오케스트레이션을 위한 기본 기능이 포함되어 있습니다.

  • 애플리케이션의 여러 인스턴스를 배포하기 위한 복제
  • 로드 밸런싱 및 서비스 검색
  • 기본적인 건강검진 및 수리
  • 여러 시스템을 그룹화하고 작업을 분배하도록 예약

2015년에는 오라일리 오픈소스 컨벤션(OSCON) (ibm.com 외부 링크) Kubernetes 창립자들은 Kubernetes의 확장되고 개선된 버전인 Kubernetes 1.0을 공개했습니다. 얼마 지나지 않아 Red Hat® OpenShift® 팀의 개발자가 Google 팀에 합류하여 엔지니어링 및 기업 경험을 프로젝트에 활용했습니다.

Kubernetes와 Cloud Native Computing Foundation의 역사

1.0년 Kubernetes 2015 출시와 동시에 Google은 Kubernetes를 클라우드 네이티브 컴퓨팅 재단 (CNCF)(ibm.com 외부 링크), 비영리 Linux 재단의 일부입니다. CNCF는 Docker, Google, Microsoft, IBM 및 Red Hat을 포함한 세계 최고의 컴퓨팅 회사의 수많은 구성원이 공동으로 만들었습니다. 그만큼 사명 (ibm.com 외부 링크) CNCF의 목표는 "클라우드 네이티브 컴퓨팅을 유비쿼터스화하는 것"입니다.

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

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

클라우드 이전에는 소프트웨어 애플리케이션이 실행 중인 하드웨어 서버에 묶여 있었습니다. 하지만 2018년에 쿠버네티스와 컨테이너가 클라우드 판매 조직의 관리 표준이 되면서 클라우드 네이티브 신청서가 접수되기 시작했습니다. 이는 클라우드 기반 소프트웨어 연구 및 개발을 위한 관문을 열었습니다.

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

Kubernetes의 지속적인 영향

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

Kubernetes가 2016년에 CNCF에 가입한 이후 기여자 수는 8,012명으로 996% 증가 (링크는 ibm.com 외부에 있습니다). CNCF의 대표적인 글로벌 컨퍼런스, KubeCon + CloudNativeCon (ibm.com 외부 링크), 수천 명의 참석자를 유치하고 Kubernetes 및 기타 분야에 대한 개발자와 사용자의 정보와 통찰력을 위한 연례 포럼 개발자 동향.

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

IBM과 쿠버네티스

2014년에 IBM은 Kubernetes 오픈 소스 커뮤니티와 힘을 합쳐 컨테이너 오케스트레이션을 기업에 도입한 최초의 주요 기업 중 하나였습니다. 현재 IBM은 Kubernetes 컨테이너 오케스트레이션 및 기타 클라우드 기반 관리 솔루션을 구현하여 기업이 지속적인 클라우드 여정을 탐색할 수 있도록 지원하고 있습니다.

귀하의 목표가 클라우드 네이티브 애플리케이션 개발, 대규모 앱 배포 또는 마이크로서비스 관리인지 여부에 관계없이 Kubernetes와 그 다양한 사용 사례를 활용하는 데 도움을 드릴 수 있습니다.

IBM Cloud® Kubernetes Service 시작하기

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

IBM Cloud에서 Red Hat OpenShift 살펴보기

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

IBM Cloud Code Engine에 대해 자세히 알아보기

클라우드에서 더 보기

전자 설계 자동화(EDA) 워크로드를 위해 IBM Cloud 활용

4 분 읽기 - 전자 설계 자동화(EDA)는 반도체 장치(또는 칩)의 정의, 계획, 설계, 구현, 검증 및 후속 제조를 지원하는 것을 목표로 하는 소프트웨어, 하드웨어 및 서비스로 구성된 시장 부문입니다. 이 서비스의 주요 제공업체는 반도체 파운드리 또는 제조공장입니다. EDA 솔루션은 칩 제조에 직접적으로 관여하지는 않지만 세 가지 측면에서 중요한 역할을 합니다. EDA 도구는 반도체 제조 프로세스를 설계하고 검증하는 데 사용됩니다.

IBM Tech Now: 30년 2023월 XNUMX일

<1 분 읽기 - 기술 세계의 가장 뛰어난 최신 뉴스와 발표를 소개하는 비디오 웹 시리즈인 IBM Tech Now에 오신 것을 환영합니다. 새로운 IBM Tech Now 비디오가 게시될 때마다 알림을 받으려면 YouTube 채널을 구독하세요. IBM Tech Now: 에피소드 88 이 에피소드에서는 다음 주제를 다룹니다. IBM과 Equinix 간의 기술 협업 백악관 사이버 보안 계획 구현 IBM Security QRadar SIEM이 Cybersecurity Breakthrough Awards의 “SIEM…

Apptio Cloudability 및 IBM Turbonomic을 사용하여 FinOps 운영 및 자동화

2 분 읽기 - 전통적인 기업부터 가장 혁신적인 스타트업까지, 조직은 퍼블릭 클라우드를 사용하고 있습니다. 실제로 ESG Research는 모든 애플리케이션의 91%가 결국 퍼블릭 클라우드에서 호스팅될 것이라는 사실을 발견했습니다. 그만큼 많은 투자로 인해 클라우드의 가변적인 소비 기반 지출 모델에 재정적 책임을 부여하도록 설계된 클라우드 재무 관리 원칙인 FinOps 운동이 필요해졌습니다. 우리는 숙련된 FinOps 실무자가 클라우드 비용 관리에서 "가능한 것"의 경계를 넓히고 고급 지원을 위해 로비하는 것을 확인했습니다.

IBM Cloud Databases for Redis는 6년 25월 2024일에 버전 XNUMX의 수명 종료를 발표합니다.

<1 분 읽기 - 25년 2024월 6.0일 이후에는 아직 활성 상태인 버전 6.2의 모든 IBM Cloud Databases for Redis 인스턴스가 Redis 버전 6.2로 업그레이드됩니다. 이는 당사의 데이터베이스 버전 관리 정책에 따라 수행됩니다. 다음 단계 사용자는 버전 6의 EOL 날짜 이전에 백업 및 복원 프로세스를 사용하여 IBM Cloud Database for Redis 인스턴스를 버전 XNUMX로 업그레이드해야 합니다. 다음과 같은 이유로 전체 업그레이드를 기다리지 않는 것이 좋습니다. : 우리가 제공하다…

IBM 뉴스레터

새로운 트렌드에 대한 최신 사고 리더십과 통찰력을 제공하는 뉴스레터와 주제 업데이트를 받아보세요.

지금 구독하세요 더 많은 뉴스레터

spot_img

최신 인텔리전스

spot_img