Docker-Swarm、Kubernetes、Mesos、およびCore-OSフリート
私はこれらすべてに比較的慣れていませんが、リストされているテクノロジーの中で明確な状況を把握するのに苦労しています。
ただし、これらはすべて異なる問題を解決しようとしますが、共通点もあります。よくあることと違うことを理解したいと思います。少数の組み合わせが適切である可能性が高いと思われますが、そうであればそれらは何ですか？
それらのいくつかを質問とともにリストしていますが、誰かがそれらのすべてを詳細にリストし、質問に答えるのは素晴らしいことです。
Kubernetes対Mesos：
このリンク
は違いについての良い洞察を提供しますが、KubernetesがMesosの上で実行される理由を理解することはできません。 2つのオープンソースソリューションを組み合わせることと関係がありますか？
Kubernetes対Core-OSフリート：
Kubernetesを使用する場合、フリートは必要ですか？
Docker-Swarmは上記のすべてにどのように適合しますか？
開示：私はKubernetesのリードエンジニアです
MesosとKubernetesは、クラスター化されたアプリケーションの実行に関する同様の問題を解決することを主な目的としていると思います。それらは異なる問題を解決するための異なる歴史とアプローチを持っています。
Mesosは、非常に汎用的なスケジューリングと、複数の異なるスケジューラーのプラグインにエネルギーを集中しています。つまり、HadoopやMarathonなどのシステムが同じスケジューリング環境で共存できるようになります。 Mesosは、コンテナの実行にあまり焦点を合わせていません。 Mesosは、コンテナへの広範な関心の前に存在し、コンテナをサポートするために部品にリファクタリングされました。
対照的に、Kubernetesは、コンテナから分散アプリケーションを構築するための環境になるようにゼロから設計されました。コアプリミティブとしてレプリケーションおよびサービスディスカバリ用のプリミティブが含まれていますが、そのようなものはMesosのフレームワークを介して追加されます。 Kubernetesの主な目標は、分散システムを構築、実行、管理するためのシステムです。
フリートは低レベルのタスクディストリビューターです。これは、クラスターシステムのブートストラップに役立ちます。たとえば、CoreOSは、それを使用して、kubernetesクラスターを起動するために、クラスター内のマシンにkubernetesエージェントとバイナリを配布します。同じ分散アプリケーション開発の問題を解決することを意図したものではなく、クラスターのsystemd/init.d/upstartのようなものだと考えてください。 kubernetesを実行する場合は必要ありません。他のツール（Salt、Puppet、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に参加してください。
最も単純な答えは、単純な答えはないということです。 Swiftがコンテナーの威力を高め、特にDockerは、「コンテナーのスケジューリングとオーケストレーション」のために、それが意味するものは何でも、パワーの空白を残しています。実際には、いくつかのレベルで調和しながら機能することができますが、競争の特定の側面を持ついくつかの技術を持っていることを意味します。たとえば、Kubernetesは（Googleが最初に設計したように）コンピューティングクラスターにコンテナーを展開および管理するためのワンストップショップとして使用できますが、FleetがCoreOSで提供する復元層を利用してFleetの上に配置することもできます。
このGoogle vidが述べているように Kubernetesは完全なボックスコンテナースケーリングソリューションではありませんが、開始するのに適したステートメントです。同様に、MarathonがKubernetesと同じ役割を果たしているように見える限り、Apache MesosがKubernetesと連携できるが、Marathonと連携できないことを期待するでしょう。私はどこかでこれらを読んだことが同じ努力の一部になるかもしれないと思うが、それについて間違っているかもしれない-それはメソスフェアの戦略的方向性とそれに対応するKubernetesの原則の採用に関するものだ。
ソロモンハイクスは、DockerCon基調講演で、Swarmは多くのオーケストレーションおよびスケジューリングフレームワークに共通のインターフェイスを提供できる層になると示唆しました。私が見ることができることから、SwarmはスムーズなDockerデプロイメントワークフローを提供するように設計されており、Deisなどの既存のコンテナワークフローフレームワークと連携しますが、Mesosなどの「ヘビーウェイト」デプロイメントとリソース管理に十分な柔軟性を備えています。
これが役立つことを願っています-これは巨大な投稿になる可能性があります。重要なのは、これらが統合されて相互運用可能になる可能性のある若い、進化しているサービスであると思いますが、今後12か月間試して、その効果を確認する必要があります。この問題については非常に賢い人がいるので、将来は非常に明るいようです。
私が理解する限り：
Mesos、Kubernetes、およびFleetは、非常によく似た問題を解決しようとしています。アイデアは、開発者からすべてのハードウェアを抽象化し、「クラスター管理ツール」がそれをすべて整理するというものです。その後、必要なことは、コンテナをクラスターに提供し、それに情報を与えて（永続的に実行し続ける、Xが発生した場合にスケールアップするなど）、クラスターマネージャーがそれを実現することです。
Mesosでは、すべてのクラスター管理を行いますが、スケジューラーは含まれません。スケジューラは、このプロセスには2つのprocと512MBのRAMが必要であり、その上に空きがあるマシンがあるので、そのマシンで実行します。 MesosではMarathonとChronosのプラグインスケジューラを使用できます。独自のスケジューラを作成できます。これにより、リソースの分散やクラスターのスケーリングなどの強力な機能が提供されます。
FleetとKubernetesは、これらの種類の詳細を抽象化するようです（したがって、基本的に独自のスケジューラを記述する必要はありません）。つまり、タスクを定義し、FleetまたはKubernetesで定義された形式/方法でタスクを送信する必要があります。その後、タスク（コンテナ）を引き継いでスケジュールします。
Mesosを使用すると、独自のスケジューラを作成するのに多少の作業が必要になりますが、必要に応じて柔軟性が向上する可能性があります。
Mesos上でKubernetesを実行するという考えは、KubernetesがMesosのスケジューラとして機能することだと思います。個人的には、これがどちらか一方を単独で実行することで得られる利点はわかりません（誰かが飛び込んで説明してくれることを願っています！）
MikeBが言ったように..それはまだ初期の段階であり、それはすべてアマゾンのECSにも目を光らせているので、多くの競合する標準と多くの重複があります！
-編集-Docker swarmはあまり経験がないので言及しませんでした。
2017年以降にこれにアクセスする場合は、フリートは廃止されます。もう使用しないでください。
フリートドキュメント 「フリートはもはやCoreOSによって積極的に開発または保守されていません」と言い、 コンテナオーケストレーション：フリートからKubernetesへの移行 にリンクします。 FleetはContainer Linuxから削除され（ 以前のCoreOS Linux ）、Kubernetes kubelet（エージェント）に置き換えられました。これは、主な製品として Tectonic （Kubernetesディストリビューション）を提供する企業の中枢と一致しました。