Docker-Swarm、Kubernetes、Mesos、Core-OSフリート

私はこれらすべてに比較的新しいですが、リストされたテクノロジーの中で明確なイメージを得るのに苦労しています。

ただし、これらはすべてさまざまな問題を解決しようとしますが、共通点もあります。共通点と相違点を教えてください。少数の組み合わせが最適である場合、それは何ですか？

私はそれらのいくつかを質問と一緒にリストしていますが、誰かがそれらすべてを詳細にリストして質問に答えてくれるとすばらしいでしょう。

1. KubernetesとMesos：

   このリンク

   ApacheのMesosとGoogleのKubernetesの違いは何ですか

   違いについての洞察は得られますが、KubernetesがMesosの上で実行される理由を理解できません。それは、2つのオープンソースソリューションを組み合わせることと関係がありますか？

2. Kubernetes対Core-OSフリート：

   Kubernetesを使用する場合、フリートは必要ですか？

3. Docker-Swarmは上記のすべてにどのように適合しますか？

開示：私はKubernetesのリードエンジニアです

MesosとKubernetesは、クラスター化されたアプリケーションを実行する際の同様の問題を解決することを主な目的としていると思います。問題を解決するための歴史とアプローチは異なります。

Mesosは非常に一般的なスケジューリングと、複数の異なるスケジューラーのプラグインにエネルギーを集中しています。つまり、HadoopやMarathonなどのシステムを同じスケジューリング環境で共存させることができます。Mesosはコンテナーの実行にあまり重点を置いていません。Mesosは、コンテナーへの関心が広まる以前から存在し、コンテナーをサポートするためにパーツにリファクタリングされています。

対照的に、Kubernetesはコンテナから分散アプリケーションを構築するための環境になるように一から設計されました。これには、コアプリミティブとしてレプリケーションとサービスディスカバリ用のプリミティブが含まれています。Kubernetesの主な目標は、分散システムを構築、実行、管理するためのシステムです。

フリートは、下位レベルのタスクディストリビューターです。これは、クラスターシステムのブートストラップに役立ちます。たとえば、CoreOSは、kubernetesクラスターを起動するために、クラスター内のマシンにkubernetesエージェントとバイナリーを配布するためにそれを使用します。これは、実際の同じ分散アプリケーション開発の問題を解決することを目的としたものではなく、クラスターのsystemd / init.d / upstartのようなものと考えてください。kubernetesを実行する場合は必要ありません。他のツール（Salt、P​​uppet、Ansible、Chefなど）を使用して、同じバイナリ配布を実現できます。

Swarmは、既存のDocker APIを拡張して、マシンのクラスターを単一のDocker APIのように見せるためのDockerによる取り組みです。基本的に、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は完全なボックスコンテナースケーリングソリューションではありませんが、出発点としては適切です。同様に、ある時点で、Apache MesosがKubernetesで機能することを期待できますが、MarathonはKubernetesと同じ役割を果たしているように見えますが、Marathonでは機能しません。これらを読んだどこかで同じ取り組みの一部になる可能性があると思いますが、私はそれについて間違っている可能性があります。それは、メソスフィアの戦略的方向性とそれに対応するKubernetesの原則の採用に関するものです。

DockerConの基調講演で、Solomon Hykesは、Swarmは多くのオーケストレーションおよびスケジューリングフレームワークに共通のインターフェースを提供できる層になると示唆しました。Swarmは、Deisなどの既存のコンテナワークフローフレームワークを使用してスムーズなDockerデプロイメントワークフローを提供するように設計されていますが、Mesosなどの「重い」デプロイメントやリソース管理に対応できる柔軟性があります。

これがお役に立てば幸いです-これは巨大な投稿になる可能性があります。重要なのは、これらは融合して相互運用可能になる可能性が高い、新しく進化するサービスであることですが、それがどのように機能するかを確認するには、次の12か月を乗り切る必要があります。問題について非常に賢い人がいるので、未来はとても明るく見えます。

私が理解している限り：

Mesos、Kubernetes、Fleetはすべて、非常によく似た問題を解決しようとしています。アイデアは、開発者からすべてのハードウェアを抽象化し、「クラスター管理ツール」がすべてを整理するというものです。次に、必要なのは、クラスターにコンテナーを与え、いくつかの情報を与え（永続的に実行し続ける、Xが発生した場合にスケールアップするなど）、クラスターマネージャーがそれを実行することです。

Mesosでは、すべてのクラスター管理を行いますが、スケジューラーは含まれません。スケジューラーは言っているビットです、このプロセスには2つのprocと512MBのRAMが必要です。私はそこに空き容量のあるマシンを持っているので、そのマシンで実行します。Mesosで使用できるプラグインスケジューラはいくつかあります。MarathonとChronosで、独自に作成できます。これにより、リソースの分散やクラスターのスケーリングなどの能力が大幅に向上します。

フリートとKubernetesは、これらの種類の詳細を抽象化するように見えます（そのため、基本的に独自のスケジューラーを作成する必要はありません）。つまり、タスクを定義し、FleetまたはKubernetesで定義された形式/方法で送信する必要があります。その後、タスク（コンテナ）を引き継ぎ、スケジュールします。

だから私は推測します：Mesosを使用すると、独自のスケジューラーを作成するのに少し手間がかかる可能性がありますが、必要に応じて柔軟性が向上する可能性があります。

Mesosの上でKubernetesを実行するアイデアは、KubernetesがMesosのスケジューラーとして機能することだと思います。個人的には、これがどちらか一方を単独で実行することよりどのような利点をもたらすかはわかりません（うまくいけば誰かが飛び込んで説明します！）

MikeBが言ったように..それは初期の段階であり、すべての準備ができている（AmazonのECSにも注目する）ため、多くの競合する標準と多くの重複があります。

-編集-Docker swarmについては、あまり経験がないので触れませんでした。

2017年以降にこれに来る人は誰でも非推奨です。もう使用しないでください。

フリートのドキュメントには、「フリートはCoreOSによって積極的に開発または保守されなくなった」とあり、コンテナオーケストレーションへのリンク：フリートからKubernetesへの移行。フリートはContainer Linux（以前はCoreOS Linuxと呼ばれていました）から削除され、Kubernetes kubelet（エージェント）に置き換えられました。これは、Tectonic（Kubernetesディストリビューション）を主要製品として提供する企業のピボットと一致しました。