是Kubernetes+；Docker&x2B；AWS=Azure+；服务织物？

我看到了Kubernetes的优势，包括滚动部署、自动运行状况检查监控，以及在现有服务器出现故障时启动新服务器。我也明白库伯内特斯不仅仅是为了多克

所以，这带来了几个问题

当Azure和Service Fabric能够提供我所说的一切（以及更多）时，我为什么需要Kubernetes呢

---

将Kubernetes与Service Fabric一起用于Azure上的大规模部署有意义吗？

请在下面找到一篇关于ACS和Azure Service Fabric之间差异的比较文章：

请您澄清一下，当您谈到“AWS”时，您指的是什么

从“开发人员级别”来看，解决方案在这两种情况下都可能是状态化的，但从基础架构的角度来看，它有一个主要区别：

• Docker+Kuberest是一个面向“IaaS”的解决方案
• Azure服务结构（如果您使用的是Azure服务）是PaaS解决方案

一般来说，IaaS的成本更高，维护成本也更高。 从支持的角度来看：

• Microsoft支持Azure服务结构
• Docker和Kubernetest更面向开源

希望这有帮助

---

致以最诚挚的问候

让我们首先看看Kubernetes和服务结构之间的相似之处

• 它们都是云不可知的集群、编排和调度软件
• 它们都可以由您手动部署到任何位置的任何一组VM
• 两者都有“托管”产品，这意味着Azure或Google cloud等云提供商将为您托管一个集群，但通常您仍然拥有虚拟机
• 它们都部署和管理容器
• 它们都有丰富的管理操作，如滚动升级、健康检查和自我修复功能

这是一个相当高层次的视图，但应该让您了解每个视图可以运行的内容和位置

现在让我们看看他们的不同之处。有很多小的差异，但我想重点关注两个真正大的概念差异：

• 应用程序模型：
  • ServiceFabric允许您编排任意容器或EXE（无论是小型node.js应用程序还是大型遗留应用程序），从这个意义上讲，它类似于Kubernetes。但总体而言，它更侧重于应用程序开发，特别是与平台集成的编程模型。在这方面，它比Kubernetes更接近于Cloud Foundry
  • Kubernetes更专注于为应用程序编排基础架构。它并不真正关注如何编写应用程序。这取决于你自己去弄清楚；Kubernetes只想让容器运行，不管里面有什么
• 状态管理
  • Kubernetes通过向容器提供持久磁盘存储卷并为POD分配唯一标识符，允许您向其部署有状态软件。这允许您部署ZooKeeper或MySQL之类的东西
  • 服务结构是有状态的软件。服务结构设计为一个有状态、数据感知的平台。它提供HA状态和扩展原语。因此，虽然Kubernetes允许您部署有状态的东西，但服务结构允许您构建有状态的东西。这是经常被忽视的关键区别之一。例如：
    • 在Kubernetes上，您可以部署ZooKeeper
    • 在ServiceFabric上，您实际上可以使用ServiceFabric的复制和领导者选举原语构建ZooKeeper
    • Kubernetes使用etcd对集群的状态进行分布式、可靠的存储
    • 服务结构不需要etcd，因为服务结构本身是一个分布式、可靠的存储平台。服务结构中的系统服务利用这一点来可靠地存储集群的状态。这使得服务结构完全独立

---

服务结构是一个有状态的平台，这一事实是理解它以及它与其他主要编排器的区别的关键。它所做的一切—调度、运行状况检查、滚动升级、应用程序版本控制、故障切换、自我修复等—都是围绕着这样一个事实而设计的，即它正在管理需要始终保持一致性和高可用性的复制和分布数据

@Downvoter:你能解释一下原因吗？从第5分钟看到第10分钟。回答您问题的精彩幻灯片。但是这个问题太宽泛了，可能会吸引到意见一致的答案，这可以解释为什么会投反对票（顺便说一句，我没有投反对票）。在Service Fabric社区问答期间，有人问了一个类似的问题。它大约从9分钟开始：感谢这些链接，非常有用。：）感谢您的帮助，everyoneAWS（可能）指的是Amazon Web服务。问题似乎是关于这些不同云及其功能之间的比较，而不是使用Azure的IaaS与PaaS之间的比较…谢谢你的反馈，那么我没有真正回答这个问题。无论如何，要做出选择，有关基础设施和相关维护影响的问题似乎是合法的，需要解决。就技术本身而言，Azure Service Fabric是面向状态的，这是其他容器技术（至少在Azure上）的一个关键区别。