Kubernetes + Docker + AWS = Azure + Service Fabric吗? [英] Is Kubernetes + Docker + AWS = Azure + Service Fabric?

问题描述

我看到了Kubernetes的优势，其中包括滚动部署，自动运行状况检查监视以及在现有服务器发生故障时让新服务器运行.我也确实了解到Kubernetes不仅仅适用于Docker.

I see advantages of Kubernetes which include Rolling Deployments, Automatic Health check monitoring, and swinging a new server to action when an existing one fails. I also do understand that Kubernetes is not just for Docker.

因此，带来了两个问题！

So, that brings a couple of questions!

当Azure和Service Fabric可以提供我所说的一切(以及以后)时，为什么我需要Kubernetes?

When Azure, and Service Fabric could provide all that I said (and beyond), why would I need Kubernetes?

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

Would it make sense for one to use Kubernetes along with Service Fabric for large scale deployments on Azure?

推荐答案

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

Let's look first at the similarities between Kubernetes and Service Fabric.

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

这是一个相当高级的视图，但应该让您了解可以分别使用哪些内容和在哪里运行.

That's a fairly high-level view but should give you an idea of what and where you can run with each.

现在让我们看看它们的不同之处.有很多细微的差异，但我想着重介绍两个真正的大概念差异:

Now let's look where they're different. There are a ton of small differences, but I want to focus on two of the really big conceptual differences:

• 应用程序模型:

• Service Fabric允许您编排任意容器或EXE(无论是小型的node.js应用程序还是大型的遗留应用程序)，从某种意义上讲，它类似于Kubernetes.但是总的来说，它更专注于应用程序开发，并且与平台集成了编程模型.在这方面，它比Kubernetes与Cloud Foundry具有更紧密的可比性.
• Kubernetes更加专注于为应用程序编排基础架构.它并没有真正专注于如何编写应用程序.由您自己决定； Kubernetes只是想运行一个容器，而不管其中的容器是什么.

• Service Fabric allows you to orchestrate any arbitrary container or EXE (whether that's a small node.js app or a giant legacy application), and in that sense it is similar to Kubernetes. But overall it is more focused on application development specifically, with programming models that are integrated with the platform. In this respect, it is more closely comparable to Cloud Foundry than Kubernetes.
• Kubernetes is focused more on orchestrating infrastructure for an application. It doesn't really focus on how you write your application. That's up to you to figure out; Kubernetes just wants a container to run, doesn't matter what's in it.

状态管理

• 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完全是独立的.
  • Kubernetes allows you to deploy stateful software to it, by providing persistent disk storage volumes to containers and assigning unique identifiers to pods. This lets you deploy things like ZooKeeper or MySQL.
  • Service Fabric is stateful software. Service Fabric is designed as a stateful, data-aware platform. It provides HA state and scale-out primitives. So while Kubernetes allows you to deploy stateful things, Service Fabric allows you to build stateful things. This is one of the key differences that's often overlooked. For example:
    • On Kubernetes, you can deploy ZooKeeper.
    • On Service Fabric, you can actually build ZooKeeper yourself using Service Fabric's replication and leader election primitives.
    • Kubernetes uses etcd for distributed, reliable storage about the state of the cluster.
    • Service Fabric doesn't need etcd, because Service Fabric itself is a distributed, reliable storage platform. The system services in Service Fabric make use of this to reliably store the state of the cluster. This makes Service Fabric entirely self-contained.

    Service Fabric是一个有状态的平台，这一事实对于理解它以及它与其他主要协调器之间的区别至关重要.它所做的一切(计划，运行状况检查，滚动升级，应用程序版本控制，故障转移，自我修复等)都是围绕以下事实进行设计的:它正在管理复制的和分布式的数据，这些数据必须始终保持一致且高度可用.

    The fact that Service Fabric is a stateful platform is key to understanding it and how it differs from other major orchestrators. Everything it does - scheduling, health checking, rolling upgrades, application versioning, failover, self-healing, etc - are all designed around the fact that it is managing replicated and distributed data that needs to be consistent and highly available at all times.

    这篇关于Kubernetes + Docker + AWS = Azure + Service Fabric吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！