上世纪70年代末，生态系统这个术语首次运用于计算机行业，这个比喻用来解释苹果II软件这个新兴领域所出现的情况。在那之前，几乎所有软件都是由对应计算机的厂商独家分销的。但是苹果完全意识到了独立软件开发商（ISV）的存在，其中一些ISV用拉链袋来包装软盘，相关的操作说明打印在彩色美术纸上。苹果认识到各有关方（包括它自己）之间的关系对每个人互惠互利后，这家计算机厂商打造出了全球的第一个生态系统。

近四十年后，几乎每个计算平台的目的是打造各自的生态系统――这种经济体围绕一种产品形成起来，开发支持该产品的产品/服务的人员或厂商反过来又得到该产品的支持。Kubernetes社区的许多领袖奉行的一个理念是，实行排他性有悖于生态系统的立足之本：支持。

重新发明轮子没有意义

谷歌的首席软件工程师蒂姆·霍金（Tim Hockin）说：“Kubernetes是最典型的平台。对于你使用哪种监控解决方案，Kubernetes绝不该抱有一种固执己见的态度。与过去一样，说到这种决定，我们应该完全保持中立，我致力于继续保持中立。我认为，去跟潜在的采用者说‘不光要安装这种Kubernetes工具（这本身有好几种产品），还要把你的所有监控工具换成Prometheus，把所有日志工具换成Fluentd――顺便说一下，你还要使用gRPC和OpenTracing’，这是难以为继的。这根本就行不通。”

霍金继续说：“Kubernetes是一种可插入式系统，可以说有意这样，那样你可以将多个解决方案整合到其里面。现在，由于Prometheus之类的工具是整个大家族的一员，我希望，人们会把Prometheus看成是某种云原生的行事方式。要是人们没有现有的监控解决方案，他们可以关注CNCF（云原生计算基金会）在开发的其他技术，并考虑那些技术。不过请注意，我指的是‘考虑’，而不是‘被迫采用’。”

CNCF确实在制作自己的生态系统图，名为Cloud Native Landscape。你很容易在这个图上找到Docker，Kubernetes就在“Scheduling&Orchestration”（调度及编排）表上，在该表上的还有Docker Swarm、Mesos、Nomad和亚马逊弹性容器服务（现在名为EC2 Container Service）。

不过，本章节的目的在于直观地描述专门围绕Kubernetes而形成的这个生态系统的发展现状。有人可能提出这个有力的观点：容器生态系统几乎完全是在Docker的推动下缔造起来的。虽然许多组织声称为划分的命名空间或可移植的工作负载这类概念作出了贡献，但只有一家logo为庞大蓝色鲸鱼的组织（Docker）得到了公认。

工作负载调度和编排其实并不是Kubernetes发明的，但是它的确首次对这个概念采取了独特的方法，能够让进程间通信和可扩展性达到一定的级别，又易于实施，而Docker凭一己之力未能做到这点。

由于众多企业采用Kubernetes作为平台、乃至作为一套方法，而不仅仅是另一种工具，它确实需要被认为是一系列广泛的可互换工具的起源。蒂姆·霍金的观点是，绝不能将这个平台视为企图通过单一的工具集，实行单一的工作方式。不妨把它看成是一种操作系统，有通过认证的软件和获得许可的扩展库。

持续集成/持续交付平台提供商Codeship的技术主管劳拉·弗兰克（Laura Frank）让这个概念更进了一步：她认为，生态系统的一个核心问题是，除非开发人员先能够从生态系统得到好处，否则别指望他们会通过自己开发的工具来推动生态系统的发展。

弗兰克告诉我们：“我很务实，始终使用现有的工具，而不试图自行编写工具。坦率地说，由于Kubernetes具有滚动更新、自我愈合的特性，我编不出一种更好的解决方案。我认为，试图重新发明累子是没有意义的。我认为，完全可以依赖Kubernetes获得诸如此类的现有工具，而不是试图使它们实现自动化，或者甚至自行编写。我认为，依赖工具、尤其依赖开源工具很好，因为我认为‘你不是谷歌，所以你没有谷歌那样的大问题’这个观点其实再也行不大通了。”

她继续说：“Kubernetes有一个非常丰富的生态系统，开源社区紧紧围绕着它，它不仅仅代表一家公司的利益。它其实是许多不同行业之间的合作，大大小小的技术团队和组织走到一起，开发可协同运行、确保使用场合尽量广泛的产品。”

DevOps管道

图2描述了Kubernetes生态系统的现状。

这张图有点不平衡。那并不是意外，绝不是。之所以存在那些遗漏，并不是由于我们匆忙刊发这份电子书。虽然许多人纷纷紧跟潮流，宣传Kubernetes是一套完整的开发运维（DevOps）生命周期管理框架，但是如果我们划分DevOps管道，以便以开发为中心的工具趋向左边，以运维为中心的工具趋向右边，那么生态系统中的工具往往趋向右边。

这不是某种生态系统缺陷。你实际上并不用Kubernetes来创建和部署微服务，就像你并不用煮锅煎鸡蛋、把鸡蛋摊开来那样。有许多独立的开发环境适用于此。Docker就可用于将开发的产品包装到可移植的容器中。Kubernetes社区正在开发一套名为CRI-O的工具集，用于在标准引擎中试运行先前已有的容器。但是它并不取代Docker。CRI-O并不创建容器镜像。、

我们在DevOps管道的“Create”（创建）这栏下面所列的几个包括Telepresence（这种本地开发环境用于构建在Kubernetes中试运行的微服务）以及rkt和containerd运行时环境，后面两个现在都是CNCF的项目。Codeship出现在了管道的“Package”（包装）和“Release”（发布）这两个阶段，这时候你将微服务与持续部署模式整合起来。

管理平台出现在“Configure”（配置）这栏：这类系统不是诸如OpenShift之类的端到端生命周期管理系统，而是以Kubernetes本身并未提供的增值服务这种形式提供给客户。然后“Monitor”（监控）这栏显示了许多日志、监督和监控工具及平台，它们有的被并入到Kubernetes系统中（比如Fluentd统一日志层），有的可以从外面插入到Kubernetes（比如New Relic APM、AppDynamics、Dynatrace、Sysdig和VMware Wavefront。）许多这些监控平台的历史比Kubernetes还要早几年，不过它们无疑被该平台强大的影响力吸引进来。

图2的最下面是支持Kubernetes的基础设施服务，比如Quay容器部署平台、Nuage Networks的SDN和Twistlock容器安全平台。

Twistlock的首席技术官约翰·莫雷洛（John Morello）说：“保护容器安全与保护虚拟机安全之间其实有几个不同的根本性差异。外头有好多缺乏根据的文章，称容器是虚拟机的下一个进化阶段。虽然它们肯定有一些相似之处，但使用场合以及核心技术大不一样。如果你认为容器是某种微型虚拟机，难怪会有一系列偏见和假设，其实是不正确的。”

莫雷洛表示，一个容器化、分布式的应用程序有大量的小实体，即众多对象。相比之下，从开发人员的角度来看，正在构建的应用程序可能仍是单一实体。这可以解释如今的Kubernetes DevOps管道会显得有点不平衡：等到应用程序进入到生产阶段，它变得不太像是构件（construct），而更像是全体（population）。

支持级别

图3列出了可用的软件包和服务，你能够通过它们获得或购买Kubernetes，或者购买Kubernetes的支持。

我们分成以下几类：

●社区支持的发行版是免费开源软件包，你可以借助这些软件包自行部署平台，并试运行一下。Minikube是一种真正的Kubernetes环境，适合单一计算机上的本地试验型部署。

图3：Kubernetes平台发行版的几种类别

●开发商发行版（无增值服务）显示了交付软件解决方案或基于云的平台的公司，这类解决方案或平台包括纯粹的Kubernetes以及开发商提供的支持。

●开发商发行版（有增值服务）显示了提供更全面的环境的公司，包括调度、开发和生命周期管理，Kubernetes是这类公司的系统的核心。

●应用平台/PaaS显示了全面的平台即服务，包括Red Hat OpenShift，它们实际上抽取掉了Kubernetes的管理和维护这一块，隐藏在端到端、自动化的开发和部署环境后面。

如果读者有兴趣了解更详细的介绍，不妨看一下这份经常更新、社区管理的Kubernetes发行版列表（https://docs.google.com/spreadsheets/d/1LxSqBzjOxfGx3cmtZ4EbB_BGCxT_wlxW_xgHVVa23es/edit#gid=0）。

Red Hat的Kubernetes和OpenShift产品经理布赖恩·格雷斯利（Brian Gracely）告诉我们，他预计，随着含有Kubernetes的平台（比如Red Hat平台）越来越流行起来，客户对Kubernetes可能反而习以为常。

格雷斯利问道：“最后这多少归结为，你打造的商业模式是不是围绕最终确实变得无聊乏味（boring）的概念？然后你选择在它上面还是围绕它来打造某种差异化优势。眼下我们看到，一个非常健康的生态系统依托众多公司，这些公司想成为这个数字化转型时代（云原生应用）的一员，这很棒。我们看到大家从不同的角度来看待Kubernetes。Red Hat将它作为软件来交付；我们还通过OpenShift Online，将它作为服务来交付。我们看到各大云提供商拿来Kubernetes后做成谁都可以使用的服务――这是一种新的商业模式，这种模式很好。”

他继续说：“我认为，眼下Kubernetes生态系统仍处于早期，这一点也没错。仍有大量的爆炸式创新在进行，很酷的想法层出不穷。但如果你跟Kubernetes这方面投入大量技术人才的公司聊一聊，比如Red Hat、微软、谷歌、英特尔、华为和IBM，我们的目的是，最终我们希望核心技术很稳定。人们会以不同的方式进入市场。没错，五年后，也许我们不会称之为‘Kubernetes生态系统。’但如果我关注Kubernetes，有人说‘嗯，它正在变成有点无聊乏味的技术’，我觉得那未尝不是件好事。这恰恰证明了Kubernetes成熟起来。”

版权声明：

凡本网内容请注明来源：T媒体（http://www.cniteyes.com）”的所有原创作品，版权均属于易信视界（北京）信息科技有限公司所有，未经本网书面授权，不得转载、摘编或以其它方式使用上述作品。

本网书面授权使用作品的，应在授权范围内使用，并按双方协议注明作品来源。违反上述声明者，易信视界（北京）信息科技有限公司将追究其相关法律责任。