Apache Mesos와 Google Kubernetes의 차이점은 무엇입니까?


385

Apache의 Mesos와 Google의 Kubernetes의 차이점은 정확히 무엇입니까? 둘 다 서버 클러스터 관리 소프트웨어라는 것을 알고 있습니다. 누구든지 주요 차이점이 어디에 있는지 자세히 설명 할 수 있습니까? 언제 어떤 프레임 워크가 선호됩니까?

Mesosphere 위에서 Kubernetes 를 사용하고 습니까?

답변:


515

Kubernetes는 가상 머신 세계 또는 '금속'시나리오에 'Google 스타일'클러스터 관리 기능을 제공하는 오픈 소스 프로젝트입니다. 그것은 당신을 위해 관리되는 가벼운 컴퓨팅 '노드'를 제공하는 현대 운영 체제 환경 (CoreOS 또는 Red Hat Atomic과 같은)과 매우 잘 작동합니다. Golang으로 작성되었으며 가볍고 모듈 식이며 휴대 가능하며 확장 가능합니다. 우리 (Kubernetes 팀)는 여러 다른 기술 회사 (Mesos 오픈 소스 프로젝트를 관리하는 Mesosphere 포함)와 협력하여 Kubernetes를 컴퓨팅 클러스터와 상호 작용하는 표준 방법으로 설정하고 있습니다. 아이디어는 사람들이 Google에 대한 경험을 바탕으로 클러스터 애플리케이션을 구축해야하는 패턴을 재현하는 것입니다. 이러한 개념 중 일부는 다음과 같습니다.

  • 포드 — 컨테이너를 그룹화하는 방법
  • 복제 컨트롤러 — 컨테이너의 수명주기를 처리하는 방법
  • 레이블 — 컨테이너를 찾고 쿼리하는 방법
  • 서비스 — 공통 기능을 수행하는 컨테이너 세트.

따라서 Kubernetes 만 있으면 간단하고 실행하기 쉽고 휴대 가능하며 확장 가능하여 가장 가벼운 방식으로 관리하는 항목에 '클러스터'를 명사로 추가 할 수 있습니다. 클러스터에서 응용 프로그램을 실행하고 개별 시스템에 대한 걱정을 중지하십시오. 이 경우 클러스터는 VM과 같은 유연한 리소스입니다. 논리적 컴퓨팅 장치입니다. 전원을 켜고 사용하고 크기를 조정 한 후 빠르고 쉽게 줄이십시오.

Mesos를 사용하면 기본 비전 측면에서 상당한 양의 겹침이 발생하지만 제품의 수명주기는 상당히 다른 지점에 있으며 스위트 스폿이 다릅니다. Mesos는 여러 시스템을 논리적 컴퓨터에 연결하는 분산 시스템 커널입니다. 큰 정적 컴퓨팅 클러스터를 만들기 위해 많은 물리적 리소스를 소유 한 세계에서 탄생했습니다. 그것에 대한 좋은 점은 현대적인 확장 가능한 데이터 처리 응용 프로그램이 Mesos (Hadoop, Kafka, Spark)에서 잘 실행된다는 것입니다. 새로운 연령 컨테이너 패키지 응용 프로그램과 함께 동일한 기본 리소스 풀에서 모두 실행할 수 있기 때문에 좋습니다. . Kubernetes 프로젝트보다 다소 무겁지만 Mesosphere와 같은 사람들의 작업 덕분에 관리가 쉬워지고 있습니다.

이제 흥미로운 점은 Mesos가 현재 많은 Kubernetes 개념을 추가하고 Kubernetes API를 지원하도록 조정되고 있다는 것입니다. 따라서 필요한 경우 Kubernetes 앱에 대한 더 많은 기능 (고 가용성 마스터, 고급 스케줄링 의미, 매우 많은 수의 노드로 확장 할 수있는 기능)을 제공하고 프로덕션 워크로드 (Kubernetes)를 실행하는 데 적합합니다. 아직 알파 상태입니다).

물었을 때 나는 다음과 같이 말하는 경향이있다.

  1. Kubernetes는 클러스터링 세계에 익숙하지 않은 경우 시작하기에 좋은 곳입니다. 그것은 타이어를 걷어차 고 클러스터 중심 개발을 실험하는 가장 빠르고 쉬운 방법입니다. 다양한 공급자 (Microsoft, IBM, Red Hat, CoreO, MesoSphere, VMWare 등)가 지원하기 때문에 매우 높은 수준의 이식성을 제공합니다.

  2. 기존 워크로드 (Hadoop, Spark, Kafka 등)가있는 경우 Mesos는 해당 워크로드를 서로 인터리브하고 Kubernetes 앱을 포함한 새로운 기능을 혼합 할 수있는 프레임 워크를 제공합니다.

  3. Kubernetes 프레임 워크에서 커뮤니티에서 아직 구현하지 않은 기능이 필요한 경우 Mesos가 탈출 밸브를 제공합니다.


4
훌륭한 개요. 두 가지 간단한 생각 : 1) Kubernetes가 알파가 아닌 베타 버전이라고 생각합니까? 2) 마라톤에 대한 정보를 추가 하시겠습니까?
knite

57
요약하자면 (빠른 읽기를 위해-올바르게 이해하기를 바랍니다) kubernetes는 컨테이너의 클러스터 관리자입니다 (전용?) mesos는 클러스터를 지원되는 모든 프레임 워크에 대한 하나의 거대한 컴퓨터 시스템처럼 보이게하는 분산 시스템 커널입니다 그리고 mesos에서 실행되도록 빌드 된 앱. 그러나 kubernetes는 mesos에서 실행할 수있는 프레임 워크 중 하나입니다. 따라서 둘 다 결합하면 클러스터가없는 클러스터와 관리 할 클러스터가없는 클러스터 관리자가됩니다. Great new world :-) (J / K는 kub.가 더 성실한 물리 해상도이기 때문에 많은 이점이 있습니다.)
masi

7
다음은 Kubernetes 1.0 런칭 이벤트 : youtube.com/…에서 면책 사항입니다.
Air

68

두 프로젝트 모두 데이터 센터 또는 클라우드의 컨테이너 내부에서 애플리케이션을보다 쉽게 ​​배포 및 관리 할 수 ​​있도록합니다.

Mesos 위에 응용 프로그램을 배포하기 위해 Mesos에 Marathon 또는 Kubernetes를 사용할 수 있습니다.

Marathon은 cgroup 및 Docker 컨테이너에서 Linux 서비스를 실행하기위한 클러스터 전체 초기화 및 제어 시스템입니다. 마라톤에는 다양한 카나리아 배포 기능이 있으며 매우 성숙한 프로젝트입니다.

Marathon은 확장 성이 뛰어나고 전투 테스트를 거친 유연한 리소스 관리자 인 Mesos에서 실행됩니다. 마라톤은 많은 프로덕션 환경에서 확장 및 실행되는 것으로 입증되었습니다.

Mesos 및 Mesosphere 기술 스택은 기존 Linux 워크로드를 실행하기위한 클라우드와 유사한 환경을 제공하지만 새로운 분산 시스템을 구축하기위한 기본 환경도 제공합니다.

Mesos는 데이터 센터에 대해 직접 프로그래밍하기위한 전체 API를 갖춘 분산 시스템 커널입니다. 기본 하드웨어 (예 : 베어 메탈 또는 VM)를 추상화하고 리소스 만 노출합니다. 여기에는 Message Passing, Task Execution 등과 같은 분산 응용 프로그램 (예 : Spark는 원래 Mesos App, Chronos 등)을 작성하기위한 기본 요소가 포함되어 있습니다. 따라서 완전히 새로운 응용 프로그램이 가능합니다. Apache Spark는 원래 Mesos 용으로 구축 된 새로운 Mesos 전문 용어 프레임 워크의 예입니다. 이를 통해 정말 빠른 개발이 가능해졌습니다. Spark 개발자는 Mesos의 핵심 요소이므로 노드간에 작업을 분배하기 위해 네트워킹에 대해 걱정할 필요가 없었습니다.

내 지식으로는 Kubernetes는 현재 Google의 프로덕션 배포 환경에서 사용되지 않습니다. Google은 프로덕션을 위해 Mesos / Marathon 모델과 훨씬 유사한 Omega / Borg를 사용합니다. 그러나 Mesos를 기초로 사용하는 것에 대한 가장 큰 장점은 Kubernetes와 Marathon 모두 그 위에 실행될 수 있다는 것입니다.

마라톤에 대한 추가 자료 :

https://mesosphere.github.io/marathon/

비디오 : https://www.youtube.com/watch?v=hZNGST2vIds


37

Kubernetes와 Mesos는 하늘에서 만든 성냥입니다. Kubernetes는 서비스 발견,로드 밸런싱 및 복제 제어를위한 포드 레이블과 함께 포드 (공동 배치 된 컨테이너 그룹) 추상화를 가능하게합니다. Mesos는 클러스터의 여러 노드에서 포드에 대한 세분화 된 리소스 할당을 제공하며 Kubernetes가 동일한 클러스터 리소스에서 실행되는 다른 프레임 워크와 원활하게 재생되도록 할 수 있습니다.

에서 는 Kubernetes - 메소의 추가 정보


18

Mesos와 Kubernetes는 머신 클러스터를 관리하고 하드웨어를 추상화하는 데 사용할 수 있습니다.

Mesos는 의도적으로 스케줄러를 제공하지 않으므로 (프로세스를 언제 어디서 실행할지, 프로세스가 실패 할 경우 수행 할 작업을 결정하기 위해) Marathon 또는 Chronos와 같은 것을 사용하거나 직접 작성할 수 있습니다.

Kubernetes는 즉시 당신을 위해 예약을 할 것이며, 함께 사용할 수있는 Mesos의 스케줄러로 사용할 수 있습니다 (내가 틀렸다면 정정하십시오!). Mesos는 동일한 클러스터를 공유하는 여러 스케줄러를 가질 수 있으므로 이론적으로 동일한 하드웨어에서 kubernetes와 크로노스를 함께 실행할 수 있습니다.

매우 간단하게 : 컨테이너 예약 방법을 제어하려면 Mesos로, 그렇지 않으면 Kubernetes 바위로 이동하십시오.


1
이 답변은 부정확하고 혼동됩니다. Kubernetes에서 Mesos를 쉽게 실행할 수있는 방법은 없습니다. 실제로 이는 아키텍처의 역전입니다. Kubernetes는 Mesos보다 덜 일반적이기 때문에 Mesos에서 실행하는 것이 더 합리적입니다.
ssk2

1
네, Kubernetes가 Mesos에서 실행되고 있음을 의미했습니다. Kubernetes는 mesos 프레임 워크에 대한 예약 논리를 제공하며 mesos는 작업 실행 등을 처리합니다. 명확하지 않은 경우 죄송합니다.
user2851943

2
@air 여기서 스케줄러를 어떻게 정의하는지 알고 싶습니다. Mesos 자체는 스케줄링 로직을 제공하지 않는 것 같습니다. 이것은 모두 Chronos / Marathon / etc에서 처리됩니까? (아마도 내가 뭔가를 놓쳤다! :))
user2851943

6
나는 당신이 무엇을 얻고 있는지 알 것입니다-Mesos는 스케줄러를 연결할 수있는 프레임 워크입니다. Mesos가 중요한 것을 생략했다는 제안 ( "Mesos는 당신에게 제공하지 않습니다")에 혼란 스러웠습니다. 디자인. 다운 보트를 제거했습니다.
Air

5
이 답변은 정확합니다. Mesos는 리소스 관리에 중점을두고 플러그 가능 프레임 워크를 허용하여 스케줄링을 분리합니다. Fenzo이 : 좋은 예는 무엇 넷플릭스는 스케줄링 프레임 워크를 작성하여 한이다 techblog.netflix.com/2015/08/...
카밀로 크레스포

5

여기이 짧은 비디오와 같은 자료를 학습 메소을

베어 메탈 클러스터를 사용하면 HDFS, SPARK, MR 등과 같은 스택을 생성해야합니다. 베어 메탈 클러스터 관리 만 사용하여 이와 관련된 작업을 시작하면 시작 시간이 많이 소요됩니다.

mesos를 사용하면 베어 메탈 위에 이러한 서비스를 설치할 수 있으며 이러한 기본 서비스의 가동 시간을 피할 수 있습니다. 이것은 mesos가 잘하는 일입니다. kubernetes가 그 위에 구축되어 활용 될 수 있습니다.


3

"둘 다 서버 클러스터 관리 소프트웨어라는 것을 알고 있습니다."

이 진술은 전적으로 사실이 아닙니다. Kubernetes는 서버 클러스터를 관리하지 않으며 최소한의 번거 로움과 노출로 함께 작동하도록 컨테이너를 오케스트레이션합니다. Kubernetes를 사용하면 응용 프로그램의 일부를 "배치"또는 "데몬 세트"(및 몇 가지 다른 것)에 의해 전달되고 서비스를 통해 외부 세계에 노출되는 "포드"(하나 이상의 컨테이너)로 정의 할 수 있습니다. 그러나 Kubernetes는 클러스터 자체를 관리하지 않습니다 (클러스터를 프로비저닝, 구성 및 확장 할 수있는 도구가 있지만 Kubernetes 자체에는 포함되지 않음).

반면에 Mesos는 "클러스터 관리"에 더 가깝습니다. 컨테이너 스케줄링뿐 아니라 어디에서 실행 중인지를 제어 할 수 있습니다. Mesos는 또한 클러스터 서버에서 실행되는 독립형 소프트웨어를 관리합니다. 대부분 Kubernetes의 대안으로 사용되지만 Mesos는 많은 영역에서 기능이 겹치는 반면 Mesos는 더 많은 작업을 수행 할 수있는 것처럼 Kubernetes와 쉽게 작업 할 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.