撰文：康翔

编辑：阿由

在神秘的代码世界里，程序员就是主角，只相信冰冷代码的他们并不善于主动称赞别人。

在全球程序员最大的聚集地之一，开源代码托管平台Github上，不同程序员、团队、公司创造的代码项目都会公之于众，以开源的方式将代码的魅力和影响力发挥到极致。

在这个过程中，有着一个神圣的机制——每个登录平台的程序员，都可以用自己的鼠标，在别人的代码项目页面点击一个“Star”。这一个简单的动作实际上代表了程序员发自心底的认可。

就在几个月前，一个全新的、面向边缘云场景的容器技术悄然登录了Github，“Star”的数量随即飙升，短短几个月时间已经超过了1万颗。

这样的数字，即便是很多成名已久的项目也无法做到。而赢得这份荣耀的产品不是其他，正是Rancher新推出的k3s。用Rancher中国CEO秦小康自己的话来说：“k3s受欢迎的程度，远远超过了我们之前的想象。”

秦小康表示，k3s最初并不是Rancher自身规划中的产物，而是来源于一家石油钻井客户的实际需求。

Rancher中国CEO秦小康

这家客户有很多油井，油井上布置了各种传感器和计算设备，这些装置的目的是要收集油井的工作状态，并且通过网络将它们传输到云端进行统一管理。

这家石油公司之前已经是Rancher的客户，已经在使用Rancher的产品部署及管理K8S，并且得到了满意的回报。当时客户提出来一个新想法，能否在数量众多的油井平台上部署K8S集群，进一步延伸他们利用容器技术来提升分析和管理的能力。

之所以找Rancher提想法，也是因为油井平台并不是一个常见的K8S环境，一台钻机寿命长的话可以用上许多年，再加上整体数量比较大，之前传输数据的任务又比较简单，所以这些部署在油井上的计算机设备配置都很低，普通的K8S太大了，根本放不下。

对于这样“超越常规”的要求，最正常的回复应该就是拒绝了。不过这个新需求却“勾”起了研发部门的兴趣，很快就抽调人力开始了尝试。

传统的K8S膀大腰圆，动辄就是几个GB的容量，因而极致的瘦身必不可少。为此，Rancher大幅度地删除了旧的、非必需的代码，整合了正在进行的打包进程，同时使用更轻量的容器引擎及数据存储替代方案。

最终，k3s变成了一个大小仅为40MB的二进制文件，在客户的终端上畅快地运行起来。

Rancher随即便意识到，这个产品完全可以复制到更多的使用场景，覆盖更为广阔的应用领域，公司将其命名为k3s，并开源到GitHub上跟广大开发者共享，共同探索k3s更广阔的使用场景和想象空间。

k3s的问世看起来很偶然，但作为一家以技术引领市场、以用户需求为导向的公司，Rancher在自身创新基因的驱动下，必然会催生出诸如k3s之类的“偶然”，这在未来场景中同样适用。

据秦小康介绍，虽然信息技术的发展速度很快，但是在传统行业的大量应用场景里，用户的环境绝非“超级环境”，位于边缘的设备诸如工业机和单片机里搭载的都是单一应用，程序非常小巧，如何让这些“古董级”的设备和应用同样享受到现今的数字红利，正是k3s将要担负起的职责与使命之一。

正如我们上面所说的，k3s最早发布的时候只有不到40MB，但在上个月的正式GA（General Availability）之后，它的“体积”稍微增加了一些，达到了差不多60MB的样子。

对于这个改变，秦小康表示，第一次的客户环境和应用比较特殊，于是Rancher的产品部门大刀阔斧地进行了裁剪，但是事后又觉得差不多有十多兆的东西不应该完全去除。譬如ROOT FS里面的命令行等功能，考虑到用户需求和更多场景的适应性，最终将它们重新添加回来。

此外，最早的发布版本就像是电影的“导演剪辑版”，虽然做的改动很少，然而随着后续剧情（产品稳定性等）需求，就必须对此前的版本进行修订与补充，从而满足用户应用场景的严苛要求。

“我们对k3s的体量没有强制的要求，至少没有一定要低于边缘上限百分之多少的硬指标。”秦小康强调，在满足所有功能的情况下，k3s会尽量保持最大化的轻量。当然，边缘设备也在不断的升级和发展中，它们不会始终停留在十几年前的配置上。

毕竟是经CNCF认证的K8S发行版，k3s也最大范围地保持了对软硬件平台的兼容和支持。整体看来，这些平台与K8S并无差异，甚至扩宽了对适用于边缘的硬件平台支持。

硬件方面，k3s支持Intel、NVIDIA与ARM等平台，由于边缘计算的缘故，后者尤其得到各方看好；操作系统方面，只要是可以跑K8S的系统就可以运行k3s，不管RedHat、Ubuntu，抑或是CentOS。

与数据中心的管理员不同，边缘节点的管理员往往不希望系统和Kubernetes平台割裂开来，因此Rancher又专门做了一个k3OS——这是一个集成了k3s的操作系统，非常小巧，但是五脏俱全，经过了Rancher的精心裁剪，能够为用户在边缘环境提供最好的支持。

Rancher与ARM的合作已历经多年，而在边缘计算乃至工业互联网之后，双方的关系也变得更加密切。

尤其是相当于K8S微缩版的k3s，更是被认为极大地释放了ARM在边缘场景的优势。对于Rancher来说，如果哪一天能通过k3s构建出一个统一的计算平台，将几百亿、上千亿的设备联接在一起，那必然给这个世界带来翻天覆地的变化。

值得一提的是，k3s继承了Rancher一如既往的理念——避免与任何厂商尤其是公有云供应商以及软硬件平台进行锁定（Lock-in），充分给予用户选择基础设施架构的自由。

“我们希望为用户提供尽量多元开放的选择，这是国内其他边缘容器厂商无法做到的，他们想尽量塞给客户一个‘全家桶’，从而增加客户后期迁移或改变选择的难度，等于变相在‘套牢’客户。客户系统灵活性的减弱，实际上是强迫客户相信他们对于未来的承诺，这是在用比较小的利益引导客户做出未来才可能会后悔的选择。”

秦小康强调：“一直以来，Rancher的愿景均是：Run Kubernetes Everywhere，最终推动Computing Everywhere，让计算无处不在。”要想将K8S的优势延伸到边缘，就势必需要k3s，这也是做k3s的初衷之一。

说到这里，或许有些读者朋友会产生误解，认为k3s的边缘应用就是荒野戈壁，远离人迹。实际上在Rancher已经收获的行业客户里，有很多场景就在我们的身边。

银行营业厅的摄像头就是非常典型的边缘应用场景，目前国内多家银行都掀起了利用智能柜机增加自身网点服务能力的变革。其中一个最关键的环节，就是利用柜机的摄像头对客户的身份进行识别确认。

为了实现这样的应用，银行需要同步升级所有营业厅的摄像头才能够做到精准的信息匹配。在传统的模式下，假如有一万个网点，就需要一万次到网点处理。通过中央的Rancher管理，边缘的k3s可以实现同步，将各种更新推送到所有的网点摄像头上。

再比如物流行业的手持终端，这种设备非常昂贵。由于同一时间里不可能要求在外作业的快递员将设备送回来统一升级，而且业务也不可以中断，因此这一类设备的管理维护难度非常大。k3s则可以进行手持终端的应用同步更新，业务完全不会受到影响，快递员甚至毫无感知。

在秦小康看来，一定程度上，k3s发挥的作用就像是CDN（内容分发网络），在复杂的环境下高效地保障信息的连贯性。他补充道，当前k3s的用户中就有很多CDN的公司，Rancher未来也会开发更多的行业应用领域。

从市场调查来看，k3s绝对是业界当前的第一品牌。现阶段，虽然也有几家全球知名的大型公司在做类似的平台，但是它们产品得到的关注度较之k3s相差甚远，尤其在Github上的Star数，基本上就是数量级的差别，项目模式也是截然不同。

k3s与众不同之处在于，它首创了边缘集群自治模式，对云和边的网络兼容性极好。即使云边断网，边缘集群亦可以独立自治工作。其他一些边缘容器厂商采用的则是云边大集群模式，一旦云边通信出现问题，整个集群将会出现很大的抖动。

至于k3s如何实现云边协同，秦小康给出了官方的推荐部署方案：用户可以在云端部署Rancher Server服务，在边缘端部署独立的k3s集群，最终通过Rancher 2.x的多集群管理方式来满足云边协同的需求。

这样做的最大好处是，无需强烈依赖云和边的网络质量，又可实现集群的统一部署和纳管，同时有效避免了锁定（Lock-in）。

不过Rancher的野心不止于此。秦小康强调：“通过技术的持续更新以及在用户场景的不断实践，Rancher希望扩大领先优势，将k3s发展成为边缘计算开发平台的事实标准。”

目前，Rancher的营收主要来源于针对数据中心和云的多云多集群企业级Kubernetes管理平台Rancher，随着边缘计算的需求越来越多，公司也会对k3s投入更多的资源，推动K8S技术的应用与发展，匹配客户的需求。

“中国市场对技术的专注与热忱，已经超出了很多发达国家和地区，这就会带来各方广泛期待的后发优势、弯道超车。随着AI、5G以及边缘计算的持续深入，计算终将无处不在。”秦小康最后总结道。