Kubernetesができない、またはその逆のApache Mesosは何をしますか?
Mesosは2レベルのスケジューラです。確かに、すべてのマシンからリソース情報を取得し、それをkubernetesなどのフレームワークがマシン全体のコンテナをスケジュールできるようにトップレベルのスケジューラーに提供しますが、Kubernetes自体はマシン全体のコンテナをスケジュールできます(この点に関してMesosは不要です)。それでは、Apache Mesosでできること、Kubernetesでできないこと、またはその逆は何ですか?
MesosとKubernetesはどちらもnレベルのコンテナオーケストレーターです。これは、同じ機能を実現できますが、それらの1つである種のタスクを簡単に実行できることを意味します。実際、Mesos上でKubernetesを実行でき、その逆も可能です。
あなたが決定を下す必要があるとき、いくつかの手がかりを与える主な違いを見てみましょう:
あなたが指摘したように、Mesosは2レベルスケジューラであり、これがアーキテクチャの主な違いです。これにより、カスタムスケジューラ(別名フレームワーク)を作成してタスクを実行できます。さらに、複数のスケジューラを使用できます。すべてのスケジューラは、 Dominant Resources Fairness algorithm (カスタム allocator と置き換えることができる)を使用して、公平に分散されたリソースを奪い合います。また、 roles をフレームワークとタスクに割り当て、 weights をこのロールに割り当てて、一部のスケジューラーに優先順位を付けることもできます。ロールは resources で緊密に接続されています。上記の機能により、実行するタスクのタイプに基づいて異なるヒューリスティックを使用して、さまざまなアプリケーション( Fenzo など)に対して独自のスケジューリング方法を作成できます。たとえば、バッチタスクを実行するときは、データの近くに配置するのが適切であり、開始する時間はそれほど重要ではありません。一方、ステートレスサービスの実行はノードに依存しないため、できるだけ早く実行することがより重要です。
Kubernetesアーキテクチャは単一レベルのスケジューラです。つまり、ポッドを実行する決定は単一のコンポーネントで行われます。リソースの提供などはありません。一方、そこにあるものはすべてプラガブルで、レイヤード設計で構築されています。
Mesosは、その規模をサポートするためにTwitter(以前はバークレーで作成されていましたが、最初の制作用途はTwitterでした)で作成されました。
Mesosプロジェクトの約1年後の2010年3月に、Hindmanと彼のバークレーの同僚がTwitterで講演を行いました。最初、彼は失望しました。わずか8人が現れました。しかしその後、Twitterの主任科学者は彼に、8人が多く、会社の全スタッフの約10パーセントであると語った。そして、講演後、そのうちの3人が彼に近づきました。
すぐに、HindmanはTwitterでコンサルティングを行い、Googleの元エンジニアなどと協力してプロジェクトを拡大しました。その後、彼はインターンとして入社しました。そして、その1年後、彼は正社員としてサインオンしました。 ソース
Kubernetesは、ロックインエクスペリエンスがないことを約束してユーザーをクラウドに誘導するためにGoogleによって作成されました。これは、AmazonがKindleで行った手法と同じです。あなたはそれについてどんな本でも読むことができますが、Amazonでそれを使うことはあなたに最高の経験を与えます。 Googleにも同じことが言えます。 Kubernetesは任意のクラウド(パブリックまたはプライベート)で実行できますが、最高のツール、統合、サポートはGoogle Cloudでのみ利用できます。
しかし、GoogleとMicrosoftは違います。 MicrosoftはAzureのすべてをサポートしたいのに対し、GoogleはKubernetesをどこでも必要としています。 (ある意味では、MicrosoftはGoogleよりもすべてのオーケストレーターを吸収し、Borgの名にふさわしい存在です。)まさに文字通り、Kubernetesは、Googleがオンプレミスのクラウドクラウドに対応し、AWS(差別化されたインフラストラクチャをライセンス付きスタックとして販売することはできませんが、VMwareはプライベートクラウドパートナーであると述べていますが、Microsoft(Azure Stackプライベートクラウドはまだ公開されていません)。 ソース
コミュニティの規模だけでプロジェクトを判断することは誤解を招く可能性があります。PHPはコミュニティが大きいため素晴らしい言語であると言っているようです。
MesosコミュニティはKubernetesよりもはるかに小さいです。それが事実です。 Kubernetesは、Google、Intel、Mirantis、RedHatなどを含む多くの大企業からの財政支援を受けており、Mesosは、主にMesosphereによって開発され、Apple、Microsoftからの支援を受けています。 Mesosは成熟したプロジェクトですが、開発は遅くなりますが安定しています。一方、Kubernetesははるかに若いですが、急速に発展しています。
Kubernetesコミュニティ-Ian Lewis、開発者支持者、Google
Mesosは、初期段階から大規模な顧客を対象としていました。 Twitter、Apple、Verizon、Yelp、Netflixで使用され、数千のサーバーで数十万のコンテナーを実行します。
Kubernetesは、開発者にGoogleインフラストラクチャエクスペリエンスを提供するためにGoogleによって開始されました( [〜#〜] giffe [〜#〜] )。当初から、数百台のマシンまでの小規模向けに準備されていました。この制約はリリースごとに増加しますが、小さくなり始めて大きくなりました。 Kubernetesの最大のインストールに関する公開データはありません。
規模の問題により、Kuberntetesは小規模企業(クラウド規模ではない)の間で人気を博し始めましたが、Mesosはエンタープライズユーザーを対象としていました。 KubernetesはCloud Native Foundationによってサポートされ、MesosはApache Foundationプロジェクトです。これら2つの財団には、異なる設立者とスポンサーがいます。一般的に、より多くのお金があなたにより良いマーケティングを与え、Kubernetesは間違いなくそれを正しくしました。
Kubernetesは既にコンテナオーケストレーター戦争で勝利したようです。ただし、カスタムワークロードがあり、本当に大規模な場合は、Mesosが適しています。
主な違いは、コミュニティサイズとオープンソースモデルです。DCOSはMesosphereでサポートされ、商用製品のみでエンタープライズ機能を提供します(mesosphereは慈善家ではないため)。K8Sにはより大きなコミュニティがあり、さまざまな企業からの強い貢献がありますはるかに統合されたエンタープライズ機能(マルチテナンシー、RBAC、クォータ、プリエンプション、ゲートウェイなど)を提供することで、それらは使いやすく、必ずしもDCOSに存在しないわけではありません。私はグローバルにそれを言うでしょう:
- DCOSは、ステートフルおよびビッグデータのワークロードについてより多くのバトルテストが行われていますが、プラグアンドプレイの中央監視とログ記録、セキュリティモデル、マルチテナンシー、自動更新などのエンタープライズ機能など、他の周辺コンポーネントとの統合が不足しています...生産グレードのプラットフォームのすべて。
- K8Sは、ステートレスアプリに対してより多くの戦闘テストが行われ、プロメテウス、EFK、ヘルムなどのプラグアンドプレイツールを多数提供します。これにより、プロダクショングレードプラットフォームの実装がはるかに容易になります。それに続いて、ステートフルセットとmesosフレームワークに匹敵する演算子パターンを備えたステートフルワークロードに大きな動きがありますが、K8Sは多くの機能をすぐに提供するため、より少ないコストでそれらを開発するための多くのツールを提供します。マルチテナントで安全な方法でMongoDBをサービスとして提供するMongoDBオペレーターを開発するのに2か月かかりましたが、同時にGolangを学ぶ必要がありました。