[cluster-computing] Docker-Swarm, Kubernetes, Mesos 및 Core-OS 집합
나는이 모든 것에 비교적 익숙하지 않지만 나열된 기술 중에서 명확한 그림을 얻는 데 어려움을 겪고 있습니다.
하지만이 모든 것들은 서로 다른 문제를 해결하려고하지만 공통점이 있습니다. 공통점과 다른 점을 이해하고 싶습니다. 소수의 조합이 잘 맞을 가능성이 높습니다. 그렇다면 그들은 무엇입니까?
나는 그들 중 몇 가지를 질문과 함께 나열하고 있지만 누군가가 모든 것을 자세히 나열하고 질문에 답하면 좋을 것입니다.
-
Kubernetes와 Mesos :
이 링크
차이점에 대한 좋은 통찰력을 제공하지만 Kubernetes가 Mesos 위에서 실행되어야하는 이유를 이해할 수 없습니다. 두 개의 오픈 소스 솔루션을 결합하는 것이 더 많은 일입니까?
-
Kubernetes 대 Core-OS 집합 :
kubernetes를 사용하는 경우 플릿이 필요합니까?
-
Docker-Swarm은 위의 모든 항목에 어떻게 적합합니까?
답변
공개 : 저는 Kubernetes의 수석 엔지니어입니다.
Mesos와 Kubernetes는 주로 클러스터 된 애플리케이션을 실행하는 유사한 문제를 해결하는 것을 목표로하고 있으며 문제 해결에 대한 다른 기록과 접근 방식을 가지고 있다고 생각합니다.
Mesos는 매우 일반적인 스케줄링에 에너지를 집중하고 여러 다른 스케줄러를 연결합니다. 즉, Hadoop 및 Marathon과 같은 시스템이 동일한 스케줄링 환경에서 공존 할 수 있습니다. Mesos는 컨테이너 실행에 덜 집중합니다. Mesos는 컨테이너에 대한 광범위한 관심 이전에 존재했으며 컨테이너를 지원하기 위해 부분적으로 리팩토링되었습니다.
대조적으로 Kubernetes는 처음부터 컨테이너에서 분산 애플리케이션을 빌드하기위한 환경으로 설계되었습니다. 여기에는 복제 및 서비스 검색을위한 기본 요소가 핵심 기본 요소로 포함되며, 이러한 요소는 Mesos의 프레임 워크를 통해 추가됩니다. Kubernetes의 기본 목표는 분산 시스템을 구축, 실행 및 관리하기위한 시스템입니다.
Fleet은 하위 수준의 작업 배포자입니다. 예를 들어 CoreOS는 클러스터 시스템을 부트 스트랩하는 데 유용합니다. 동일한 분산 응용 프로그램 개발 문제를 해결하기위한 것이 아니라 클러스터의 systemd / init.d / upstart와 비슷하다고 생각하면됩니다. kubernetes를 실행하는 경우에는 필요하지 않으며 다른 도구 (예 : Salt, Puppet, Ansible, Chef, …)를 사용하여 동일한 바이너리 배포를 수행 할 수 있습니다.
Swarm은 Docker가 기존 Docker API를 확장하여 머신 클러스터를 단일 Docker API처럼 보이게 만들기위한 노력입니다. 근본적으로 Google 및 다른 곳에서의 경험은 노드 API가 클러스터 API에 충분하지 않음을 나타냅니다. 여기에서 많은 토론을 볼 수 있습니다 : https://github.com/docker/docker/pull/8859 및 여기 : https://github.com/docker/docker/issues/8781
도움이 되었기를 바랍니다. 더 이야기하고 싶다면 IRC @ # google-containers에 가입하세요.
답변
가장 간단한 대답은 단순한 대답이 없다는 것입니다. 컨테이너의 성능이 급격히 상승하고 특히 Docker는 “컨테이너 스케줄링 및 오케스트레이션”에 대한 강력한 공백을 남겼습니다. 실제로 이는 어떤 수준에서는 조화롭게 작동 할 수 있지만 경쟁에서는 특정 측면에서 작동 할 수있는 여러 기술을 보유하고 있음을 의미합니다. 예를 들어 Kubernetes는 컴퓨팅 클러스터 (Google이 원래 설계 한대로)에서 컨테이너를 배포하고 관리하기위한 원 스톱 숍으로 사용할 수 있지만, Fleet이 CoreOS에서 제공하는 탄력성 계층을 사용하여 Fleet 위에 위치 할 수도 있습니다.
이 Google vid에 따르면 Kubernetes는 완전한 기본 컨테이너 확장 솔루션은 아니지만 시작하기에 좋은 진술입니다. 같은 방식으로, Marathon이 Kubernetes와 동일한 역할을 수행하는 것처럼 보이는만큼 Apache Mesos가 Kubernetes와 함께 작동 할 수 있지만 Marathon에서는 작동하지 않을 것으로 예상 할 수 있습니다. 내가 읽은 어딘가에서 이것들이 동일한 노력의 일부가 될 수 있다고 생각하지만, 그것에 대해 틀릴 수 있습니다. 사실 Mesosphere의 전략적 방향과 이에 상응하는 Kubernetes 원칙의 채택에 관한 것입니다.
DockerCon 기조 연설에서 Solomon Hykes는 Swarm이 많은 오케스트레이션 및 스케줄링 프레임 워크에 공통 인터페이스를 제공 할 수있는 계층이 될 것이라고 제안했습니다. 내가 볼 수 있듯이 Swarm은 Deis와 같은 기존 컨테이너 워크 플로 프레임 워크와 함께 작동하는 부드러운 Docker 배포 워크 플로를 제공하도록 설계되었지만 Mesos와 같은 “무거운”배포 및 리소스 관리에 적합 할만큼 유연합니다.
이것이 도움이되기를 바랍니다. 이것은 엄청난 게시물이 될 수 있습니다. 핵심은 이것이 통합되고 상호 운용 될 수있는 젊고 진화하는 서비스라는 점이라고 생각하지만, 향후 12 개월 동안 어떻게 작동하는지 확인해야합니다. 문제에 대해 매우 영리한 사람들이 있기 때문에 미래는 매우 밝아 보입니다.
답변
내가 이해하는 한 :
Mesos, Kubernetes 및 Fleet은 모두 매우 유사한 문제를 해결하기 위해 노력하고 있습니다. 아이디어는 개발자로부터 모든 하드웨어를 추상화하고 ‘클러스터 관리 도구’가 모든 것을 정렬한다는 것입니다. 그런 다음 클러스터에 컨테이너를 제공하고 정보를 제공하면 (영구적으로 실행하고 X가 발생하면 확장하는 등) 클러스터 관리자가이를 수행합니다.
Mesos를 사용하면 모든 클러스터 관리를 수행하지만 스케줄러는 포함하지 않습니다. 스케줄러는이 프로세스에 2 개의 프로세서와 512MB RAM이 필요하다는 것을 말하는 비트입니다. 거기에 여유 공간이있는 머신이 있으므로 해당 머신에서 실행하겠습니다. Mesos : Marathon 및 Chronos에 사용할 수있는 플러그인 스케줄러가 있으며 직접 작성할 수 있습니다. 이것은 리소스 분배 및 클러스터 확장 등의 많은 힘을 제공합니다.
Fleet과 Kubernetes는 이러한 종류의 세부 정보를 추상화하는 것처럼 보입니다 (기본적으로 자체 스케줄러를 작성할 필요가 없음). 즉, 작업을 정의하고 Fleet 또는 Kubernetes에서 정의한 형식 / 매너로 제출 한 다음 작업 (컨테이너)을 인계 받아 예약해야합니다.
따라서 Mesos를 사용하면 자신의 스케줄러를 작성하는 데 약간의 작업이 필요할 수 있지만 필요할 경우 더 많은 유연성을 제공 할 수 있습니다.
Mesos 위에서 Kubernetes를 실행하는 아이디어는 Kubernetes가 Mesos의 스케줄러 역할을한다는 것입니다. 개인적으로 나는 이것이 하나 또는 다른 것을 스스로 실행하는 것보다 어떤 이점을 가져다주는 지 잘 모르겠습니다 (누군가가 뛰어 들어 설명 할 것입니다!)
MikeB가 말했듯이 .. 초기 단계이며 모든 것이 준비되어 있으므로 (Amazon의 ECS도 주시하십시오) 경쟁 표준이 많고 겹치는 부분이 많습니다!
-편집-나는 그것에 대해 실제로 많은 경험이 없기 때문에 Docker swarm에 대해 언급하지 않았습니다.
답변
2017 년 이후에이 기능을 사용하는 사람은 모두 사용되지 않습니다. 더 이상 사용하지 마십시오.
플릿 문서 에는 “집단이 더 이상 CoreOS에서 적극적으로 개발 또는 유지 관리되지 않습니다.”라고 말하고 컨테이너 오케스트레이션 : 플릿에서 Kubernetes로 이동 과 연결됩니다 . 플릿은 Container Linux ( 이전의 CoreOS Linux ) 에서 제거되었고 Kubernetes kubelet (에이전트)로 대체되었습니다. 이는 Tectonic (Kubernetes 배포판)을 기본 제품 으로 제공하기위한 기업의 피벗과 일치했습니다 .
