KubeCon大会：商业化加速推动Kubernetes开源项目日趋成熟

至顶网软件频道消息： 本周，年度KubeCon + CloudNativeCon North America 2018大会在西雅图举行，这次活动将让云计算产业有机会评估一下Kubernetes到底发展到什么程度了，此外也探讨了可能阻碍Kubernetes平台发挥全部潜力的各种问题。

整个2018年Kubernetes都是科技领域一个热点话题，看起来这项技术似乎将在未来几年继续保持无处不在的发展势头。如今Kubernetes生态系统已经非常有活力，不过这是一把双刃剑。

提供商们对Kubernetes的商业化采用是今年云计算领域的一个主流旋律，这是因为现在企业可以更轻松地部署容器，Kubernetes实现了应用编写一次就能部署在很多计算环境中（从本地数据中心到公有云）。Kubernetes成熟的一个明显标志是，围绕Kubernetes成长起来的开源项目构成了一个丰富的生态系统，这其中包括监控项目（Prometheus）、服务代理（Envoy）、远程过程调用（gRPC）、容器网络接口（CNI）、基于DNS的服务发现（CoreDNS）、打包环境（Helm）等等。

Kubernetes主导地位日益增长的的另一个迹象是迅速扩大的企业采用率。Cloud Native Computing Foundation最近发布两年一次的企业用户调查报告显示，自2017年12月以来，使用云原生技术的企业已经增长了200%多。Kubernetes是容器管理的首选，83％的企业表示他们在私有云、公有云、混合云或者多云部署中采用Kubernetes，有大约40％的企业表示他们现在生产中采用Kubernetes。

对云计算厂商来说，Kubernetes是一个重要的竞争焦点。所有领先的公有云厂商都对这项开源技术进行了大量投资。AWS、微软、谷歌、IBM、Oracle和阿里巴巴都有他们各自的Kubernetes引擎，此外还有Red Hat、思科、VMware等等。

Kubernetes生态系统的扩散困扰着市场

然而，那些采用Kubernetes的企业现在正在走进开源项目的雷区，这些开源项目并没有积累成为一个成熟的、厂商无关的堆栈，能够应对各种云计算的各种生产级企业应用用途。

Kubernetes生态系统有多令人困惑？核心的Kubernetes开源平台已经演变成为数十个厂商调整过的发行版和托管云实施，令人眼花缭乱。不仅如此，有一系列开源项目构建并补充了Google的Kubernetes，这就更加令人困惑了。

有许多（但并不是全部）开源容器化相关的项目都属于Cloud Native Computing Foundation，只有少数不是Kubernetes的项目。最值得注意的是， 用于监控的Prometheus，用于代理的Envoy，都已经“逐渐”走向标准化。

但是我们还没有看到不同子项目之间取得突破性成功。因此，采用基于Kubernetes解决方案的企业面临着可能需要在市场崩溃时的一两年内进行“重新构建”式的迁移活动所带来的风险，我们都知道很多有前景的开源项目都已经从人们视野中逐渐消失了。

Oracle最近在积极“规划”一套核心的CNCF项目，这一点值得称道。但考虑到这只是一家厂商，这对于带来跨行业的一致性不会带来太大影响——如果云原生计算要成熟到成为任何容器化微服务的支撑，就必须要有这种一致性。而且，这无法确保攻击面的安全，攻击面在庞大异构多厂商、联合和碎片化的Kubernetes发行版、版本和工具中正在不断扩大。

Kubernetes正在成熟的开源核心

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

2018年Kubernetes核心项目的贡献总数正在放缓。随着时间的推移，CNCF管理下的Kubernetes核心代码库稳定在大约175万行代码，而其公共应用编程接口端点大约稳定在1.6万。同时，对于Kubernetes特殊兴趣群组和CNCF内孵化器项目的贡献也呈现放缓趋势。

但这并不意味着Kubernetes生态系统的创新正在萎缩。source{d}的研究还表明，更多创新来自于与Kubernetes相关的项目，这些项目在CNCF范围之外由GitHub组织进行管理。这个规模更大的Kubernetes生态系统最近大部分活动都会涉及到开发集群联合、容器运行时、支持高性能计算和机器学习的可扩展工作负载管理、以及弹性负载平衡。

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

例如，AWS最近发布的Firecracker，是一个使用基于Linux内核的虚拟机或KVM的轻量级开源虚拟机监控工具。Firecracker可以在无服务器云中创建和管理安全的多租户容器和Lambda功能。它能够实现主流容器的运行时，以管理像microVM这样的容器。通过这种方式，它让开发者可以利用虚拟机的工作负载隔离，同时获得在Kubernetes背板上运行容器的效率。

Firecracker是在Apache v2.0下提供许可的，可从GitHub存储库下载，旨在优化无服务器环境中的瞬态和无状态工作负载。AWS Lambda使用Firecracker作为配置和运行沙箱的基础，公有云提供商在该沙箱上执行客户代码。

Firecracker提供了一种安全设备模型，可以减少内存占用和攻击面，同时在每台服务器上提供高密度的microVM。最小的设备型号可以缩短启动时间（在默认microVM大小的i3.metal上小于125毫秒），同时减少攻击面。Firecracker可以将数千个microVM打包到一台机器上。用户可以访问其进程内速率限制器，以精细的粒度控制网络和存储资源的共享方式，甚至可以跨数千个microVM进行控制。

研究公司Wikibon发现，Firecracker最值得关注的是AWS将Kubernetes容器化与无服务器及虚拟化范例协调一致的方式。这并不是CNCF Kubernetes核心项目的主要关注点，但这对于那些已经投资了所有这些技术的企业来说，是一项越来越明显的要求。

CNCF能否让Kubernetes与其他社区协调一致？ 

Kubernetes核心社区之外的持续创新对于生态系统的成熟发展来说至关重要。最近，谷歌研究员Eric Brewer认为，谷歌（仍然是Kubernetes社区最主要的贡献者）可能过早地开源了Kubernetes，而给社区留下太多需要解决的问题。

但是，Brewer的观点并没有点到根本问题。如果在开源之前，谷歌在开发和证明Kubernetes核心堆栈的时候就已经参与到社区中的话就会好很多。有理由让一个有远见的厂商在发布到开源社区之前打造一个一致的——尽管是复杂的——解决方案堆栈。

也许是已经吸取了这一教训，谷歌正在全力以赴地构建另一个核心开源堆栈TensorFlow，它具有强大的功能层、工具和接口、同样重要的是——广泛的社区参与。

也许谷歌会在某个时候将开源TensorFlow堆栈提交给类似CNCF这样的组织，正式开发和治理TensorFlow，并使其与Kubernetes生态系统保持一致。在两到三年的时间内，Kubernetes和TensorFlow生态系统将会融合，因为AI DevOps的容器化正在加速，解决这些要求的、仍在萌芽状态的开源项目——例如Kubeflow——将成为Kubernetes无所不在的云世界中所有AI应用开发的核心。

谷歌应该将TensorFlow提交给CNCF吗？现在我们还不清楚目前的CNCF是否能够给TensorFlow带来所需的一致性，让这个开源堆栈不会偏离核心用途，同时确保TensorFlow工作组与Kubernetes工作组有适当的接触，确保进行必要的调整。