azure - Kubernetes + Docker + AWS = Azure + Service Fabric 吗？

Question

我看到了 Kubernetes 的优势，其中包括滚动部署、自动运行状况检查监控以及在现有服务器发生故障时启动新服务器以采取行动。我也明白 Kubernetes 不仅仅适用于 Docker。

所以，这带来了几个问题!

当 Azure 和 Service Fabric 可以提供我所说的所有内容(甚至更多)时，我为什么还需要 Kubernetes？

将 Kubernetes 与 Service Fabric 结合使用在 Azure 上进行大规模部署是否有意义？

Answer 1

我们首先看一下 Kubernetes 和 Service Fabric 之间的相似之处。

• 它们都是与云无关的集群、编排和调度软件。
• 它们都可以由您手动部署到任何位置的任何虚拟机组。
• 两者都有“托管”产品，这意味着 Azure 或 Google Cloud 等云提供商将为您托管集群，但通常您仍然拥有虚拟机。
• 它们都部署和管理容器。
• 它们都具有丰富的管理操作，例如滚动升级、运行状况检查和 self 修复功能。

这是一个相当高级的 View ，但应该让您了解每个可以运行什么以及在哪里运行。

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

• 应用模型:

  • Service Fabric 允许您编排任何任意容器或 EXE(无论是小型 Node.js 应用程序还是大型遗留应用程序)，从这个意义上说，它与 Kubernetes 类似。但总体而言，它更专注于应用程序开发，以及与平台集成的编程模型。在这方面，它更接近于 Cloud Foundry，而不是 Kubernetes。
  • Kubernetes 更专注于为应用程序编排基础设施。它并不真正关注如何您编写应用程序。这取决于你自己去弄清楚； Kubernetes 只需要一个容器运行，并不关心里面有什么。

• 状态管理

  • Kubernetes 允许您通过向容器提供持久磁盘存储卷并向 Pod 分配唯一标识符来部署有状态软件。这使您可以部署 ZooKeeper 或 MySQL 等内容。
  • Service Fabric 是有状态的软件。 Service Fabric 被设计为一个有状态的数据感知平台。它提供 HA 状态和横向扩展原语。因此，虽然 Kubernetes 允许您部署有状态的事物，但 Service Fabric 允许您构建有状态的事物。这是经常被忽视的关键区别之一。例如:
    • 在 Kubernetes 上，您可以部署 ZooKeeper。
    • 在 Service Fabric 上，您实际上可以使用 Service Fabric 的复制和领导者选举原语自行构建 ZooKeeper。
    • Kubernetes 使用 etcd 来分布式、可靠地存储集群状态。
    • Service Fabric 不需要 etcd，因为 Service Fabric 本身就是一个分布式、可靠的存储平台。 Service Fabric 中的系统服务利用它来可靠地存储群集的状态。这使得 Service Fabric 完全独立。

Service Fabric 是一个有状态平台，这一事实对于理解它以及它与其他主要编排器的区别至关重要。它所做的一切——调度、运行状况检查、滚动升级、应用程序版本控制、故障转移、 self 修复等——都是围绕这样一个事实设计的:它正在管理需要始终保持一致和高度可用的复制和分布式数据。