本周，一年一度的KubeCon + CloudNativeCon北美2018年活动在西雅图举行，这将给云计算行业一个机会，评估Kubernetes已经走了多远。

另一方面，该展览还将讨论可能会阻碍这个开源容器编排平台实现其全部潜力的问题。

2018年，Kubernetes一直是高科技领域的一个标志性故事，未来几年，该技术似乎将继续保持其普及的势头。库贝内兹的生态系统已经变得异常活跃，尽管这是一把双刃剑。

供应商对Kubernetes的商业采用一直是今年云计算领域的主导故事，这要归功于它让企业更容易部署容器。容器是一种软件，可以让应用程序一次性编写，并部署在从内部数据中心到公共云的许多计算机环境中。Kubernetes成熟的一个明显标志是围绕它成长起来的丰富的开源项目生态系统。这些项目包括监视(Prometheus)、服务代理(Envoy)、远程过程调用(remote procedure call, gRPC)、集装箱网络接口(container network interface, CNI)、基于dna的服务发现(service discovery, CoreDNS)、打包环境(packaging environment, Helm)等等。

Kubernetes日益增长的主导地位的另一个标志是企业的迅速普及。云计算基金会(TheCloud Native Computing Foundation)最近发布的半年度企业用户调查报告显示，自2017年12月以来，企业对云计算原生技术的使用增长了200%以上。Kubernetes无疑是容器管理的首选，83%的受访者表示，他们将其用于私有、公共、混合或多云部署。约40%的企业受访者表示，他们目前正在生产Kubernetes。

在云计算供应商中，Kubernetes是一个关键的竞争焦点。所有领先的公共云提供商都对这项开源技术进行了大量投资。亚马逊网络服务公司(Amazon Web Services Inc.)、微软公司(Microsoft Corp.)、谷歌LLC、IBM Corp.、甲骨文公司(Oracle Corp.)和阿里巴巴控股有限公司(alibaba Holding Co. ltd .)都有各自的Kubernetes引擎，doRed Hat Inc.、思科系统公司(Cisco Systems Inc.)、VMware Inc.和其他公司也是如此。

然而，采用Kubernetes的企业现在正在一个不断发展的开放源码项目的雷区中前进，这些项目仍然没有形成一个成熟的、与供应商无关的堆栈，它解决了用于云计算的广泛的生产级企业应用程序用例。

Kubernetes的生态系统有多混乱?Kubernetes的核心开源平台已经变成了一个令人眼花缭乱的领域，有几十个供应商调整的发行版和托管的云实现。不仅如此，那些建立在谷歌催生的Kubernetes基础上并对其进行补充的不断深化的开源项目更是让人摸不清头脑。

很多，但远远不是所有的，与开放源码容器相关的项目都在云本地计算基金会的范围内，除了Kubernetes之外，只有少数几个。最值得注意的是，Prometheus项目的监测和Envoy项目的代理已经“升级”为类似于标准化的项目。

但是，不同的子项目之间的分离成功还没有出现。因此，采用基于kubernetas的解决方案的企业将面临这样的风险，即在一两年后市场动荡时，它们可能需要进行“拆解和替换”迁移活动，而我们都知道，目前那些有前途的开源项目已经从业界的视野中消失了。

甲骨文最近努力“策划”一组核心的CNCF项目——包括毕业项目和其他项目——是值得称赞的。但是考虑到这仅仅是一家公司的事情，如果云计算希望成熟到可以为任何对任何容器的微服务进行编排，那么它并没有为这个堆栈带来急需的跨行业一致性做多少工作。而且，它也无法开始保护不断增长的攻击面，这些攻击面在庞大的异构多厂商、联邦和碎片化的Kubernetes发行版、版本和工具中暴露自己，而这些发行版、版本和工具遍布整个多云。

然而，Kubernetes的开源平台显示出成熟的迹象。根据source{d}最近的源代码分析，目前版本1.13中的核心Kubernetes代码库正在稳定下来。

2018年，库贝内兹核心项目的捐款总额有所下降。核心Kubernetes项目的提交速度正在减慢。cncf管理的Kubernetes核心代码库随着时间的推移稳定在大约175万行代码，而它的公共应用程序编程接口端点稳定在大约1.6万行代码。与此同时，中国创新基金会对Kubernetes特殊利益集团和孵化器项目的捐助也在放缓。

但这并不意味着Kubernetes生态系统的创新正在减弱。{d}研究的来源还表明，更多的创新来自于Kubernetes相关的项目，这些项目正在CNCF之外的外部GitHub组织中进行管理。在这个更大的Kubernetes生态系统中，最近的许多活动包括开发集群联合、容器运行时、支持可伸缩的工作负载管理(用于高性能计算和机器学习)和弹性负载平衡。

在商业化方面，很明显，在Kubernetes的核心生态系统项目上，供应商并没有放慢构建云计算环境的步伐。与此同时，许多最活跃的云计算解决方案提供商也在扩展他们自己的新的开源项目，以满足CNCF社区项目核心范围之外的需求。

例如，考虑AWS最近发布的acker，这是一个轻量级的开源虚拟机监视器，它使用基于Linux内核的虚拟机或KVM。在无服务器的云中，爆竹支持创建和管理安全的多租户容器和Lambda函数。它使当前流行的容器运行时(如containerd)能够将容器管理为微vm。通过这种方式，它允许开发人员利用虚拟机的工作负载隔离，同时获得在Kubernetes backplane上运行的容器的效率。

通过Apache v2.0许可并可从thisGitHub repo下载，爆竹被设计来优化无服务器环境的瞬态和无状态工作负载特性。AWS Lambda使用爆竹作为配置和运行沙箱的基础，公共云提供商在沙箱上执行客户代码。

爆竹提供了一个安全的设备模型，减少内存占用和攻击表面积，同时在每个服务器上提供高密度的微vm。它的最小设备模型使启动时间更快(i3上少于125毫秒)。金属与默认的微vm大小)，同时减少攻击面。它可以在一台机器上包装数千个微vm。用户可以访问它的进程内速率限制器来控制网络和存储资源如何共享，甚至在数千个微vm之间共享。

Wikibon发现，关于鞭炮最值得注意的是AWS将Kubernetes容器化与无服务器和虚拟化范例更紧密地结合在一起的方式。这并不是CNCF Kubernetes核心项目的主要关注点，尽管在所有这些技术上投资的企业中，这显然是一个不断增长的需求。

Kubernetes核心社区之外的持续创新对于这个生态系统的成熟是绝对必要的。最近，谷歌的同事Eric Brewer承认，他所工作的公司——仍然是Kubernetes社区最大的贡献者——可能太早发布了开源项目，给社区留下了太多的问题，让他们无法解决。

然而，布鲁尔的声明并没有触及根本问题。如果谷歌在开发和验证基于kubernets的核心堆栈之前就已经加入了社区，那就更好了。我们有理由让一个有远见的供应商在向开源社区发布之前，先充实一个连贯的(尽管复杂的)解决方案堆栈。

也许这表明谷歌已经吸取了这个教训，它正在以最快的速度构建另一个核心的开源栈——TensorFlow，它拥有一组健壮的功能层、工具和接口，以及——同样重要的——广泛的社区参与。

在某种程度上，谷歌可能——也可能应该——将开源的TensorFlow栈提交给一个与cncf相当的行业组织，以规范该栈的开发和治理，并使之与Kubernetes生态系统相一致。在两到三年的时间,Kubernetes TensorFlow生态系统将会聚集,集装箱化的AI DevOps处于幼稚期开源项目管道加速和解决这些需求——最明显的是,Kubeflow——成为所有人工智能应用开发中心cloud-besotted Kubernetes无处不在的世界里。

谷歌应该向CNCF提交TensorFlow吗?目前还不清楚是否CNCF,黑帮在其目前的形式来看,开源软件栈的一致性需要保持偏离其核心用例,同时确保其工作小组对接触点到Kubernetes工作小组,以确保必要的校准。