作者：物女王（彭昭）      物联网智库 原创

 

最近在边缘计算领域，发生了一次具有非凡意义的合作，有可能以节点的身份被载入物联网史册。

 

两大著名开源组织，Linux基金会和Eclipse基金会正在合作，将把在超大规模云计算环境中已被普遍使用的Kubernetes（简称K8s），带入到物联网边缘计算场景中。新成立的Kubernetes物联网边缘工作组将采用运行容器的理念并扩展到边缘，促进K8s在边缘环境中的适用。

 

该工作组得到了不少重量级企业的支持，他们已经对K8s投入了大量资金，包括Red Hat、博世、西门子、Eurotech、InfluxData、Vapor IO和VMware等。

 

Eclipse基金会执行董事Mike Milinkovich在随后发布的博客文章中写道：该工作组将推动K8s的演进以适应物联网边缘应用的需求，工作内容包括：

 

• 支持将工业物联网IIoT的连接设备数量扩展到百万量级，既可支持IP设备以直连方式接入K8s云平台，又可支持非IP设备通过物联网网关接入。

• 利用边缘节点，让计算更贴近设备侧，以便减少延迟、降低带宽需求和提高可靠性，满足用户实时、智能、数据聚合和安全需求：

        --将流数据应用部署到边缘节点，降低设备和云平台之间通信的带宽需求。

        --部署无服务器应用框架，使得边缘侧无需与云端通讯，便可对某些紧急情况做出快速响应。

• 在混合云和边缘环境中提供通用控制平台，以简化管理和操作。

 

据IDC数据统计, 到2022年将有超过500亿的终端与设备联网。未来超过75%的数据需要在网络边缘侧分析、处理与储存。而在边缘计算领域，很多基本的重大问题仍然悬而未决，或者仍有很大的改进空间，包括边缘侧的连接性、易管理性、可扩展性、可靠性、安全性等。

 

在边缘计算领域，解决方案的碎片化和同质化可能是首当其冲的问题，10家供应商针对相同的应用可能会有10种不同的解决方案，不仅浪费资源于重复建设，而且缺乏通用性。两大基金会的合作试图利用开源平台K8s的优势，发挥其在边缘计算领域的应用潜能。

 

在两大基金会的合作宣言中，一句话耐人寻味，他们希望通过彼此合作将K8s在云计算领域掀起的冲击波在边缘计算领域重演。当前，K8s这一云计算领域的热词，尚未在物联网领域普及，因此在本文中你将看到贴心的“温故知新”：

 

• K8s在云端掀起了什么冲击波？K8s又是如何赢得了云计算的战争？

• 为什么K8s有可能成为边缘计算发展的利器？这里你会看到关于云原生、容器、微服务等热词的解释。

• 在物联网应用中，以云平台为核心，还是以边缘为核心？思维差异有可能决定成败。

 

K8s在云端做了什么？

 

2017是K8s的胜利之年，它赢得了云计算的战争。

 

K8s诞生于谷歌，随后谷歌选择将其开源，从结果来看这一决策相当明智，也为K8s在众多竞争者中成功突围做好助攻。

 

Docker+K8s，这一组合正在成为云计算的主流，基于Docker+K8s的新型PaaS平台具有敏捷部署、弹性伸缩、灵活调度、故障自动恢复等优势，充分满足业务扩展中的资源支持，因此在短短两年之内，便从Docker Swarm、Cloud Foundry Diego、Kontena、Apache Mesos、Amazon ECS…等大量对手中脱颖而出。

 

K8s最终活了下来，很多公司纷纷放弃了自己造“轮子”的举动，终止了各自的容器编排工具，加盟K8s阵营，已经融入K8s生态的代表企业，除了谷歌之外，还包括Red Hat、微软、IBM、阿里、腾讯、华为和甲骨文等。如果一家公有云现在还没有提供K8s服务，那么基本可以认为它落后于时代。在私有云领域，K8s也已几乎成为标配。

 

K8s的胜利到底意味着什么？

 

意味着，有史以来第一次，无论使用哪一种云平台，研发人员都可以拥有完全相同的计算环境。

 

Red Hat首席架构师BilginIbryam认为，K8s胜出的最大意义有两点。一是K8s成为开发者必须学习和掌握的容器编排平台，因为它与90%的容器工作相关。二是K8s就像容器领域中的亚马逊，我们已经离不开它。K8s不仅关注应用的运行，还关注应用的打包与分发，使得应用程序可以在不同云平台之间自由迁移，它开创了全新的应用程序可移植平面，成为大家共同的选择。

 

过去，很多用户常常担心被阿里、亚马逊、微软等云计算提供商“绑定”。但自从有了K8s之后，分布式应用与云平台实现了“解耦”，工程师们不再担心如何把应用从一个平台移植到另一个平台，因为K8s在各种云平台环境均可运行。

 

为什么K8s会成为主流？

 

Docker和K8s是云原生概念的核心和基础。云计算诞生已有超过10年，但云计算时代的应用到底该是什么样子，一直没人能说清楚，也没人能确定云计算的基础架构将会如何发展。

 

在Docker+K8s出现之前，没人设想过会有一个被所有云计算供应商同时支持的分布式应用平台，直到容器技术出现之后，人们才意识到终于离目标又进了一步。

 

技术路径的选择有时直接决定了前程似锦还是江河日下。

 

OpenStack曾被称作“公有云操作系统”，但因开源版本混乱，后续运营、维护、升级成本高昂等问题，导致其难以适合公有云的发展。2015年到2017年之间，最大的OpenStack公有云提供商，思科、AT&T和HPE先后退出了市场。最近eBay宣布策略性放弃OpenStack，转而使用K8s和Docker重新平台化，才算摆脱了困境。

 

在物联网领域，技术路径的选择更为关键，可以预见大量物联网平台将会纷纷“倒戈”，增加对K8s的支持。

 

在此前的文章中，我曾经提到很多工业物联网IIoT平台均是基于Cloud Foundry构建，包括GE的Predix平台、西门子的MindSphere、博世的IoT Cloud、研华科技的WISE-PaaS和霍尼韦尔的Sentience等。目前已有企业表示将会基于K8s重新部署IIoT平台。

 

K8s将在边缘实现什么？

 

此处我们先把“云原生”、“容器”、“微服务”等热词翻译成通俗易懂的语言。

 

云原生：如果业务上云之后，开发和运维人员比上云之前还痛苦，那么上云的意义何在？

 

云原生并不是新技术，而是一种理念，它是不同思想的集合，集目前各种热门技术之大成，它的意义在于让上云成为潮流而不是阻碍。云原生应用，即指专门为在云平台部署和运行而设计的应用。

 

 

 

很多公司在完成从传统应用到云端应用的迁移过程中，遇到了或多或少的技术难题，云端应用的效率并没有实现预想的明显提升，升级迭代速度和故障定位也没有预想中快。因此云原生这一概念被提出，试图同步改进应用的开发模式，提升运维效率和企业的组织结构。

 

云原生定义了云端应用应该具备的基础特性，包括敏捷、可靠、可扩展、高弹性、故障恢复、不中断业务持续更新等。

 

2015年，由Google提议创立的CNCF云原生基金会（Cloud Native Computing Foundation）正式成立，并且发布其标志性产品K8s，不少有价值的云原生项目也随之诞生。CNCF将云原生的生态圈划分为5层，分别是应用定义与开发层、编排与治理层、运行层、供应保障层和基础设施层。

 

 

容器：容器技术是主机虚拟化技术后，最具颠覆性的计算机资源隔离技术。

 

通过容器技术进行资源的隔离，不仅对CPU、内存和存储的额外开销非常小，而且容器的生命周期管理非常快捷，可以在毫秒级开启和关闭容器。

 

简单的说，容器就像集装箱一样把软件封在一个壳子里。

 

 

上图中的这条大鲸鱼其实就是我们的电脑，这些箱子便是Docker容器，箱子里装的是软件。除了软件本身，它还包含了软件运行所需要的特殊环境配置。软件运行时可以直接利用这个箱子里的环境配置，与电脑中原有的环境配置完全不冲突，而且互不影响。

 

咱们不妨再说得简单点儿。

 

如果把电脑比作一个大食堂，食堂里面有蔬菜等原材料、各种厨具和加工工具，还有厨师作为食堂的在职员工。那么Docker容器就像是大食堂中开设的各种菜馆门店，川湘粤鲁豫菜都可以各有一个店，每个店都使用大食堂中现成的厨具，大部分原材料和现成的厨师，只需准备少部分配菜和配料（运行环境）即可。

 

 

微服务：相比大而全，人们更喜欢小而美，微服务就此应运而生。

 

过去的单体应用，就像家乐福超市一样，把所有业务的代码都放在一起，就像把所有商品混在一起售卖。这对于小型项目来说自然是很合适的，可是项目一旦大了起来，业务一多，这个单体应用也就膨胀了，膨胀后的应用主要有以下两个缺点：

 

1、牵一发动全身。修改一个业务的一行代码，需要重启整个单体应用，这显然是不合理的。

 

2、扩展能力受限。对于单体应用，如果发现某一业务的请求量非常大，那么是无法单独扩展该业务的，只能拷贝整个单体应用，再部署一套环境，来实现集群。

 

正因为单体应用有着这些缺陷，就诞生了微服务架构。微服务是一种分布式架构设计理念，为了推动细粒度服务的使用，这些服务要能协同工作，每个服务都有自己的生命周期。微服务一般配合更细粒度的容器使用，并和云原生有很强的关联性。它具有3个关键点：

 

1.每一个微服务是一个独立的自治系统，不依赖外部组件能够独立运行。

2.对外只能通过API提供服务或者获取服务。

3.粒度足够小。

 

追根溯源，其实微服务的这种架构设计理念早就有了。总之，一个微服务就是一个独立的实体，可以独立的部署在PaaS平台上，也可以作为一个独立的进程在主机中运行。服务之间通过API访问，修改一个服务不会影响其它服务。

 

说回K8s。

 

通过上面的概念介绍，K8s天生就符合云原生的理念，是容器的编排工具，适合微服务架构。但如果K8s想在边缘计算落地，还需要克服一些差异化问题：首先要进行代码压缩的工作，节省空间的占用。

 

作为K8s的创造者，谷歌在边缘计算领域的举动值得关注。在收购了物联网平台Xively之后，谷歌又与Foghorn开展了密切合作。

 

FogHorn在我的文章中曾被多次提及，这家公司成立于2014年，一直专注于边缘分析和边缘智能，是边缘计算领域发展最快的初创公司之一。Foghorn很早就拥抱了云原生的理念，基于容器构建微服务。

 

目前FogHorn正在积极推进机器学习的“边缘化”（Edgification），重点开拓的领域是工业物联网IIoT。FogHorn提供的边缘计算平台，可与部署在公有云中的物联网平台协同工作。FogHorn的旗舰产品EdgeML在边缘侧使用机器学习模型进行预测分析和异常检测，从而实现工业设备的预测性维护。

 

在最新的版本中，Foghorn平台增加了对预测模型标记语言（PMML，Predictive Model Mark Up Language）的支持，以便在边缘侧支持任何兼容的机器学习模型。

 

有外媒预测也许谷歌有意并购FogHorn，并将其与Edge TPU结合使用，以便构筑杀手级应用。

 

从云到边，重心正在转移

 

在物联网应用中，以云平台为核心，还是以边缘为核心？在这点的认知上，称霸云计算的巨头和硬件出身的企业有很大分歧，这一分歧带来的分道扬镳或直接导致最终的成败。

 

比如在谷歌的物联网架构中，云平台处于核心地位，位于云端的大脑可以使用物联网数据流实现高级分析、可视化、机器学习等功能。

 

 

而在硬件企业眼中，必须借助自身优势乏力，它们寄希望于终端设备和边缘计算成为物联网的核心。富士康便直接将涵盖工业设备、机器控制、工业网关和边缘计算等更接近工业现场的部分称为核心层，边缘计算称为核心层运算。

 

 

通过K8s在边缘计算领域的渗透，可以感受到云计算巨头也意识到了物联网的核心应当从云端进一步下沉，更贴近数据的源头，毕竟数据才是驱动云平台和人工智能的“原动力”。边缘设备作为物联网云平台的“入口”，成为连通物理世界和数字世界的桥梁，是物联网产业的重要关口。

 

K8s为边缘侧的应用部署提供了便利性，在一定程度上转变了边缘应用与硬件之间的关系，将两者的耦合度降低，让边缘层的应用可以使用更加灵活开放的模式，解决现有的痛点并满足新的需求。

 

由于K8s在边缘计算层解决了“最后一公里”云原生应用的供应问题，成为了云计算在未来发展中的重要落地支撑，推进边缘计算与云计算的彼此融合，来到“边云协同”的新阶段。通过由边缘与云端形成的多层混合架构而触发的“边云协同”效应，更能综合发挥两者的优势，促进物联网基础架构迎来一次全面的升级。

 

【物女心经】专栏中多次提到的EdgeX Foundry开源项目也已经与K8s建立合作，将EdgeX部署在其上。

 

至此，我已完成了K8s的介绍，以及它有可能在物联网边缘侧引发的冲击。

 

边缘计算领域的竞争是一场马拉松，而不是短跑。

 

最后，我想引用一个人的观点，他叫Frederick Brooks，是一位软件工程专家。20世纪80年代，Brooks在其著作《No Silver Bullet: Essence and Accident in Software Engineering》，对软件工程面临的挑战进行了论述。

 

他的一个基本论断是“没有银弹”。（银弹：欧洲中世纪的传说中有一种叫“人狼”的妖怪，只有用银子制成的特殊子弹才能杀死人狼。）即，没有任何一种技术或管理上的进展，能够独立在10年内大幅度提高软件的生产率、可靠性和便利性。

 

K8s虽然在一定程度上提升了边缘侧应用开发的效率问题，但它并不是银弹。对于物联网边缘来说，没有银弹。愿你在用好K8s这个优质工具的同时，兼顾边缘计算全局观，还有余力去把握其他或与K8s同样重要的技术和趋势。

 

衷心感谢华为工业互联网和边缘计算领域专家、边缘计算产业联盟需求与架构组主席史扬在成文过程中对我的大力支持。

 

本文小结：

1.2017是K8s的胜利之年，它赢得了云计算的战争。因为K8s，有史以来第一次，无论使用哪一种云平台，研发人员都可以拥有完全相同的计算环境。

2.K8s正在向边缘计算渗透，它为边缘侧的应用部署提供了便利性，在一定程度上转变了边缘应用与硬件之间的关系，将两者的耦合度降低。

3.K8s虽然在一定程度上提升了边缘侧应用开发的效率问题，但它并不是银弹。对于物联网边缘来说，没有银弹。

 

 

参考文章：

Open-source boffins want to do for the IoTedge what Kubernetes did for containers

K8s at the Edge – Some Context on the NewKubernetes IoT Working Group

Google Kubernetes - Analytical Evaluation

梁胜博士：从Kubernetes的发展看云计算的未来

为什么容器将统治云端：Kubernetes的崛起

Bare Metal K8s Clustering at Chick-fil-AScale