쿠버네티스란 무엇인가요? 귀하의 비즈니스가 알아야 할 모든 것

쿠버네티스란 무엇인가요?

Kubernetes의 정의는 계속해서 변합니다. Kubernetes가 계속 성장함에 따라 주변 세계도 변화시키기 때문입니다. 2019년 가을 버전은 다음과 같습니다. Kubernetes는 작업 부하 분산 및 조정 메커니즘 데이터 센터의 클러스터된 서버를 위해 리소스 가용성, 접근성 및 여러 서비스에 대한 균형 잡힌 실행을 동시에 보장합니다.

이 체계에서 Kubernetes는 거리에 관계없이 동시에 여러 종류의 서버가 공통 테넌트에 대한 작업 부하를 공유할 수 있도록 합니다. 그런 다음 해당 워크로드를 클라이언트에 서비스로 제공합니다. 즉, 클라이언트 시스템이 클라이언트에 연결할 수 있음을 의미합니다. 네트워크를 통해 일부 데이터를 그들에게 전달하고 잠시 기다린 후 응답.

이는 단일 공간 내에서 수행되던 분산 데이터 처리입니다. 모놀리식 애플리케이션. Kubernetes는 이 전체 프로세스를 관찰 가능성과 관리 가능성에 노출합니다.

이러한 서비스를 관리할 때 Kubernetes는 필요에 따라 네트워크 레이아웃을 변경합니다. 더 많은 클라이언트가 특정 유형 또는 클래스의 워크로드를 요청하면 오케스트레이터는 해당 워크로드의 복제본을 더 많이 만듭니다. 마찬가지로 요청이 줄어들면 복제본 수가 줄어듭니다. 이것이 Kubernetes를 유명하게 만든 프로세스이며, IT 운영자는 이를 각각 확장 및 축소라고 부릅니다. 서비스가 세분화되는 경우 개별 기능 또는 마이크로서비스, 공유하는 메모리와 프로세서 대신 네트워크를 통해 서로 접촉하는 Kubernetes는 다음을 수행할 수 있습니다. 마치 완전한 것처럼 개별 마이크로서비스를 확장하고 수요 증가 및 감소에 따라 축소합니다. 응용 프로그램.

Kubernetes의 비즈니스 사례

우리 사업, 상거래 시스템, 그리고 우리 사회의 상당 부분을 구축하는 정보 기술 플랫폼이 노후화되고 있습니다. 이를 교체하는 것은 비용보다 이익이 더 큰 문제입니다. 처럼 5G 무선 전환에 어려움을 겪고 있는 모든 통신 서비스 제공업체 입증하겠지만, 단기 비즈니스 모델이 수익성을 거의 보장하지 않는 한 조직이 전체 인프라 교체 비용을 정당화하는 것은 어렵습니다.

Kubernetes는 비즈니스 수익성을 주장할 뿐만 아니라 이를 입증하기 위해 몇 가지 테스트 사례를 준비하고 있습니다. 이에 찬성하는 것은 오늘날 조직이 기존 인프라를 유지하기 위해 지불하는 비용이 계속 증가하고 있으며 점점 더 정당성이 떨어지고 있다는 증거가 점점 늘어나고 있다는 것입니다.

• 클라우드는 1세대 가상화를 기반으로 합니다., 이는 더 이상 사용되지 않으며 아마도 관련성이 없을 수도 있습니다. 일반적으로 서버의 기본 하드 드라이브에 설치되는 소프트웨어 이미지는 다음과 같습니다. 원격 서버의 메모리와 저장소에 렌더링되어 소프트웨어가 항상 그랬던 것처럼 그곳에서 실행될 수 있습니다. 전에. 이제 이전처럼 소프트웨어를 실행하도록 만들 필요가 없습니다. 모놀리식 애플리케이션을 계속해서 생산해야 하는 비즈니스 사례는 사라졌습니다. 대규모 멀티플레이어 온라인 게임기본 독점 플랫폼은 제조업체의 독점 도메인입니다.
• 인터넷은 도메인 시스템을 사용하여 매핑됩니다. 사용되는 기능과 서비스가 아닌 등록된 소유자에게 주소를 매핑하는 것입니다. 서비스 메시 이러한 지도를 보다 관련성이 높은 지도와 오버레이하여 분산 애플리케이션이 광범위하게 분산된 네트워크에서 서로를 찾을 수 있도록 합니다. 그리고 이러한 서비스 메시는 Kubernetes에 긴밀하게 바인딩되어 워크로드 조정 다음으로 시스템에서 두 번째로 관련성이 높은 서비스를 제공합니다.
• 모바일 장치는 모바일 앱에 의존합니다. 주로 클라이언트와 서버 간에 교환되는 정보를 최소화하기 위해 "스마트" 기능을 클라이언트 측에 배포합니다. 무선 대역폭이 더 이상 프리미엄 상품이 아니기 때문에 해당 기능을 다시 서버측으로 전환하여 새로운 기능을 구현하는 것이 더 실용적이고 비용 효율적이 될 수 있습니다. 비록 정말 훌륭한 카메라를 탑재했음에도 불구하고 이전 제품보다 상당히 "멍청"하지만 상상할 수 없을 정도로 더 뛰어난 성능으로 동일한 작업을 수행하는 장치 종류입니다. 속도.
• 퍼블릭 클라우드 데이터센터는 대규모 "하이퍼스케일" 시설 이는 수만 명의 임차인에게 동시에, 때로는 수백 마일 떨어진 곳에서 서비스를 제공합니다. 컴퓨팅의 분산성이 더욱 높아짐에 따라 더 많은 수의 훨씬 작은 데이터 센터를 사용자에게 더 가까운 곳에 분산시키는 것이 더 실용적이고 더 바람직해질 수 있습니다.
• 인공 지능은 소프트웨어의 상위 클래스로 구성됩니다., 주로 상대적으로 인해 메모리, 스토리지 및 기타 리소스의 높은 비용. 각각 훨씬 작은 공간을 차지하는 수많은 컨테이너로 구성된 분산 서비스 모델을 사용하면 AI가 훨씬 더 보편화될 수 있습니다. 더 나은 추론을 이끌어내는 소프트웨어(예: "30야드 떨어져 있는 저 나무를 조심하세요!")는 "표준 작동"이라고 불리는 만큼 "스마트"라고 불리지 않습니다. 장비."
• 컨테이너화를 사용하면 비즈니스 소프트웨어를 더 쉽게 관리할 수 있습니다. 서버 기반 컴퓨팅의 맥락에서 컨테이너는 워크로드를 가상화할 수 있는 패키지입니다. (휴대 가능하고, 독립적이며, 격리되어 실행됨) 여전히 운영 체제에 의해 호스팅되는 동안(예: 하이퍼바이저). 최신 애플리케이션은 컨테이너화를 통해 서버 간에 이식 가능하며, 이는 단지 배포를 패키징하는 것이 아닙니다. 컨테이너화된 환경에서는 소프트웨어 코드가 리포지토리(일부는 공개, 일부는 비공개)에서 검색되거나 "가져온" 후 즉시 배포되어 프로덕션 환경에서 실행됩니다. 이 자동화된 배포 방법을 사용하면 소프트웨어를 18개월마다뿐만 아니라 창시자뿐만 아니라 사용자도 매일 개선할 수 있습니다. 결과적으로 이는 데이터 센터 시스템 무결성과 보안을 획기적으로 향상시킵니다.

"오케스트레이션"의 의미

오케스트레이션은 IT 플랫폼에 공존하는 여러 워크로드를 효과적으로 관리하고 실행하는 것입니다. Kubernetes의 경우 특정 워크로드가 이미 마이크로서비스로 세분화된 플랫폼에 도착할 수 있습니다. 그들은 여전히 ​​함께 일하지만 독립적인 단위입니다. Kubernetes 오케스트레이션을 사용하면 해당 단위를 필요에 따라 늘리고 재배포할 수 있으며 더 이상 사용하지 않을 때 단계적으로 제거할 수 있습니다.

오케스트라 지휘자처럼요?

잘못된 비유입니다. 지휘자는 곡이 적절한 시간과 리듬에 맞춰 연주되도록 합니다. 데이터 센터에서는 운영 체제가 계속해서 그 역할을 수행합니다. Kubernetes는 이를 변경하지 않습니다. 오케스트레이터는 최대의 효율성과 원활한 진행을 위해 컴포지션의 모든 부분 실행을 조정합니다. 한 부분이 다른 부분을 압도할 수 없으며 모든 부분이 각자의 역할을 수행합니다. 효과적으로. 이러한 부분은 여러 위치에 광범위하게 분산될 수 있으므로 오케스트레이터는 해당 부분이 현재 동일한 작업에 기여하는 데 필요할 수 있는 모든 리소스를 모으기도 합니다.

운영 체제와 오케스트레이터 비교

무엇보다도 컴퓨터의 운영 체제는 프로그램이 프로세서에 의해 예상대로 안전하게 실행될 수 있도록 해줍니다. Kubernetes는 클러스터의 여러 서버에 분산된 여러 워크로드에 대한 역할을 동시에 수행합니다.

이는 Kubernetes가 확장된 운영 체제라고 말하는 것이 아닙니다. OS는 여전히 각 프로그램의 실행을 마샬링하는 역할을 합니다. 그리고 컨테이너화된 환경(적어도 원래 설계된 기본 환경)에서 각 컨테이너의 호스트는 vSphere 또는 KVM과 마찬가지로 하이퍼바이저가 아니라 OS입니다.

그러나 한 가지 측면에서 보면 단일 컴퓨터에 대한 운영 체제라면 서버 클러스터에 대한 오케스트레이터는 실행을 감독합니다. 처리 능력, 메모리, 스토리지, 네트워킹 시설 등 인프라 리소스가 모두 병합. 쿠버네티스는 쿠웨이트를 해방시킨 연합군처럼 데이터센터가 어떤 오케스트레이터를 선호할지에 대한 문제를 극히 짧은 기간에 해결했다. Operation Desert Shield와 마찬가지로 Kubernetes에는 신속하게 실행되는 간단한 전략이 있었습니다.

소프트웨어는 모두 어디로 가나요?

현대 데이터 센터에서는 소프트웨어를 컴퓨터에 "설치"할 필요가 없습니다. 오히려 도서관에서 빌린 책에 가깝고, 대출되기 전에 책을 출판할 수 있는 유일한 책에 가깝습니다. 컨테이너화 영역에서는 이 라이브러리를 레지스트리라고 합니다. 레지스트리에서 대여한 오픈 소스 패키지는 완전히 조립된 컨테이너로 제공됩니다. Kubernetes 관리 환경에 도입하기 위해 레지스트리를 통해 애플리케이션이나 서비스를 사용할 수 있게 만드는 작업을 배포라고 합니다. 따라서 "워크로드 배포"에 관해 이야기할 때, 이는 소프트웨어가 관리되고 조정되는 서버 클러스터에 제공하기 위해 소프트웨어를 준비하는 행위를 의미합니다.

Kubernetes는 레지스트리에서 워크로드 패키지를 검색하고 시스템 배포를 위해 대기열에 추가하고 관리하도록 구축되었습니다. 이를 통해 사용할 수 있는 리소스에 대한 액세스를 감독하고 관리하는 클러스터 간의 배포 클러스터.

그렇게 형편없는 이름을 가질 수 있는데 컨테이너화가 왜 그렇게 중요한가요?

컨테이너화는 Docker Inc.에 의해 공식적으로 시작된 추세이며, 이후 Google에 의해 빠른 속도로 추진되었으며 이제는 Microsoft 및 VMware를 포함하여 플랫폼 공간의 다른 대부분의 사람들이 합류하고 있습니다. 이는 데이터 센터 관리의 난해한 측면으로, 4년 전에는 일반 사용자가 간과할 수 없는 부분이라고 들었습니다. 그러나 Netflix와 Amazon Prime의 모든 시청자, 그리고 Alexa와 Siri의 모든 사용자는 비록 출처를 식별할 수는 없더라도 이러한 영향을 직접 느꼈습니다. 데이터 센터 관리의 초점을 머신에서 워크로드로 전환함으로써 애플리케이션과 서비스 제공 방식이 혁신적으로 바뀌었습니다.

Tupperware 파티를 산업화하는 방법처럼 들리는 "컨테이너화"보다는 "워크로드 혁명"이라고 불립니다. 네트워크는 이제 기능이 아닌 기능을 향해 라우팅되고 있습니다. 기계. 충분한 실제 비유 없이는 실제로 이 아이디어의 중요성을 이해하기 어렵습니다. 머리 꼭대기에서 몇 개의 전화 번호를 기억하십니까? 이제 스마트폰에 연락처 목록이 있고 음성에 응답할 수 있으므로 마음 속에 숫자 패턴이 더 많거나 적습니까?

이 "작업량" 사업은 모두 무엇입니까?

컴퓨터에서 실행되는 프로그램은 여전히 ​​"소프트웨어"입니다. 이는 NASA 엔지니어가 원래 아폴로 시대에 말장난으로 만든 용어를 사용하는 것입니다. 그리고 애플리케이션은 여전히 ​​여러 사용자가 운영하고 이름으로 참조하도록 설계된 프로그램입니다.

이에 비해 "워크로드"는 약간 더 모호합니다. 하나 이상의 소프트웨어로 구성됩니다. 데이터베이스를 사용할 수도 있지만 다른 워크로드가 사용하는 것과 동일한 데이터베이스일 수도 있습니다. 이는 레지스트리에 있는 두 개 이상의 패키지로 구성되어 즉석에서 조립되고 클러스터 내에서 기능을 공유할 수 있습니다. 그러나 일반적으로 하나의 주요 목적을 갖고 있으며 여러 개의 복합 부품이 있더라도 하나의 응집력 있는 단위로 작동할 수 있습니다.

소프트웨어 개발자는 일반적으로 책상에 앉아 작업 부하를 구성하지 않습니다. 그들은 여전히 ​​프로그램을 작성합니다. 그러나 해당 프로그램을 중심으로 조립된 컨테이너를 배포하는 과정에서 Kubernetes와 같은 오케스트레이터에 제공된 지침은 결국 활성 워크로드의 작동 매개변수를 선언하게 됩니다. 따라서 배포 과정에서 소프트웨어는 워크로드가 됩니다. 데이터 센터의 리소스 소비에 미치는 영향을 측정하고 완화할 수 있습니다. 사람과 사물의 일상적인 영역에서 작업 부하의 영향을 측정하고 완화할 수 있습니다. 직원.

그럼, "서비스"란 무엇인가요?

현대 데이터 센터의 서비스는 애플리케이션과 매우 다릅니다. 애플리케이션은 종종 유용한 서비스를 수행하는 것으로 설명되기 때문에 이는 합리적이지 않은 것처럼 보일 수 있습니다. 그러나 구조적으로 말하면 서비스는 지정된 입력이 주어지고 관련 데이터가 지정되면 예측 가능한 출력 세트를 생성하는 소프트웨어입니다. 데이터베이스는 종종 서비스를 사용하여 쿼리됩니다.

애플리케이션은 사용자에게 서비스를 사용할 수 있는 환경(일반적으로 시각적 환경)을 제공합니다. 서비스는 해당 기능에 관심을 가질 필요가 없습니다.

오늘날 가장 잘 조직되고 컨테이너화된 프로그램은 서비스입니다. 이들은 애플리케이션의 가장 중요한 업무를 수행할 수 있지만 독립적인 단위입니다. 마이크로서비스는 작은 경향이 있는 독립형, 개별적, 자립형 서비스입니다(최근 소프트웨어 설계자들은 반드시 그럴 필요는 없다고 주장하지만). 오케스트레이터는 전달되는 요청에 응답하기 위해 필요하거나 허용되는 만큼 마이크로 서비스 복제본을 호출(또는 "인스턴스화")할 수 있습니다.

API(원래 "Application Program Interface"의 약자)는 지정된 통신 프로토콜을 사용하는 서비스 집합입니다. 네트워크 컴퓨팅에서 API는 명령이나 명령문을 수신 서버에 전달하기 위해 제작된 URL을 사용하여 일반적으로 웹 브라우저를 통해 원격으로 연결되도록 설계되었습니다. 해당 명령은 도중에 데이터 패키지를 업로드할 수도 있습니다. 해당 명령에 대한 응답자는 서비스입니다. Kubernetes의 장점은 서비스를 조정하는 것입니다.

예, 서비스는 일종의 작업 부하입니다. 아마도 현대 서비스 아키텍처의 가장 두드러진 예는 다음과 같습니다. 소위 서버리스 기능. 다른 서비스나 해당 사용자가 호출하기 위해 소스(이를 호스팅하는 서버 또는 서버 클러스터)를 이름으로 지정하거나 간접적으로 지정할 필요가 없기 때문에 이렇게 부릅니다. 대신 해당 세부 정보는 요청자를 대신하여 채워지며 결과적으로 해당 기능의 사용자는 해당 기능이 클라이언트에 로컬로 존재하는 것처럼 가장할 수 있습니다. 스마트폰의 연락처 목록처럼 숫자가 중요하지 않다고 생각하게 만듭니다.

쿠버네티스의 구성요소

이 기사는 "컨테이너"라는 단어나 그보다 더 적은 단어를 사용하지 않고 처음 10개 단락까지 빠져 있음을 눈치챘을 것입니다. 자명한 단어 "컨테이너화". Kubernetes와 컨테이너의 분리는 최근 몇 달 동안 범위에 대한 가장 예상치 못한 변화 중 하나입니다. 쿠버네티스의 잠시 후에 그 이유를 이해하게 될 것입니다.

오케스트레이션의 주요 목표 중 하나는 네트워크에서 사물을 사용할 수 있도록 하는 것입니다. 지금까지 우리는 이러한 것들을 주로 "컨테이너"라고 불렀습니다. 처음부터 Kubernetes는 자신이 조정하고 효과적으로 오케스트레이션하는 개체를 다음과 같이 언급했습니다. 꼬투리. 이러한 맥락에서 "포드"라는 용어는 단순히 "컨테이너 그룹"으로 정의되었습니다.

제어 영역의 포드 및 리소스

Kubernetes 클러스터의 각 서버(물리적 또는 가상)를 노드라고 합니다. Kubernetes의 일부 측면을 호스팅하고 오케스트레이터가 유지 관리하는 네트워크를 통해 주소를 지정할 수 있는 경우 노드입니다. 마스터 노드와 작업자 노드(때때로 미니언이라고도 함)가 있습니다. 시스템 제어를 담당하는 구성 요소 네트워크는 다른 모든 네트워크와 분리되어 제어 평면을 형성합니다. 이 독점 평면에는 세 가지 구성 요소가 있습니다.

• API 서버(kube-api서버), Pod 내부에서 실행되는 서비스를 포함하여 들어오는 모든 요청의 유효성을 검사합니다.
• 컨트롤러 관리자(kube-컨트롤러-관리자). 시스템 내 일부 리소스 관리를 직접 담당하는 Kubernetes의 개별 구성 요소를 컨트롤러라고 합니다. 예를 들어 포드 기반 서비스가 수행할 작업을 프로비저닝하는 것은 작업 컨트롤러의 작업입니다. 흥미로운 점은 Kubernetes가 추가 컨트롤러를 추가하여 확장되어 컨테이너 이외의 기능을 조정하는 역할을 할 수 있다는 것입니다.
• 스케줄러(kube-scheduler), 이는 시간에 관한 것이 아니라 워크로드를 포드에 위임하는 것만큼 중요하지 않습니다. 포드가 프로비저닝되면 스케줄러는 현재 가용성 상태를 고려하여 포드를 처리하는 데 가장 적합한 작업자 노드에 포드를 위임합니다.

컨트롤러는 Kubernetes 제어 영역 내부에 있습니다. Kubernetes와 함께 제공되는 것의 주요 기능은 변경 사항을 찾기 위해 네트워크 인프라의 리소스 상태를 모니터링하는 것입니다. 최선의 대응 방법을 결정하는 평가 기능을 트리거하려면 이벤트(그러한 변화의 신호)가 필요합니다. 응답 작업을 위임할 수 있는 서비스 클래스는 운영자입니다. 오케스트레이터가 더 복잡한 시스템을 자동화할 수 있도록 하기 위해 서비스 설계자는 다음을 추가합니다. 컨트롤러는 제어 플레인으로 가서 결정을 내리고, 백엔드의 운영자는 이에 따라 조치를 취합니다. 결정.

커스텀 리소스

결국 데이터 센터에서 Kubernetes의 위치를 ​​확고히 하는 대작이 될 수 있는 것은 이 컨트롤러 체계의 확장성입니다. 사용자 정의 리소스 정의(CRD)라는 아키텍처 추가의 결과로, Kubernetes는 이러한 컨테이너 이외의 작업을 조율할 수 있습니다.. 달리 말하면, Kubernetes가 다른 것을 오케스트레이션된 리소스로 인식하도록 효과적으로 가르치는 컨트롤러를 만들 수 있다면 그렇게 할 것입니다. 여기서 말하는 것은 무엇입니까? "다른 것"은 무엇일까요?

• 가상 머신(VM) -- 전 세계 기업 워크로드의 대부분을 지원하는 고전적인 하이퍼바이저 기반 엔터티입니다. vSphere 플랫폼이 VM 관리 부문에서 가장 뛰어난 상용 리더인 VMware는 Kubernetes를 주요 VM 오케스트레이터로 만들기 위한 프로젝트가 이미 시작되었습니다..
• 대규모 데이터베이스 최근 몇 년 동안 엔진과 제어 작업이 Hadoop 및 Apache Spark와 같은 전용 시스템으로 옮겨졌습니다. 개발자가 Java, Scala, 아르 자형.
• 고성능 컴퓨팅(HPC) 워크로드 역사적으로 슈퍼컴퓨터의 지배를 받아온 슈퍼컴퓨터의 경우 Slurm과 같은 전용 스케줄러 그리고 최근에는 아파치 메소스. Kubernetes가 거의 편재성에 가까워짐에 따라 데이터 센터에서 시간 지향적 스케줄링 에이전트로서의 장점이 의문시되고 있습니다.
• 기계 학습 모델, 이는 병렬 액세스와 결정론적 스케줄링을 갖춘 대규모 데이터 볼륨이 필요합니다. 이러한 요소만으로 Kubernetes가 오케스트레이터 또는 인프라 촉진자로서 자격을 상실한다고 생각할 수도 있지만 다음과 같은 프로젝트가 있습니다. Kubeflow 이러한 기능을 제공하는 데이터베이스 공급자와 스케줄러는 Kubernetes에 의해 자체적으로 프로비저닝됩니다.

데이터 평면의 개체

Pod에 수집되는 이러한 모든 클래스의 작업 부하 엔터티와 향후 Kubernetes가 조율하게 될 다른 모든 항목이 포드로 통합됩니다. 객체, 더 나은 단어가 부족하여.

오케스트레이터에게 이러한 개체 중 하나를 설명하는 것은 매니페스트라고 하는 ID 문서 역할을 하는 파일입니다. 이는 객체가 사용할 리소스를 선언하는 YAML이라는 언어를 사용하여 작성된 코드 요소입니다. 컨트롤러는 원하는 경우 개체가 소비할 연료의 양, 스토리지의 양, 데이터베이스 클래스, 네트워크 포트 등을 미리 볼 수 있습니다. 컨트롤러는 이러한 요구 사항을 충족하기 위해 최선을 다합니다. 클러스터에 이미 과도한 부담이 가해지면 가능한 한 최선을 다해야 할 수도 있다는 사실을 알고 있기 때문입니다.

각 포드 내부에는 다음과 같은 원격 에이전트가 있습니다. 쿠벨렛, 운영자로부터 요청을 받고 Pod의 구성 요소를 관리합니다. 기존의 컨테이너 기반 시스템에서는 쿠벨렛 컨테이너 엔진에 대한 프로세스를 생성합니다. Docker는 Kubernetes 테이블에서 예약된 위치를 차지했던 곳입니다. Docker는 사실상 컨테이너 엔진의 독점 공급자였습니다. 심지어 범용 런타임도 만들었습니다. 실행C ("실행·보기"로 발음)을 작성하여 오픈 소스 커뮤니티에 공개했습니다. 이제 Kubernetes 프로젝트는 다음과 같은 자체 대안을 탄생시켰습니다. 크리오 ("cry · O"는 때때로 "Creole"처럼 말하지만), 이는 다음과 같은 컨테이너 엔진에서 선호됩니다. Red Hat OpenShift와 같은 Kubernetes 기반 플랫폼.

Kubernetes의 패배한 경쟁자

많은 기술 언론이 서버 클러스터 오케스트레이션 공간이 현대 데이터 센터에서 가장 뜨거운 전쟁터라는 집단적 인식을 갖기 전에 전투는 이미 끝났습니다. 상품 시장은 오랫동안 경쟁 표준을 용인하는 경우가 거의 없습니다. 이것이 바로 하나의 HTML, 하나의 Facebook, 하나의 Kubernetes가 있는 이유입니다.

도커 스웜

컨테이너 혁명을 촉발한 엔지니어들이 모인 회사, 도커(Docker Inc.)가 사업을 시작했습니다. 대규모 배포, 보안, 무료 오픈 소스 지원을 상용화하는 데 초기 철학을 두고 있습니다. 핵심. 수익은 Docker 브랜드이지만 일반적으로 대체품을 사용할 수 있는 Docker 코어의 부착 및 강화에서 발생합니다. "배터리"라는 비즈니스 모델의 경우 포함되지만 교체 가능합니다." Docker의 리더들은 컨테이너가 어디에나 존재하게 된다면 컨테이너를 만드는 것에 대해 지적이든 아니든 어떤 주장도 해서는 안 된다고 주장했습니다. 상품. 시장이 더 넓어지면 더 많은 수의 기꺼이 고객을 확보하게 될 것이라고 회사는 믿었습니다.

이를 위해 2015년 Docker가 지원했습니다. 오픈 컨테이너 이니셔티브의 창설 (OCI, 원래는 Open Container Project 또는 Open Container Foundation이지만 여러 가지 이유로 곧 이름 변경이 필요함) Linux Foundation의 후원을 받습니다. 회사 회의에서 발표할 때, 당시 CTO였던 솔로몬 하이크스는 청중에게 이렇게 말했습니다. 그는 "상자의 크기와 모양과 같은 세부 사항"을 놓고 논쟁을 벌이는 표준 전쟁을 좋아하지 않았습니다. 그런 이유로, 중 또한 Hykes는 Docker 컨테이너의 런타임 구성 요소(네트워크를 통해 작동 가능하게 만드는 부분)를 교체한다고 발표했습니다. ~와 함께 실행C.

바로 같은 주에 OCI의 창립 멤버 중 다수가 다음과 같은 내용을 발표했습니다. 클라우드 네이티브 컴퓨팅 재단 설립, Linux Foundation의 또 다른 프로젝트입니다. 표면적으로 CNCF의 임무는 오픈 소스 애플리케이션 배포 기술의 사용을 촉진하고 발전시키는 것입니다. CNCF가 관리할 첫 번째 프로젝트는 다음 3월부터 시작됩니다. 쿠버네티스일 것이다, Google에서 시작된 프로젝트입니다.

한편, 덜 다재다능하고 때로는 몇 가지 실험을 거친 후 배포 플랫폼에 대한 어색한 시도, Swarm은 Docker의 오케스트레이터가 되었습니다. 대부분의 경우 Swarm은 가치 있는 경쟁자였습니다. 관리자는 학습 곡선이 훨씬 덜 힘들다고 말했습니다. 컨테이너 간 트래픽을 호스트 트래픽에서 분리한 오버레이 네트워킹 모델은 각각의 평면에서 이들 사이의 브리지는 특히 Kubernetes의 플랫 네트워크 오버레이 모델과 비교할 때 영리한 것으로 인식되었습니다. 다중 클라우드 배포 모델에서 Swarm 컨테이너 클러스터는 느린 퍼블릭 클라우드에 위임될 수 있는 반면, 제어 플레인의 트래픽은 지연 시간이 짧은 클러스터에 더 밀접하게 포함될 수 있습니다. 성능과 관리 효율성 측면에서 전문가들은 선호하는 제품을 선택하는 데 시간이 많이 걸렸습니다.

성능만으로 기술 전쟁의 결과가 결정된다면 Sun Microsystems는 오래 전에 데스크탑을 정복했을 것이며 우리 모두는 BlackBerry에서 그것에 대해 이야기했을 것입니다.

CNCF는 다음을 포함하여 전체 오픈 소스 생태계의 광범위한 배포를 발전시키고 촉진하는 것을 사명으로 삼았습니다. 성능 모니터링, 서비스 검색, 데이터 볼륨 관리 및 보안이 모두 하나의 워크로드 배포를 중심으로 이루어집니다. 엔진. Docker는 이미 확장성 모델을 출시하기 시작했지만 즉시 난해하고 철학적인 수렁에 빠졌습니다. 확장 가능한 아키텍처가 "무국적"이라는 애플리케이션 설계의 특정 교리를 위반했는지 여부에 대한 것입니다.

동시에 Kubernetes는 공급업체에 구애받지 않는 플랫폼으로 분류되었지만 초기에는 Google이 모든 역량을 집중하고 소비자와 언론인 모두에게 주제와 일관된 홍보를 맞춤화하는 동시에 Kubernetes라는 이름을 브랜딩. 2017년 내내 Kubernetes를 평가하는 기업은 이를 Google 제품으로 인식했습니다. 적법성과 형식이 그들에게 설명되었을 때 많은 사람들은 최종 결과가 다음과 같은 것이라면 아무것도 중요하지 않다고 말하며 손을 흔들었습니다. 구글 쿠버네티스 엔진. 제가 참여한 몇 차례 이상의 대화에서 IT 관리자와 기타 전문 기업 실무자들은 Google과 Google의 차이에 대해 이야기했습니다. 도커(Docker), 샘 힐(Sam Hill)이 도커란 무엇인가?

그러나 구글은 오케스트레이션 신앙의 유일한 옹호자로서의 모습을 오랫동안 유지할 수 없었다. 2015년으로 거슬러 올라가면, Red Hat은 중대한 결정을 내렸습니다. OpenShift 컨테이너 배포 플랫폼의 엔진을 Kubernetes로 교체합니다. 2017년까지 그 결정은 큰 성과를 거두었습니다. Red Hat은 최고의 Kubernetes 기여자가 되었습니다. 북쪽에서는 마이크로소프트가 기업에 또 다른 변화의 물결이 닥칠 가능성을 막기 위해 오픈 소스 커뮤니티에서 가장 눈에 띄는 엔지니어 두 명을 고용했습니다. 컨테이너화된 애플리케이션 구축 및 배포를 위한 Kubernetes 생태계의 핵심 요소인 Deis의 공동 창립자이자 CTO였던 Gabe Monroy(Docker가 방어하기를 바랐던 보루) 그 자체); Kubernetes 프로토타입인 Borg를 만든 Google 엔지니어 중 한 명인 Brendan Burns는 [PDF]. 이번에는 Microsoft가 일부 연구 부서 측면 프로젝트의 뒷장에 신입 사원을 숨기지 않았습니다. 그들은 Kubernetes 이미지에서 Azure의 상당 부분을 다시 만드는 데 앞장섰습니다.

댐이 무너지고 있었고 동시에 여러 곳에서 발생했습니다.

아파치 메소스

분산 서버 클러스터의 워크로드 스케줄링 부문에서 확고한 선두주자는 Apache Mesos였습니다. 이는 마스터/워커 아키텍처를 개척했으며(Mesos는 "워커"에 대해 다른 단어를 사용했지만) Marathon이라는 프라이빗 PaaS 플랫폼으로 확장된 최초의 스케줄러 중 하나였습니다. Mesos의 첫 번째 주요 배포는 Ben Hindman이 엔지니어로 근무했던 Twitter에서 이루어졌습니다. 2013년에 Hindman은 Mesos의 최고의 상업 공급업체인 Mesosphere를 설립하기 위해 떠났습니다. Mesosphere는 Microsoft와 협력하여 조직화되고 하이브리드된 배포를 가능하게 하는 최초의 퍼블릭 클라우드 기반 PaaS 중 하나를 제작했습니다. DC/OS, 이는 Azure를 위한 최고의 워크로드 배포 플랫폼이 될 것으로 보였습니다. 메소스는 수년간의 구축 경험이 있다는 장점이 있었기 때문에 처음부터 모두가 헤아릴 필요는 없는 플랫폼이었습니다.

그러나 현직 메소스는 전력을 다해 반군 도전자의 영향을 피할 수 없었다. 2017년 8월, VMware는 자매 회사인 Pivotal의 리소스를 활용하여 Pivotal Container Service라는 클라우드 기반 Kubernetes 플랫폼, Cloud Foundry의 순위를 통해 올라온 Kubo라는 자동화된 배포 메커니즘을 사용합니다. 곧 Azure도 이를 따라 DC/OS 프로젝트를 효과적으로 중단했습니다. 그러다가 2018년 6월, 그 충실한 아마존은 방어적 입장을 포기했다, Kubernetes 배포 플랫폼을 공개합니다. 그리고 마지막으로, 그것을 믿는 사람은 거의 없습니다 지난 7월 IBM의 Red Hat 인수가 마무리되었습니다., IBM이 더 나은 Linux 배포판을 필요로 한다는 내용이었습니다. OpenShift는 IBM이 더 이상 다시 포장할 필요가 없다고 판단한 분산 데이터 센터에 대한 경로를 이미 포장했습니다.

패배가 너무 완벽해서 메소스피어는 더 이상 그 이름으로 거래를 할 수 없었고, 지난 8월 D2IQ로 이름을 바꾸다, 자체 "Ksphere"를 구축하겠다고 다짐했습니다. 그리고 10월 초, 도커가 제안함 사용자는 Kubernetes와 Swarm을 나란히 실행해 봅니다. 회사 블로그 게시물에는 "새로운 사용자는 Docker Swarm을 이해하는 것이 훨씬 더 쉽다는 것을 알게 되었습니다."라고 적혀 있습니다. "그러나 Kubernetes는 많은 기능을 추가하도록 발전했습니다."

Kubernetes가 여기에서 어디로 가는지

지금까지 데이터 센터 재구축에 대한 논의의 대부분은 기존 워크로드를 새 모델로 마이그레이션하는 주제를 중심으로 이루어졌습니다. 우리가 알고 있는 애플리케이션은 "모놀리스"라고 불립니다. 왜냐하면 영화 "2001"에 나오는 신비한 물체처럼 그것들은 독특하고 실질적으로 견고하며 처음에 그랬던 것처럼 4시간 동안 극장에 앉아 있어도 설명할 수 없기 때문입니다. 이는 작성자만이 변경할 수 있는 코드로 구성되어 있습니다.

Kubernetes로의 이동은 모놀리식 마이그레이션 프로세스로 설명되었습니다. 어떤 사람들은 이것이 이전의 모놀리식 네트워크처럼 작동하지만 이를 완전히 대체하는 마이크로서비스 네트워크를 재구축해야만 가능하다고 말했습니다. 다른 사람들은 모놀리식 서비스 주위에 API를 래핑하고 마이크로서비스 방식으로 네트워크를 통해 해당 API를 배포하는 것이 가능하다고 말합니다. 그렇게 하는 것이 더 쉬울 것이며 기업이 이미 소유하고 있는 동일한 기능을 복제하는 데 많은 노력이 필요하지 않을 것입니다.

이제 Kubernetes의 CRD(Arlo Guthrie의 표현을 빌리자면) 덕분에 누구도 예상하지 못했던 세 번째 가능성이 생겼습니다. 즉, Kubernetes 자체가 기존 워크로드의 요구 사항을 충족하기 위해 마이그레이션할 수 있다는 것입니다. 아마도 세계에서 가장 활동적인 오픈 소스 소프트웨어 프로젝트인 Kubernetes는 말 그대로 수백 명의 전문가에 의해 유지 관리되고 있습니다. 기업이 소프트웨어를 자동화하는 데 필요한 컨트롤러 및 운영자를 고안하거나 조정하는 데 도움을 줄 수 있는 엔지니어 공급망.

Kubernetes를 만든 사람들은 몇 년 전에 자신의 창작물이 다음과 같은 시대가 올 것이라고 말했습니다. 모든 사람의 데이터 센터에 너무 많은 부분이 있기 때문에 지루할 뿐 아니라 이에 대한 기사도 읽지 않을 것입니다. 그것. 내가 목격한 바에 따르면 그날은 아직 적어도 몇 년은 더 남아 있다.

자세히 알아보기 -- CBS Interactive Network에서

• Kubernetes의 다음 단계는 다른 모든 것을 조정하는 것입니다. 작성자: Scott M 풀턴, III, ZDNet
• 5G는 클라우드의 Kubernetes에 달려 있습니다. 스티븐 J. 본-니콜스, ZDNet 리눅스와 오픈소스
• Red Hat이 Knative를 Kubernetes 오케스트레이션에 대한 해답으로 보는 이유 작성자: James Sanders, TechRepublic Cloud

다른 곳

• Kubernetes 사용자 정의 리소스 정의: CRD 설명 BMC 소프트웨어로
• 쿠버네티스 아키텍처 101 아쿠아컨테이너시큐리티 제공
• Kubernetes 아키텍처 이해 작성자: Edureka