我看到Kubernetes的优点,包括滚动部署,自动健康检查监控,以及在现有服务器出现故障时将新服务器转为动作.我也明白Kubernetes不仅仅适用于Docker.
所以,这带来了几个问题！
当Azure和Service Fabric可以提供我所说的(以及更多)时,为什么我需要Kubernetes？
在Azure上大规模部署使用Kubernetes和Service Fabric是否有意义？
>它们都是与云无关的集群,编排和调度软件.
>它们既可以由您手动部署到任何位置的任何VM集合.
>两者都有“托管”产品,这意味着Azure或Google Cloud等云提供商将为您托管群集,但通常您仍拥有VM.
>他们都部署和管理容器.
>它们都具有丰富的管理操作,例如滚动升级,运行状况检查和自我修复功能.
这是一个相当高级别的视图,但应该让您了解每个可以运行的内容和位置.
现在让我们来看看它们的不同之处.有很多小的差异,但我想关注两个非常大的概念差异：
>应用模型：
> 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是一个有状态平台的事实是理解它以及它与其他主要协调者有何不同的关键.它所做的一切 – 调度,健康检查,滚动升级,应用程序版本控制,故障转移,自我修复等 – 都是围绕这样一个事实设计的：它管理的复制和分布式数据需要始终保持一致且高度可用.
