原标题：说说K8S是怎么来的，又是怎么没的
普元云计算架构师宋潇男点评：
Kubernetes 已在容器编排之战中取胜，未来很可能会成为“多云”之上的标准层，进而为分布式系统的分发和运行带来根本性的改变，而其自身则会慢慢变得像 Linux Kernel 一样，成为一种系统底层的支撑，不再引人注目。
原文的标题是 The Gravity of Kuberrnetes，但是从内容上看，更像是近些年流行的“XXX is 中的垃圾收集，你会知道大量的 Windows 开发者会遇到内存问题，所以他们会购买你的软件。
标准化的专有平台可以给平台提供者创造大量的利润。1995 年，Windows 这个很好的平台让微软能够以 100 美元的价格售出一个只是纸盒子装着的光盘。2018 年，iPhone 这个很好的平台让苹果能够从平台所有的应用销售额中拿走 30%。
但是专有的标准会导致分裂。
当开发者们见到这种分裂时，他们会抱怨。他们会联想到贪婪的资本家，这些资本家为了赚钱，不惜牺牲软件的质量。开发者们会想：“为什么人们不能和谐共处？”为什么我们不能让所有东西开放和免费？
开发者们还会想：“我们不需要专有标准。我们可以拥有开放标准。
Linux 就曾发生过这样的事。现在，大多数新的服务侧应用都在使用 Linux。但曾经有一段时间，人们对此有争议。见上图的左侧远端部分。
最近，我们还看到了一个更新的开放标准：Docker。Docker 给了我们一个开放、标准化的打包、部署和分布单个节点的方法。这极其有价值！但在 Docker 解决的所有大问题之中，有个新的问题非常突出，那就是我们应该如何将这些节点编排到一起？
毕竟，你的应用肯定不只是单个节点。你知道自己希望部署一个 Docker 容器，但是容器应该如何相互通信呢？你如何向上扩展容器实例呢？你如何在容器实例之间路由流量呢?
在 Docker 流行之后，一大批开源项目和专有平台纷纷出现，以解决容器编排的问题。
有些开发者并未采用任何编排平台，而是使用 BASH、Puppet、Chef 和其它工具来为他们的部署编写脚本。
无论一个开发者是否使用编排平台或者脚本来部署容器，Docker 都可以加快开发，并且让开发者和运营之间更加和谐。
随着愈来愈多的开发者使用 Docker 来部署容器，编排平台的重要性日益突出。容器对于分布式系统的重要性就如同对象对于面向对象程序的重要性那样[2]。所有人都希望使用容器平台，但是众多平台之间存在着竞争，很难看出哪个平台会最终胜出，所以这可能会是持续十多年的竞争，就如 iOS 和安卓的竞争那样。
这样的竞争正在制造分裂。这并不是因为流行的编排框架是专有的（Swarm、Kubernetes 和 Mesos 都是开源的），而是因为每个容器编排社区都已经在自己的系统上投入了太多资金。
所以，从 2013 到 2016 年，Docker 用户一直有种隐忧。选择容器编排框架就像一次豪赌，如果你选择了错误的编排系统，这就好像你开了一家影像店，却选择了 高清 DVD，而不是蓝光光碟[3]。
集装箱（container）船倾覆的图片从不过时。图片来源：Huffington 的帖子
容器编排的战争给人感觉就像是一场赢家赢得一切的战争。
正如在所有战争中那样，总是有一层雾，让我们很难看透彼此。在我报道容器编排之战时，我曾用一条条播客记录我和容器编排专家的谈话，其中，我会问到这样的问题，”那么，哪一个容器编排系统会赢？“
我一直这么做，直到某个我十分景仰之人告诉我问这样的问题一点也没有意思，还不如评估一下不同编排商之间的技术权衡。
回首过去，我后悔自己被不同容器编排商之间的战争的故事所吸引。
当有关容器编排商的辩论如火如荼时，甚至是我这样的记者也被这样的情绪激发，并且认为这将是一场与派系斗争有关的故事时，那些最聪明的人大多数却正在进行着平静和科学的谈论。
容器编排之战并非是一场派系斗争，而更多的是观点和开发者工程学之间的差异。
好吧，或许容器编排之战并不只是观点之间的差异。因为这个领域将会创造大量财富。我们现在谈论的是与数十亿市值的老组织如银行、电信公司和保险公司之间的合同，这些组织正在逐步向云迁移。
如果你正在帮助电信公司迁移到正确的平台，那么你的业务会很好。但如果你拥护了错误的平台，最终你只会得到一仓库的高清 DVD。
冲突最严重的时间大约是 2016 年底，那时有关于 Docker 可能出现分歧的传言，原因是因为 Docker 公司想改变 Docker 标准，以更好地适配其容器编排系统 Docker Swarm[4]。但即使在那时，做一个乐观者仍然是明智的。
具有毁灭性的创新会带来痛苦，但它是一个进步的标志。在争取容器编排统治地位的斗争中，出现了许许多多的毁灭性创新。
但在 2016 底迷雾消散之后，Kubernetes 成了明显的获胜者。
今天，随着 Kubernetes 成为保险的选择，CIO 们对在企业中采用容器编排感到更安全了，这也让厂商更愿意投入到 Kubernetes 专用的工具中，并且把这些工具销售给这些 CIO。
- 开源开发者正在朝同样的方向前进，并且为他们能构建的东西感到兴奋。
- 大公司（无论是新还是老）都在逐渐采用 Kubernetes。
- 大型云提供商也准备好迎接低成本的 Kubernetes 即服务。
- 监控、日志记录、安全和合规软件厂商也极为激动，因为他们能更加容易地预测自己要集成的底层软件堆栈了。
今天，盈利最多的专有后端开发者基础设施提供商就是亚马逊 AWS 云服务。开发者并不憎恨 AWS，因为 AWS 是创新和具备使能性的，并且便宜。如果你在 AWS 花了很多钱，那说明你的生意很好。
通过 AWS，开发者不会感到 90 年代时的主导专有平台所给人的那种被锁定的感觉。但仍然有一些锁定感。一旦你深深地扎根于 AWS 的生态系统中，并使用如 DynamoDB、Amazon Elastic Container Service（弹性容器服务）、或 Amazon Kinesis 服务时，你会发现你很难再脱离亚马逊。
然而，由于 Kubernetes 为基础设施创造的是一个开放、共有的层，所以理论上，将你的 Kubernetes 集群从一个云提供商处”迁移到“另一个提供商那里是可行的。
如果你决定迁移你的应用，你需要重写应用的部分组件来停止使用亚马逊特定的服务（如亚马逊 S3）。例如，如果你想要一个可以在任何云上运行的 S3 替代品，你可以配置一个带 Rook[5] 的 Kubernetes 集群，并使用与你在 S3 上使用的相同 API 来存储对象到 Rook 上。
这是一个很好的选项，但是我还从未听说过谁真正地将他们的应用从云中迁走，除了 Dropbox[6] 之外，但他们的迁移是如此宏大，以至于耗费了 2 年半的时间[7]。
当然，除了 Dropbox 之外，肯定还有其他人也在亚马逊 S3 上投入了很多钱，虽然他们也想创造自己的对象存储，但是迁移会非常费力。
Kubernetes 可以被用于迁移应用，但更可能会用于在不同的云之中提供相似的操作层
在不远的将来，Kubernetes 或许不会成为一个广泛用于应用迁移的工具。更可能的情况是 Kubernetes 将会成为一个无所不在的控制平面，企业可以在多个云上使用它。
NodeJS 便是一个有用的类比。为什么人们喜欢 NodeJS 的服务器侧应用？这并不一定是因为 NodeJS 是最快的 web 服务器，而是因为人们喜欢在客户端和服务器上使用相同的语言。NodeJS 可以让你在客户端和服务器节点切换，而无需切换语言，同样，Kubernetes 也能让你在不同的云之间切换，而无需改变运营方式。
在每个云上，你都会有一些定制的应用代码，它们由 Kubernetes 运行，并且与那个云提供的受管服务进行交互。
企业希望多云化，部分是因为容灾的考虑，但还因为访问不同云上的受管服务有实际的好处。
一个新出现的模式是将基础设施分布于 AWS（用于用户流量）和 Google Cloud（用于数据工程）上。Thumbtack[8] 公司正在使用此模式。
是一个存储和查询大量数据的系统。
侧，这些不同的受管服务的编排是由
这就是今天我们常见的现象。Thumbtack 最终或许还会将 Google Cloud 用于面向用户的服务。
某家日本公司采用的多云化的数据工程流水线
越来越多的公司将逐渐迁移至多个云，而且它们当中的某些公司会在每个云上管理独立的 Kubernetes 集群。
云提供商并非可替换的商品。不同的云提供的服务会变得越来越独特和不同。如果可以访问不同的云提供商提供的不同服务，那么企业将因此受益。
Google BigQuery 等 AWS Redshift 服务十分流行，因为它们给了你强大、可扩展和多节点的工具，而且 API 还简单。开发者经常选择这些受管服务，因为它们是如此好用。
针对单个节点的工具比针对分布式系统的工具用起来更容易。相比于在我的笔记本上运行 Ruby on Rails 应用来说，在许多服务器上部署 Hadoop 难多了。然而，有了 Kubernetes 后，这一切都将改变。
如果你正在使用 Kubernetes，你可以使用一个名叫 Helm 的分布式系统包管理器。它就好比是用于 Kubernetes 应用的 npm。如果你正在使用 Kubernetes，无论你使用的是哪个云提供商，你都可以用 Helm 来轻松***一个复杂的多节点应用。
下面是对 Helm 的描述：
Helm 帮助你管理 Kubernetes 应用。Helm Charts 帮助你定义、***和升级 Kubernetes 应用，无论它们有多复杂。Charts 很容易创建、进行版本控制、共享和发布，所以请开始使用 Helm 吧，停止复制 - 粘贴的疯狂举动。
一个用于分布式系统的包管理器。不可思议！让我们看看我们能***的东西。
分布式系统配置很难，不信就去问问配置过 Kafka 集群的人。Helm 将使*** Kafka 像在你的 MacBook 上***新版 Photoshop 那样简单。 而且你可以在任何云上这么做。
在 Helm 之前，最接近分布式系统软件包管理器（就我所知道的）的东西是 AWS[9] 或 Azure[10] 或 Google Cloud Launcher[11] 上的应用市场。在这里，我们再次看到了专有软件如何导致分裂。在 Helm 之前，没有任何一个标准的、与平台无关的一键***
你可以在 AWS、Google 或 Azure 上找到一键*** Kafka 的方法。 但是，这些***中的每个都必须独立编写，以供每个特定的云提供商使用。 而要在 Digital Ocean 上*** Kafka，则需要遵循这个 10 步教程[12]。
Helm 是一个在任何 Kubernetes 实例上分布多节点软件的跨平台系统。 你可以在任何云提供商那里或你自己的硬件上使用已***有 Helm 的应用。 你可以轻松*** Apache Spark 或 Cassandra 系统。众所周知，它们都是难以设置和操作的。
你可以卖什么样的软件？
也许你甚至可以销售像 Zendesk 这样的更高级的消费级软件。
自主托管 Zendesk 的想法听起来很疯狂，但是有人的确可以构建它，并以专有二进制文件的形式出售，以固定费用而不是订阅进行收费。 如果我向你出售价值 99 美元的 Zendesk-for-Kubernetes，并且你可以在 AWS 上的 Kubernetes 集群上轻松运行它，那么你将在工单软件上节省大量支持费用。
企业经常运行自己的 WordPress 来管理公司的博客。 Zendesk 的软件比 WordPress 更复杂吗？ 我不这么认为，但比起管理自己的博客软件，企业更害怕管理自己的 Help Desk 软件。
我经营了一家非常小的公司，但我订阅了很多不同的软件即服务工具。 包括一个昂贵的 WordPress 主机，一个用于广告销售的昂贵的 CRM 软件，和用于通讯简报的 MailChimp。 我支付这些服务是因为它们超级可靠和安全，而且它们也是复杂的多节点应用。 我不想在自己的机房里运行它们。我也不想自己管理它们。 当我的简报发送失败时，我不想自己排除技术故障。我不想运行太多的软件[13]。
相比之下，我并不担心我的单机软件出错。
我在单机软件上的开销往往要便宜得多，因为我不需要把它们作为服务购买。 我用来写音乐的软件有一次性的固定成本。 Photoshop 有一次性固定成本。 我支付电费来运行我的电脑，但除此之外，我不需要持续的资本支出才能运行 Photoshop。
当多节点应用与单节点应用一样可靠时，我们将看到定价模型的变化。
也许有一天我可以购买 Zendesk-for-Kubernetes。 Zendesk-for-Kubernetes 将会给我提供我需要的所有东西 - 它将启动一个电子邮件服务器，它会给我一个网络前端来管理工单。 如果出现任何问题，我可以在需要支持时支付费用。
Zendesk 是一个非常棒的服务，但如果它有一个固定的定价模式，那将会更好。
借助 Kubernetes，部署和管理分布式应用程序变得更加容易。 借助 Helm，将这些应用程序分发给其他用户变得更加容易。 但是开发分布式系统还是相当困难的。
这是 Brendan Burns 最近所作的一篇 CloudNative Con / KubeCon 主题演讲的焦点，那个演讲的题目为 “构建新工具、模式和范例来让分布式系统开发更加大众化的工作实在太难了 [14]”。
云原生开发是定制且复杂的，而且仅限于少数专家开发人员。 Metaparticle 通过在熟悉的编程语言中引入一系列实用程序来改变这种状况，这些实用程序符合开发人员当前的处境，并使他们能够使用熟悉的语言开始开发云原生系统。
Metaparticle 建立在 Kubernetes 原语的基础上，而且它使分布式协调更容易。 Metaparticle 提供独立于语言的模块，用于锁定和主选举，并把这些模块作为熟悉的编程语言中易于使用的抽象。
经过几十年的分布式系统研究和应用，我们如何构建这些系统的模式已经显现。 我们需要一种方法来锁定一个变量，这样两个节点便不能以非确定性的方式写入该变量。 我们需要一种方法来做主选举，以便在主节点死亡时，其他节点可以选择一个新节点来编排系统。
今天，我们使用 etcd 和 Zookeeper 这样的工具来帮助我们进行主选举和锁定，而这些工具都有接入成本。
Brendan 用 Zookeeper 的例子来说明这一点。Hadoop 和 Kafka 都使用 Zookeeper 来做主选举。 你需要花费大量的时间和精力来学习如何操作 Zookeeper。 在构建 Hadoop 和 Kafka 的过程中，这些项目的创始工程师设计的系统可以与 Zookeeper 协作，共同来维护一个主节点。
如果我正在编写一个系统来执行分布式 MapReduce，我希望不考虑节点故障和竞争条件。 Brendan 的想法是将这些问题推到一个标准的库中，从而让下一个开发人员为多节点应用程序提出新想法更加容易。
重要的元点：使用 Metaparticle 的前提是使用 Kubernetes。 Metaparticle 是一个语言层级的抽象，它是建立在对底层（分布式）操作系统的假设之上的。这再一次使我们回到了标准这一话题。 如果每个人都在同一个分布式操作系统上，我们可以对我们项目的下游用户做出更大的假设。
这就是为什么我会被 Kubernetes 洗脑的原因。 它是跨越异构系统的一个标准层。
功能即服务（通常称为“无服务器”功能）是一种功能强大且价格低廉的抽象，开发人员可以与 Kubernetes 一同使用它，在 Kubernetes 之上使用它，或者在某些情况下，单独使用它。
让我们快速回顾无服务器应用程序的现状，然后考虑无服务器和 Kubernetes 之间的关系。
功能即服务的快速回顾[16]：
功能即服务是无需依赖特定服务器运行的可部署功能。
功能即服务旨在部署、执行和扩展开发人员的单个调用。 在你调用无服务器功能之前，你的功能并没有在任何地方运行 - 所以你并未使用任何资源，除了存储原始代码的数据库以外。 当你把一个功能作为服务调用时，你的集群将负责调度和运行该功能。
你不必考虑启动一台新机器并监控该机器，或者在机器闲置时停机。 你只需告诉集群你想要运行一个功能，然后集群将执行它并返回结果。
在部署无服务器功能时，功能代码实际上并未被部署。 你的代码将以纯文本形式保存于数据库中。 当你调用这个功能时，你的代码将从数据库入口中取出，加载到一个 Docker 容器中并执行。
期望得到更多优质技术干货，欢迎加群助手小波波微信（微信 ID：cloud_primeton），与近万名技术人一起在 EAWorld 社群参与定期微课、视频分享、探讨关于 K8S、微服务、DevOps 实践等技术内容。入群暗号：206