Kubernetes 和 Service Fabric 之间的区别

您可以在此项目中看到paolosalvatori/service-fabric-acs-kubernetes-multi-container-app在 Service Fabric 和 Kubernetes 中实现的相同容器。

它们的“服务”（用于外部入口访问）是不同的，Kubernetes 更加完整和多样化：参见 Services。

现实情况是：由于市场压力，存在“两种略有不同的产品”。
最初于 2010 年发布的 Microsoft Azure platform 已经实施了自己的 Microsoft Azure Fabric Controller，以确保如果 Microsoft 数据中心内的一台或多台服务器发生故障，则服务和环境不会发生故障Microsoft 数据中心，它还提供对用户 Web 应用程序的管理，例如内存分配和负载平衡。

但为了在他们自己的 Microsoft 数据中心上吸引其他客户，他们必须适应最初于 2014 年发布的 Kubernetes，现在 (2018) 已被...采用或密切考虑...几乎每个人（如reported in late December）
（这并不意味着一个比另一个“更好”，
只是“另一个”比第一个更“可见”；））

因此，与其说是“两者之间的详细区别”，不如说是在微软数据中心上集成基于 Kubernetes 的系统的能力。

这与 Microsoft 继续向 Azure (with Deis) 的开放（阅读：非专有）暂存平台前所未有的转变是一致的（来源：detailed here）。
和Kubernetes orchestrator is available on Microsoft's Azure Container Service since February 2017。

您可以在部署的应用程序的架构中看到其他差异：

服务结构：

https://i.stack.imgur.com/0IKfQ.png

比。 Kubernetes：

https://i.stack.imgur.com/eqvFr.png

thieme 提及in the comments来自 Marcin Kosieradzki 的文章“Service Fabric and Kubernetes comparison, part 1 – Distributed Systems Architecture”。

---

两者是不同的。 Kubernetes 管理 rkt 或其他容器。

Service Fabric 不适用于管理容器。如果它管理一些，那并不能使它成为它的目的。这并不能与 Kubernetes 进行比较。

例如：当一个 pod 死掉时，Kubernetes 会立即将它放到其他节点上。 SF 中管理容器的部分不这样做，它是由 Service Fabric 的其他一些区域来完成的。和外部容器。并且在设计时并未考虑到容器。

---