Dockerコンテナを使用したDC / OS上のMarathon対Kubernetes対Docker Swarm
DC/OSでDockerコンテナを実行する際に、MarathonとChronos、Docker Swarm、Kubernetesのどれに賛否両論を求めています。
たとえば、KubernetesよりもMarathon/Chronosを使用する方が適切な場合と、その逆の場合はいつですか？
今は主に実験に取り組んでいますが、これらのサービスのいずれかを夏以降に実稼働で使用できるようになることを願っています。これでDocker Swarmが失格になる可能性があります。それまでに生産準備が整うかどうかわかりません。
私がDocker Swarmで気に入っているのは、本質的には単に「Dockerコマンド」であり、まったく新しいことを学ぶ必要がないということです。すでにdocker-composeを使用していますが、これはDocker Swarmですぐに動作します（少なくとも理論上）ので、大きなプラスになります。 Docker Swarmでの私の主な懸念は、実稼働でシステムを実行するために必要なすべてのユースケースをカバーするかどうかです。
Mesosの各コンテナオーケストレーションフレームワークのユニークな側面を分析します。
Docker Swarm を使用する場合：
- 使い慣れたDocker APIを使用して、MesosでDockerコンテナーを起動します。
- Swarmは、最終的にKubernetes（K8s-Mesosでも）と通信するためのAPIを提供する可能性があります。
- 参照： http://www.techrepublic.com/article/docker-and-mesos-like-peanut-butter-and-jelly/
Kubernetes-Mesos を使用する場合：
- K8sポッドを起動します。K8sポッドは、一緒にスケジュールされ、一緒に配置され、リソースを共有するコンテナーのグループです。
- 親コンテナの隣にある1つ以上のサイドキックコンテナ（ログアーカイバ、メトリックスモニタなど）とともにサービスを起動する場合。
- K8sラベルベースのサービス検出、負荷分散、およびレプリケーション制御を使用します。
- http://kubernetesio.blogspot.com/2015/04/kubernetes-and-mesosphere-dcos.html を参照してください
マラソン を使用する場合：
- DockerまたはDocker以外の長時間実行アプリ/サービスを起動したい。
- 制約ベースのスケジューリングにMesos属性を使用します。
- アプリケーショングループと依存関係を使用して、関連するサービスを起動、スケーリング、またはアップグレードします。
- 正常性チェックを使用して、異常なサービスを自動的に再起動するか、異常な展開/アップグレードをロールバックします。
- サービス検出のためにHAProxyまたはConsulを統合します。
- Web UIまたはREST APIを介してアプリを起動および監視したい場合。
- Mesosを念頭に置いて最初から構築されたフレームワークを使用します。
Chronos を使用する場合：
- 終了すると予想されるDockerまたは非Dockerタスクを起動します。
- 特定の時間/スケジュール（la
cron）で実行するタスクをスケジュールします。 - 依存タスクのDAGワークフローをスケジュールします。
- Web UIまたはREST APIを介してジョブを起動および監視したい場合。
- Mesosを念頭に置いて最初から構築されたフレームワークを使用します。
少し時代遅れですが、基本を正しく理解するために ApacheのMesosとGoogleのKubernetesの違いは何ですか を読むと役立つかもしれません。また、MesosはKubernetes/Marathon/Chronosとは異なるレベルで動作することに注意してください。最後になりましたが、マラソンとSwarmが同じMesosクラスター上で同時に動作できることに留意して、Timothy Chenによる Docker Swarm + Mesos を参照してください。