Kubernetes + Docker + AWS = Azure + Service Fabricですか？
ローリングデプロイ、自動ヘルスチェックモニタリング、既存のサーバーに障害が発生したときに新しいサーバーを動作させるなど、Kubernetesの利点がわかります。 KubernetesはDockerだけのものではないことも理解しています。
だから、それはいくつかの質問をもたらします！
AzureとService Fabricが私が言ったこと（およびそれ以降）をすべて提供できるとしたら、なぜKubernetesが必要になるのですか？
Azureで大規模なデプロイを行うためにService FabricとともにKubernetesを使用することは理にかなっていますか？
まず、KubernetesとService Fabricの類似点を見てみましょう。
- どちらも、クラウドに依存しないクラスタリング、オーケストレーション、およびスケジューリングソフトウェアです。
- どちらも、手動で、任意のVMセットに、どこにでも手動でデプロイできます。
- 両方に「マネージド」オファリングがあります。つまり、AzureやGoogle Cloudなどのクラウドプロバイダーがクラスターをホストしますが、通常はVMを所有しています。
- どちらもコンテナをデプロイして管理します。
- どちらにも、ローリングアップグレード、ヘルスチェック、自己修復機能などの豊富な管理操作があります。
これはかなり高レベルのビューですが、それぞれで何をどこで実行できるかがわかるはずです。
次に、それらの違いを見てみましょう。小さな違いがたくさんありますが、私は非常に大きな2つの概念的な違いに焦点を当てたいと思います。
アプリケーションモデル：
- Service Fabricを使用すると、任意のコンテナーまたはEXE（それが小さなnode.jsアプリであっても、巨大なレガシーアプリケーションであっても）をオーケストレートできます。その意味では、Kubernetesに似ています。ただし、全体的には、プラットフォームと統合されたプログラミングモデルを使用して、具体的にはアプリケーション開発に重点を置いています。この点で、KubernetesよりもCloud Foundryに近いです。
- Kubernetesは、アプリケーションのインフラストラクチャの調整に重点を置いています。アプリケーションの記述方法に重点を置いていない。それを理解するのはあなた次第です。 Kubernetesはコンテナーの実行を望んでいるだけで、コンテナーの内容は関係ありません。
状態管理
- Kubernetesを使用すると、コンテナーに永続ディスクストレージボリュームを提供し、ポッドに一意の識別子を割り当てることで、ステートフルソフトウェアをデプロイできます。これにより、ZooKeeperやMySQLなどをデプロイできます。
- Service Fabricはステートフルソフトウェアです。 Service Fabricは、ステートフルなデータ対応プラットフォームとして設計されています。 HA状態とスケールアウトプリミティブを提供します。したがって、Kubernetesではステートフルなものをdeployすることができますが、Service Fabricではbuildステートフルなもの。これは、見過ごされがちな重要な違いの1つです。例えば：
- Kubernetesでは、ZooKeeperをデプロイできます。
- Service Fabricでは、Service Fabricのレプリケーションおよびリーダー選出プリミティブを使用して、実際にZooKeeperを自分で構築できます。
- Kubernetesは、クラスターの状態に関する分散型の信頼性の高いストレージにetcdを使用します。
- Service Fabric自体は分散型の信頼性の高いストレージプラットフォームであるため、Service Fabricはetcdを必要としません。 Service Fabricのシステムサービスはこれを利用して、クラスターの状態を確実に格納します。これにより、Service Fabricは完全に自己完結型になります。
Service Fabricがステートフルなプラットフォームであるという事実は、それを理解し、他の主要なオーケストレーターとどのように異なるかを理解するための鍵です。スケジュール、ヘルスチェック、ローリングアップグレード、アプリケーションのバージョン管理、フェイルオーバー、自己修復など、すべての機能は、常に一貫性があり、高可用性が必要な複製および分散データを管理しているという事実に基づいて設計されています。