老王 发布的文章

6 月 25 日,我代表 Linux 中国社区团队参加了本次 KubeCon 2019(上海)峰会,期间有幸和安全容器 runV 的创始人王旭做了一番长谈,就云原生技术、安全容器、开源与初创企业等话题进行了深入沟通。现将这些话题整理其精要分享给大家。

互联网技术发展速度之快是所有从业者甚至非从业者都能感受到的。尤记得在世纪之交时,那时候互联网刚刚在中国开始向民用普及,不说支撑大规模的网站访问量的相关技术,就连 Linux、负载均衡甚至都没有被普遍使用。而在二十年之后,云计算已经大行其道,当今的技术人员已经言必称虚拟化、容器和 Serverless,就连刚刚准备入行互联网运维行业的新人们都已经从最初觉得考个 Linux 认证就够了到开始问询 Kubernetes 培训哪家强了。

从一届届 LC3、DockerCon 到 KubeCon,蓬勃发展的云计算与容器化似乎已经称霸了互联网领域。这次我带队参加了 6 月 24 ~ 26 日的 KubeCon 大会,对此感受尤为深刻。事实上,这次在上海举办的 KubeCon 2019 距离上次在同一地点举办的同一会议才仅仅过去半年,但是我们依旧在这次大会上看到了层出不穷的大量新技术、新动态。

云与容器的结合,引爆了这一切。

作为容器领域的资深专家,让我们来看看王旭是如何看待容器和云原生领域当前的发展态势的,以及作为这个领域的一家初创技术企业的创始人,他是如何投身到这个领域的,开源又在其间起到了什么作用。

王旭,安全容器项目 runV 的创始人,现已加入蚂蚁金服。

创立于 2015 年的 runV 项目已于 2017 年和另外一个来自英特尔的 Clear 容器项目合并为 Kata 容器项目,并由 OpenStack 基金会(OSF)进行管理,它与来自谷歌的 gVisor 项目并称为目前两大安全容器技术。

开源与初创

要么就去加强容器,要不就是引入别的安全技术来让它像容器一样。

临近 2015 年,Docker 逐渐被业界主流所接受,互联网技术已经有一个比较明显的发展趋势:第一是云,第二是容器。而云加上容器一定会产生隔离性的需求,这应该说是王旭和他的联合创始人赵鹏做安全容器最早的一个思路:要么就去加强容器,要不就是引入别的安全技术来让它像容器一样。这就是 runV 这个项目想法的起源。

runV 发布的同一个星期,英特尔Clear 容器也发布了。2016 年 8 月份,在西雅图的 LinuxCon 上,王旭和 Clear 团队见面交流,双方在一些细节上面展开合作。在 2017 年 9 月份一个会议上,英特尔软件副总裁、开源技术中心总经理 Imad Sousou 提出项目合并,然后放到基金会里管理。当时大家都觉得这是很好的一个思路。

对于 runV 和 Clear 来说,避免了重复开发以及花费精力在如何说明两者的不同上,同时合并之后可以共同推动发展一个社区,一起去寻找更多的用户。同时,两者合并还有更多的意义。

Kata 容器的意义

Kata 容器最大的意义在于推动了社区的发展。

王旭认为,Kata 容器最大的意义在于推动了社区的发展。在 2018 年之前刚开始做 Kata 容器的时候,王旭他们需要很多的附加进程来模拟 runC 容器的行为,因为 runC 是事实标准,你需要兼容它。但是当 Kata 和谷歌的 gVisor 都出来之后,上游社区就注意到这一点,开始重视,于是推出新的接口,可以语义明确地直接去对话,而不需要再去模拟 runC 的底层行为,把原来的 2N+2 个辅助进程变成了一个进程。另外,既然有了不同的容器运行时,是不是可以在不同的场景下让它们转到不同容器运行时环境上去?于是就有了“ 运行时类 runtime class ”这样的结构。Kubernetes 社区做了很多这样改进,它们也在逐步变成事实标准。这样,一个小项目的引入推动了包括从用户到上下游的整个社区相关软件的变动。

安全容器也让更多的业务使用容器变得可能。

同时,安全容器也让更多的业务使用容器变得可能。王旭在蚂蚁金服做面向金融的一些服务往云原生方向发展,需要非常严格的安全标准,这正好和 Kata 这些安全容器项目结合在一起。

增强安全性不可避免的会带来一些会性能或易用性的取舍。王旭他们的做法是,在 Kata 里面增加了一个隔离层,减少用户需要考虑的事情。举个 Docker 的例子,Docker 镜像的开发者和管理员往往不是同一个人,对于管理员来说给出的权限越少越安全,但是对于开发者来说的话,尤其开发和调试的过程中,权限的变少会让开发和调试变得非常困难。对于开发者来说,不能完全理解管理员要做的事情,所以你就会见到很多的 Docker 镜像都是要所有权限的,因为它自己也不知道需要什么权限;此外还有一些动态的情况,很难先验地用程序去完全断定它需要的权限,开发者并不太不确定到底使用了哪些能力。在这个情况下我们做的事情就是把能力整体限制到沙盒里面。在沙盒里面是完整的能力,但是实际上沙盒本身访问不到外层的系统能力,这样对应用是无感知的,操作系统就变得更安全了。确实,对于系统来说安全性和便利性是一对矛盾,你很难在同一个层面上把这个问题完全解决掉。

现在有了“运行时类”,可以指定是否需要使用安全容器。Kubernetes 社区给大家提供 了一个机制,用户可以选用或者不用安全容器,它可以是全局的配置,也可以是 pod 级别的配置。对安全性不太关键的,比如说访问一些不太敏感信息的,可以在安全性上折中一点,可以让性能更好一些。

容器的发展

从早期的 Cgroup 开始,到 LXD/LXC 这样的容器技术的出现,再到 Docker 的的诞生,一下子点燃了整个容器技术生态,紧接着在容器编排系统出现后,并发展到现今 Kubernetes 成为了事实标准。容器领域一直在快速发展。王旭的看法又是怎样的呢?

容器领域正在逐渐往上层发展。

他认为,容器领域正在逐渐往上层发展。互联网技术本身一开始是在架构层面、在底层发展,但是从 Docker 开始兴起时,给大家的感受就是减少了对底层环境的考虑,用完整的环境把应用包装起来变成容器,让它可以随地随地运行。不需要操心运行在什么样的操作系统里,把操作系统这一层干掉,或者说把它变成很窄的一层。

以发行版为例。Linux服务器发行版的核心工作有两件:一是怎么把这个系统安装上;另一个是怎么去尽量平滑管理和升级软件系统。所有的事情其实都是在围绕这两件事情。最初出现了 RPM、APT 这些包管理系统,后来是通过 Chef、Puppet、Ansible 这类配置管理系统自动化的大规模部署,再到现在的 Docker、Kubernetes,一它们都是在做软件管理的事情。原来是操作系统在做这件事情,现在是 Kubernetes 在充当操作系统的位置;对云服务来说的话,这就是无服务器模式。2014 年 AWS 在拉斯维加斯的 re:Invent 大会发布 Lambda 的时候,得到业界非常大的关注。从 Lambda 开始,每个云厂商都逐渐有了自己的无服务器服务。所以他觉得未来的发展方向,应该是向这个方向的。

除此之外,像现在中间件、服务网格也都是这样一个目的,尽量的把应用要做的事情剥离出来,和应用无关的事情全都抽象出来放到底层。

对应用开发者和使用者来说,可以不用关心底层是什么架构、怎么伸缩的,只需要知道到我需要什么服务,只要定义应用,定义 Kubernetes 配置,由它统一管理、自动伸缩和调度就好。基础设施这一层会越来越向一些少数的云厂商集中,而大家更多的精力是帮助开发者做事情,集中精力在那些业务、智能等逻辑部分。

金融与云原生

加入蚂蚁金服之后,王旭致力于将安全容器技术落地到金融级云原生的场景下。由于金融领域的特殊性,云原生实践也需要有相应的变化。

要保证安全性,不仅仅满足应用的,也要满足监管的端到端的安全性要求。

王旭举例说,金融行业不仅仅本身对安全有要求,监管对安全也有要求。所以必须要保证安全性,不仅仅满足应用的,也要满足监管的端到端的安全性要求。另一方面,他们认为安全性包括两方面,一个是应用不能破坏沙盒,泄露到外面,同时应用的底层供应商不是自己时,也可以安全的使用。这就是一个双向的安全问题。

一般而言,作为一个云服务商,会假设所有的用户都是坏人,因为所有的用户都可能去窥探基础设施,它们都可能攻击其他用户,攻击宿主机,所以要做隔离。

而金融级的要求是不光是要做这一层的隔离,而是要做更强的隔离。首先是对应用不能盲目信任,即便是内部应用也不能放任,因为内部的也有可能存在局部的破坏,也有可能会有不安全的代码或者没有被完全验证的测试代码,还有可能会有第三方的代码。反过来,应用既然是金融级的应用,它对环境也有安全要求,所以这是整体的要求。

技术创业与开源

开源对软件公司来说,是一件向死而生的事情。

在早期以开源技术为核心做创业公司时,王旭认为开源是市场推广的一个很好途径。因为软件是有人买才能赚钱,有人用才有人买,所以你如果不开源,就要一家一家地找人去试用,但是你开源了之后大家就可以免费尝试。不过,开源并不是没有缺点,开源对软件公司来说,是一件向死而生的事情。你把最核心的技术开源了,赌的是别人跟不上你的发展速度;或者说别人相信你才有能力把它做到更好,别人才会用你;或者说你给别人看到的当前版本,让他相信下一个版本他也做不到你这么好,所以才愿意跟着你来走,以至于当他维护不了的时候才会愿意来给你掏钱。这应该说是一个在市场背景下的选择。

反过来说,如果说你现在做了一个基础设施领域的软件特别好用,但是你不开源,这个时候就一定会有人做一个一样的开源替代品。那你就看能不能比它做得好,你能不能拿更多的支持、拿到更多资源。这是很困难的。

所以在这个情况下,你不得不去做这种这种极致的推广手段,就是这种不买先送的这种开源式的市场推广手段。目前来看,纯软件实现的、跟硬件没关系这种项目基本上都是采用了开源或者半开源的方式,就是说至少给你一个开源的演示版或基础版。这种方式,从商业上说是迫不得已的一种推广方式。如果你不做,你的用户们用不到的话,他们会去寻找替代品,也一定会有开源替代品出现。

技术创业还会面临一个挑战,就是当你做出来产品以后,很快会有更大的对手入场,对于初创公司来说,面临的压力是颇大的。王旭面临的情况稍微有些不同。

幸运的是,推出和 runV 类似项目的公司是英特尔,在这件事情上并没有很强的盈利导向,这也是双方最终能够合作的前提。王旭认为尽量避免无用的竞争,而是一起来教育和开拓市场,是更有建设性的做法。

做初创公司,做有价值的东西是最重要的。

经历了开源技术为核心的技术创业之后,王旭对如何做技术创业也有一些自己的看法。他认为,对于初创公司来说,很大程度上来说都在赌别人没有做过的事情,因为你重复别人做的事情,还要比别人做的好,是一件很困难的事情。对于项目来说,取决于你想的是什么东西,你的项目想得越多,想出来和别人有什么不同,别人怎么需要你的项目,其实它就越有价值。

做初创公司,做有价值的东西是最重要的,而不是说做一个很好看的架构,最重要的还是要有价值,大家才会用。此外,还要考虑相关的项目,就是你要和谁一起配合工作,你的用户群是谁,你的用户需要去引用的已有项目是哪些,怎么和它们共存,因为完全从零开始造轮子不太可能,你会用到很多已有的成果。

新做一个项目,要考虑很多相关的东西、上下游的东西,各种的兼容性、支持性,要在生态里面去找到你自己的位置。除此之外,还要明白什么是项目最重要的指标,比如开始做 runV 的时候,第一个考虑事情就是安全容器的启动时间,并且不间断的去关注和优化。

最后,做开源项目也并不是说把代码开源出来就行了,还要注重社区的建设。

作为一个开源项目来说,它的社区是非常重要的,有社区才是开源项目。

王旭认为,作为一个开源项目来说,它的社区是非常重要的,有社区才是开源项目,没有社区的项目只是拿出代码给大家看看而已,那样不会有人真的严肃的去使用你的代码。

无论是在 runV 的时期,还是后面 Kata 容器的时期,社区都是王旭和团队非常注重的一环,有很多在早期关注和参与的开发者和组织,到现在王旭也和他们保持着很好的关系。

结语

作为国内少数的基础设施方面的开源软件初创项目的领军人物之一,王旭无疑在这个领域的技术和商业方面拥有独到的经验和感悟,这些思考可以给更多在前沿领域的技术人员和开源初创项目一些启示。

“穿山甲专访”栏目是 Linux 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访,将为大家介绍中国开源领域中一些积极推动开源,谙熟开源思想的技术人,并辨析其思考、挖掘其动因,揭示其背后所发生的事情,为关注开源、有志于开源的企业和技术人标出一条路径。

取名为“穿山甲”寓意有二:取穿山甲挖掘、深入之意来象征技术进步和表征技术领袖的作用;穿山甲是珍稀保护动物,宣传公益。

6 月 24 ~ 26 日,Linux 基金会暨 CNCF 热推的 KubeCon + CloudNativeCon + OSS 2019 峰会于上海世博中心盛大揭幕。这是 Kubecon 大会在中国第二次举办,而距上一次在上海同一地点举办的 Kubecon 2018才仅过去半年,虽然调整会期有种种因素的考虑,但这么密集的再次举办也折射出云原生领域的发展速度——在本次大会上我们发现,各大云厂商和开源组织依然有很多值得分享的最新动态。

KubeCon + CloudNativeCon + OSS 2019 峰会于上海世博中心盛大揭幕

秉持 LC/CNCF 旗下会议一向的风格,这次大会在专业、丰富的各式讲演、专题分享之外,依旧是满场流动的人群、四处摆放的餐点,你甚至可以一整天泡在场馆,早中晚都吃在这里。嗯,要是有几个懒人沙发就更好了 :D

这次大会,我们 Linux 中国异步社区开源社掘金等几个国内知名的开源社区也得到了大会主办方的鼎力支持,赠送给各家社区一块非常不错的独立展位。为此,我们也精心准备了各种礼物和展板,在社区的志愿者 ONLY、cycoe、XYenChi、TK 等人的帮助下,得以在这样的国际性大会上和大家进行了面对面交流。

Linux 中国的展台 ,感谢我们的社区志愿者!

由于我在这次展会期间有好多新老朋友要见面,也预约了几个专访,因此很多心仪的演讲都失之交臂,这应该是我本次参会最大的遗憾了吧。

大家都在说“云原生”,而它到底是什么?CNCF 执行董事 Dan Kohn 给出了官方的定义:

云原生定义 v1.0

这次大会上,CNCF 宣布蚂蚁金服成为其新的黄金会员。CNCF 执行董事 Dan Kohn 表示,“CNCF 非常欢迎蚂蚁金服的加入,蚂蚁金服大规模的使用 Kubernetes 集群来构建其金融服务,是一个在中国拥抱云原生热潮中很好的案例。”

而中国更是与 CNCF 结下了不解之缘,超过 10% 的 CNCF 会员来自中国,包括 16% 的铂金会员和 35% 的黄金会员。

中国与 CNCF 的不解之缘

中国已经是 Kubernetes 的第二大贡献者,在 Kubernetes 上做出了很大的贡献,在其它的 CNCF 的项目也是如此。

也是在这次大会上,蚂蚁金服的王旭做了有关安全容器的演讲。他是安全容器项目 runV的创始人,在 runV 和 Clear 容器项目合并为 Kata 容器之后,一直在继续领导该项目的发展。他同时宣布了 Kata 容器1.7 的发布。作为容器安全领域的两大解决方案之一,Kata 容器得到了社区的积极支持,并进一步和蚂蚁金服开源的 SOFAStack 相结合,目前已经完成了和 SOFAMesh 的集成。

KubeCon NA 2018 之后 Kata 容器发布了 3 个版本

作为国内领先的云服务商,阿里云自然也出现在了这次大会上,并发布了若干重要产品/服务,其中包括国内首个“开放云原生应用中心 - Cloud Native App Hub”。开放云原生应用中心,是云原生“高速公路”上的托管和分发应用的集散地,同时也是国内开发者使用云原生应用的重要基础仓库。在 Kubernetes 生态中,“应用”是一组 YAML 格式的描述文件,而云原生应用中心,则为搜索、使用和分享这些应用描述文件提供了一个完全开源与开放的交互平台。

开放云原生应用中心 - Cloud Native App Hub

在当前的 Kubernetes 应用生态当中,Helm 是目前最被广泛使用的应用定义标准之一。所以在本次云原生应用中心的发布当中,对 Helm 格式应用的托管、搜索和分发能力成为了中心首次上线的能力。为了能够让中国的开发者更好的使用 Helm Hub 的能力,阿里云开发者中心与 Helm 社区达成了一系列技术合作,在开放云原生应用中心提供了国内首个 Helm Hub 北美官方站的同步镜像仓库与 Hub 站点。这使得中国的开发者终于可以随心所欲的搜索云原生应用,然后直接使用 helm install 命令将这些应用安装在全世界任何一个 Kubernetes 集群当中。

除了开放云原生应用中心之外,阿里云容器平台团队还正式宣布开源了重量级项目 OpenKruise。该项目源自于阿里巴巴经济体应用过去多年的大规模应用部署、发布与管理的最佳实践,源于容器平台团队对集团应用规模化运维,规模化建站的能力,源于阿里云Kubernetes服务数千客户的需求沉淀。Kruise 核心在于自动化,从不同维度解决了Kubernetes之上应用的自动化,包括,部署、升级、弹性扩缩容、Qos调节、健康检查、迁移修复等等。此次Kruise开源的内容主要在应用部署,升级方面,即一套增强版控制器组件用于应用的部署和级和运维。

目前,伴随着 5G 的到来,边缘计算也是一个热点,在本次大会上阿里云发布了托管版边缘集群 ACK@edge,致力于实现云-边-端一体化协同,通过非侵入增强方式,完美拓展云原生的边界。边缘云计算是基于云计算技术的核心和边缘计算的能力,构筑在边缘基础设施之上的云计算平台。形成边缘位置的计算、网络、存储、安全等能力全面的弹性云平台,并与中心云和物联网终端形成“云边端三体协同” 的端到端的技术架构,通过将网络转发、存储、 计算,智能化数据分析等工作放在边缘处理,降低响应时延、减轻云端压力、降低带宽成本,并提供全网调度、算力分发等云服务。

而此前华为云的开源智能边缘项目 KubeEdge 已经加入 CNCF 社区,成为 CNCF 在智能边缘领域的首个正式项目,这意味着云原生社区对智能边缘领域的关注与重视。

从本次大会的参会感受来看,特别明显的一点就是针对云原生生态的各种项目层出不穷。除了上面提及的 OpenKruise、Kata 容器之外,还有青云 QingCloud 也推出了自己的产品 KubeSphere(QKE),可以在 QingCloud 公有云上交付 KubeSphere 容器平台全能力,提供托管的原生 Kubernetes 集群、极简的人机交互实现 CI/CD、微服务、以及集群运维管理,帮助用户更敏捷地构建云原生应用,并一站式实现应用全生命周期的统一管理,从而全面释放企业的核心业务生产力。QKE 相较于原生的 Kubernetes 集群,提供了更多完善易用的开发工具集,能够实现极简开发、强劲支持和高效交付,可以帮助用户解除核心业务开发以外的平台工作负担。除了拥有强大的平台能力,QKE 还可以无缝支持混合云与多云环境。KubeSphere 交付的公有云与私有云具有完全一致的体验,无缝打通两种环境中的应用,用户可将应用在跨公、私环境的 Kubernetes 集群中进行混合部署,赋予业务更大的灵活性。

除了云原生技术方面的突破和进展之外,本次 Kubecon 大会也同时召开了开源峰会,对开源治理提出了诸多见解和分享。

来自开源社的 Ted Liu 做了题为《开源治理实践和企业案例研究》的演讲,为企业在采用、使用开源软件以及为 OSS 社区做出贡献方面提供了明确的指导和步骤。Ted Liu 还将分享一些案例研究,探讨龙头企业如何建立他们的开源项目办公室,以简化开源治理和政策,同时还将介绍开源许可和合规性。

开源社 Ted Liu 在发表演讲

而来自阿里巴巴的 Frank Zhao 则开始探索新的开源社区管理方式,将重点放在协作自动化和开发人员行为分析,这有助于社区维护人员的管理工作。在其演讲《阿里巴巴数字推动的开源社区探索》中展示了他们是如何构建阿里巴巴开源社区机制,以及为实施该机制而构建的工具背后的思考。

本次大会的内容之丰富、话题之深入,让人深切感受到了云原生领域的如火如荼的发展,而这篇文章已经太长了,本次大会上更多值得关注的数字和消息还有:

  • Linux 已经成长为世界上最重要的软件平台:100% 的超级计算机市场份额;82% 的手机市场份额;68% 的企业服务器市场份额;90% 的大型机客户;90% 的公有云工作负载;62% 的嵌入式市场份额。
  • 世界上有 51% 的关键项目是在“云”上运行的,而在中国达到了 72%;世界上有 45% 的项目,仍然是在传统的环境当中,但是在中国,这个数字仅仅只是 28% 。
  • Linux 基金会最新成立了一个子基金会 LFAI,领域主要是人工智能、机器学习和深度学习。中国有很多的企业都成为其成员,包括:百度、华为、嘀嘀等等。
  • 京东谈论了他们是《如何运行全球最大的 Vitess》以及《在 Kubernetes 中经济高效地调度大量容器》,并透露消息其区块链 BI 数据服务将在今年 7-8 月上线公测。

让我们期待今年 11 月在圣地亚哥举办的 KubeCon + CloudNativeCon 2019 北美峰会的更多消息,据称将会迎来 1.2 万名与会者,这会成为历史上最大的一个“开源峰会”!

前段时间,笔者参加了 UCloud 在京举办的 TIC 2019 大会,适逢 UCloud 实验室负责人叶理灯的演讲结束,就容器计算方面和他进行了短暂沟通。叶理灯是国内在云计算方面有深入研究和实践的资深专家,我觉得他的一些观点和看法值得分享给大家了解。

叶理灯,UCloud实验室负责人

叶理灯,UCloud 实验室负责人。现负责 UCloud 创新产品研发,专注面向企业的云计算产品的研发及运营。叶理灯拥有 10 年以上丰富的互联网研发经验,先后任职于腾讯、盛大云等互联网公司,从事海量分布式后台系统研发及运营工作。

定制违背了 K8S 初衷,提供原生 K8S 产品

记者:在官方的 K8S 发行版之上,各方云厂商提供 K8S 服务时都有一些自己的定制和调整,今天大会上提及的 UCloud 的 K8S 发行版 UK8S 主要做了哪些定制,有什么特色呢?

叶理灯如果说定制 K8S 的话,其实是违背了 K8S 的初衷。我们并没有定制 K8S,我们是基于公有云给用户提供了原生的 K8S 产品。在公有云上提供原生的 K8S,其实要做很多的工作,例如与公有云的计算、网络和存储的整合,给用户提供一个开箱即用的原生K8S集群等等。

我为什么说不应该定制呢?因为大家知道 PaaS 发展到今天,一直存在的一个问题就是供应商绑定的问题。而 K8S 之所以那么有生命力,之所以迅速流行,是因为它提供了一个开源的标准,让用户使用 K8S PaaS 平台,可以避免厂商绑定。也就是说你的服务在某个服务商的 K8S 上运行,可以无缝的迁移到另外一个服务商。

作为云厂商其实最重要的工作是,基于我们自身云平台的体系,提供原生的 K8S 给用户使用,帮助他们减少在集群管理和资源整合方面的工作和投入。例如,我们网络能力、存储能力和计算能力的整合,就是让用户享受到原生K8S的好处,同时避免了很多运维的负担。

公有云的 K8S 处在底层 IaaS 和上层应用之间,一方面向下整合IaaS能力,一方面向上托管客户的应用。在整合 IaaS 方面,不改变 K8S原生特性,因为 K8S 本身架构足够开放,例如在我们实现的网络插件,是基于我们 IaaS 的 VPC 网络,让 pod 可以和我们托管区和物理云区域打通,这是我们 IaaS 能力在 K8S 产品上的体现,算是我们的特色之一,但这是在 K8S 体系支持下的插件方式实现的,不影响我们提供原生 K8S;在应用层面,厂商也可以基于 K8S 提供一些周边的功能以帮助用户提高效率,但它和提供一个一致的 K8S 环境不矛盾。

另外一方面,如果说定制的概念是指基于 K8S 本身开发体系所提供的插件机制去做二次开发,那每家厂商都要定制,因为 K8S 本身不是一个产品级就绪的环境,需要使用者去适配网络和存储还有计算,因为每个公有云厂商基于自己的 IaaS 去提供 K8S 产品,必然要去开发插件。

综上,向用户应该提供原生的、标准的 K8S 产品,但底层应该基于自身 IaaS 平台去定制,本质还是为了提高用户使用 K8S 的效率,让用户开箱即用。

K8S 落地挑战:改造成本和人才问题

记者:你觉得目前国内云厂商提供的 K8S 集群编排服务在推广方面目前欠缺的是什么?是什么阻碍了客户进一步去使用这些容器集群服务?

叶理灯:K8S 以容器技术为核心、以容器镜像为打包标准的特点,意味着如果要迁移到这个体系下,客户需要将软件做容器化打包和微服务改造,这个是有成本的。K8S 的特点决定它是运维和研发之间的桥梁,这样就要求公司的研发过程需要跟着改造。我们看到很多公司的运维人员有动力去推动,而研发人员则没有动力,因为它改变了研发的习惯和流程,增加了负担;当然也有的公司是研发希望用 K8S 管理应用,而需要运维跟着变。这样导致迁移到 K8S 的工作较重,但一旦这个阶段过去了,迁移后的效率和成本优势就体现出来了。

因此,这是个新技术落地的问题,涉及到用户教育和习惯的改变,这个需要社区和商业公司一起完成。而且每家公司的技术路线和文化不一样,上 K8S 的路径也不一样,所以没有一个放之四海皆准的最佳实践,但随着容器和微服务逐渐落地,K8S 作为事实标准,会逐步普及。

除了改造业务的成本,另外一方面是 K8S 人才比较缺乏,不同用户的情况不一样,有些用户的运维人员本来就很少,不可能专门抽出一两个人去做 K8S,以及用户又担心它出问题谁来帮我解决?其实,应该是云厂商再往前走一步,除了帮用户构建一个 K8S 平台,还要帮助解决很多技术上的问题。 UCloud 现在就是这么做的,一个用户进来,我们会拉一个群,他们所有技术问题我们帮他们解决。在落地方面,在人才和 K8S 本身对用户架构改造方面,我们可以多做点工作,帮助客户培养K8S的运维人员和为用户制定架构迁移的方案。但我相信随着技术的发展和普及,越来越多人懂 K8S。

最后,K8S 本身也在发展,K8S 刚推出的时候是为了让大家重新面向应用来运维,但是大部分用户用 K8S 同时管理集群里的节点和应用,就会同时有两个负担。我觉得目标应该是用户直接拿一个容器就可以跑起来,而不用知道它的节点在哪里,即 Serverless 形态。一旦这种技术更加成熟,对容器技术的落地也有很大的推动作用。另一方面,Serverless 形态也给用户节省了大量的成本,按需付费,免去用户的运维成本。我觉得 K8S 的落地已经是个趋势了,是不可避免的,但是 K8S 本身是要往前进步,它的革命还没有完成。

容器与 Serverless:覆盖场景不同,非替换关系

记者:你觉得现在目前 Serverless 的发展对于容器这种创新技术的迭代升级有什么影响?是不是可以让容器更加的轻量化?

叶理灯:不完全是这样,其实 Serverless 刚出现的时候是针对计算的。计算分很多层次,有物理机、虚拟机、容器和 Serverless。Serverless 刚出来的时候,它等同于 FaaS,有一个对标的产品叫 Lambda。

Serverless 出现的动力是,由于云计算的发展,带来了如对象存储等很多丰富的中间件,Serverless 概念的提出是希望应用开发者可以不用写后端逻辑,直接把逻辑写在客户端,组合云上的一些服务来完成业务逻辑,这样就没有管理后端资源的负担了。但是后来发现很多时候还是需要后端代码的,所以就演变成如果有后端代码,就拆成函数,托管在 FaaS 服务中,这样的话,你依然是不用管理服务器的,你用的还是一个个服务,没有服务器管理负担。

这个概念在不断进步,2017 年的时候 AWS 提出了一个新的概念,重新定义了什么叫 Serverless,只要一个服务具备了四方面特性:免运维、按需付费、高可用和自动扩容,这个服务就是个 Serverless 的服务。所以 Serverless 这个概念可以对应 FaaS,也可以代表一种架构,也可以代表一种服务的形态,例如 Aurora Serverless 就是把一个数据库的服务变成 Serverless 的。

容器和 Serverless 的区别在于,Serverless 是无容器的,除了不关注服务器,也看不到容器。两者是面向不同场景的,并不是互相替代的关系。FaaS 的特点,接收一个请求拉起一个函数执行,函数是无状态的,它的执行地点也不固定,这意味着延时相对于常驻进程要高,对一些延时敏感的地方它是不合适的,但是有些场景是非常合适的。我举个例子,在 IoT 场景中,有几十万的设备,为了节省电源,它们大部分时候处于睡眠状态,如果用传统的架构去为这几十万设备服务的话,肯定要考虑并发连接的时候,应该有多少计算资源去服务,这很浪费成本。所以最好的方式,来一个请求就拉一个函数服务一下,这就很节省成本。

这是按需的,但它不是完整的替换,相当于说 IT 领域里面不同的场景其实是使用不同的服务。我们推出这个服务的原因,背后的动力还是成本和效率,在某个场景上用某个解决方案它的成本更低、效率更高,而不是说新的东西会替换老的,因为不同场景需求是不一样的。K8S 接受的用户比 FaaS 的用户更多,因为 K8S 的面更广,它覆盖的场景更多,但是它不是替换的。

记者:目前,国内客户对 Serverless 和 PaaS 的接受和普及程度是怎么样的?

叶理灯:我觉得在国内还是处于起步和用户教育阶段。2014 年 Lambda 推出的时候,它的渗透率是 72%,什么原因呢?有 72% 的人用的 Lambda,我们有个 Serverless 产品叫 UGC,腾讯有 FaaS,阿里也有 PaaS,目前都不算是渗透率很高。

原因有几个。第一、国内用户对新技术接受程度是比较低的,可能是习惯问题,国内的IT的发展水平跟国外也有差距,有 5、6 年差距;其次,对国内用户来说,把一个架构改成 Serverless 架构,其实成本是很高,而且改造的收益和规模相关;最后, FaaS 本身不是一个独立能起作用的产品,你会看到 Lambda 推出时,不是个独立的产品,它是体系的副产品,例如其他产品要开放事件源,通过事件去触发 Lambda 函数执行。只有产品体系开放足够多的事件源,FaaS 才能渗透到整个平台里面去,才能覆盖更多场景。

我们国内的厂商还没有做到这一点。AWS 刚推出 FaaS 时,它主要是 S3 上的图片处理,不是每个用户都有这个场景,因此渗透率不高。随着 API 网关方式调用,和体系开放事件源越来越丰富,覆盖场景越来越多,我相信 FaaS 会逐步落地。

在现场的演讲中,提及了一个叫 USQL 的产品,就是 Serverless 方式的大数据分析工具,StepFlow 用 Serverless 的方式编排你的程序,这些都是 Serverless 的服务。

未来,虚拟化容器值得关注

记者:目前 UK8S 的主要发展方向有什么路线图吗?UK8S 是否已经开源?

叶理灯:有的,例如说我们让 K8S 管理更多的资源、异构的资源,还有物理机、GPU 资源,希望用户可以通过 K8S 对这些资源进行统一地管理。另外,再往业务层面走会提供一些微服务的基础设施,通过产品化,一方面减轻用户的资源负担,另一方面减轻应用层的架构负担,从而尽量减轻用户迁移到 K8S 的负担。

目前 UK8S 插件还属于正在整理开源的阶段,还没有正式的发布,但我们已经小范围的开放了代码,把我们的插件代码分发给到很多用户,但公开的开源,我们希望做的更加规范一点再进行,因为我们的插件还在不断的迭代中,有一天我们觉得达到一定程度的稳定了,我们就会进行公开开源。

记者:你认为未来 K8S 以及容器的技术方向上比较值得重点关注的技术点是什么?

叶理灯:虚拟化容器。未来的方向我们相信是 Serverless,这个也是云计算应该做的,持续地为了用户提高效率和降低成本。刚才我也说了,现在用户使用 K8S 还是有资源管理的负担的,不是完全的面向应用来运维,所以需要解决这个问题,让计算节点对用户透明。用户通过 Docker 镜像和配置文件就可以把一个应用跑起来,而不用去管资源问题。这需要我们去提供一个海量的集群去跑客户的应用,这就存在一个问题,多个客户的应用可能跑在一个节点上,考虑 Docker 本身的隔离问题,我们需要类似虚拟化容器的计算方式去做隔离,同时又希望拥有 Docker 本身轻量级快速启动的效率,现在看来,虚拟化容器是比较符合这个需求的。

尾声

通过和叶理灯的交谈,梳理了我对云计算、容器技术和 Serverless 等方面的一些认识,作为一个几年来亲自践行云计算发展,并有深入探讨和研究的专家,他的观点和认识或许值得从业云计算行业的技术人员参考。

可能大家还记得,我们在一个多月前发布了一个小程序“Linux文章”,并用它来作为的我们的官方 APP。当时的实现的功能还是一个最简单的版本,基本上只是一个文章列表和文章查看。经过这段时间的不断打磨,我们终于在这个小程序的基础上,形成了比较完善的一个内容社区的官方应用。下面我给大家正式介绍一下这个小程序的功能。

首先,由于名字的原因,这个小程序没法叫做“Linux中国”,所以它的名称是叫做“Linux文章”,这有点尴尬,不过大家一般来说都可以通过扫描如下的小程序码来使用它。

扫码访问

首次访问这个小程序,会显示一个“操作指南”,从中我们可以看到,这个小程序没有采用惯常的“文章列表、点击查看”的模式,所以并不是将网站体验直接照搬到小程序当中。在这个小程序当中,充分利用了各种滑动操作,并且可以单手完成绝大部分操作。

给初次访问者的操作指南

按照指示,你可以在此屏幕上左滑或右滑看到首页的搜索框——可以搜索你想找的文章,也可以上滑看到默认文章列表或搜索结果。

首页的搜索框

而当将此页面上滑,或再次访问此小程序时,会直接显示文章列表(或搜索结果列表):

文章列表

如果进行了搜索,比如搜索“树莓派”,那么会在列表上指示搜索关键字,可以“关闭”这个关键字指示,返回默认文章列表:

搜索结果

在这个列表上,可以左右滑动,浏览更多的文章。此外,点击题图时,会切换该页面的显示模式,变成横屏模式,以题图为主要显示内容。而在横屏模式中,长按题图可以保存该题图到相册当中。

横屏模式

也可以再继续向上滑动,显示该文章内容。当然你也可以点击这个页面当中的标题访问文章内容。

文章内容

左右滑动文章页面可以看到文章内的素材信息,包括导航、链接、图片等,方便访问。

文章素材

在文章页面中,可以向下滑动回到列表,也可以继续向下滑动回到首页。

基本上,这个小程序实现了访问我们的内容的一个独立渠道,未来,我们还会增加一些方便而不会让小程序过于笨重的功能。希望大家喜欢。如果你有什么建议或 bug 反馈,请加入微信群:

半个月前,我们推出了一个“文章助手”的小程序,用于解决在微信公众号文章中无法放置可点击的链接的问题。

可能对于我们这种技术向的文章来说,很多时候都需要插入链接,而一个认真的读者也经常希望可以点击链接看看。在我们从 2013 年开始运营公众号以来,我们对此问题有过几种解决方案:

  • 直接将链接以文字的方式显示在正文中,读者需要手工选择并复制链接,然后另外在浏览器中打开
  • 类似于文章脚注一样,将链接放置在文末,读者需要翻到文末,根据所要找的链接标号来复制并在浏览器中打开
  • 将链接整理后放在另外一个 web 页面中,然后通过“阅读原文”的方式引导读者去点击,在其中完成链接功能

但是这几种方法都不太尽如人意,读者经常还是会下意识去点击文章内该出现链接的地方。所以,我们最近又有了新的解决方案。我们利用微信小程序的能力,在微信公众号文章内,采用小程序链接来替代外部链接;点击小程序链接后会打开该小程序,自动复制外部链接到剪贴板;打开浏览器(自动)贴入剪贴板中的链接来访问。

应该说,效果还是达到了我们的预期,虽然有些功能限于小程序本身支持无法做到,比如无法得到来源公众号的信息、无法主动唤起浏览器等。

不过,在使用过程中,公众号编辑们发现对链接一个个进行替换非常繁琐,所以,我决定给这个“文章助手”提供一个“助手”。我做了一个静态页面,在此页面内,只要将你编辑的公众号文章内容贴入其中的输入框,一键点击即可将全部链接转换为“文章助手”链接。

此外,经常还有认识或不认识的朋友,对我们的公众号排版表示好奇,比如这种 注释性的标签 Ruby tag 是怎么回事?也有人希望采用 PingFang 字体,这个是微信编辑器默认不提供的。这次我们就一便提供好了。

“文章助手”的助手地址如下: https://linux.cn/static/tools/a.html

  • 这个页面是纯静态页面,你可以连着其中使用的 jQuery 保存下来自行使用。
  • 该小程序永久免费,并永久不添加第三方广告。
  • 除不可抗力(如被微信官方封杀,但目前我们判断并未触犯微信使用规则),该小程序会一直运营下去。
  • 贴入输入框的文章内容可能暂时不能显示来自微信已发送文章内的图片,但是并不影响转换和转换后再贴入微信编辑器内使用。
  • 在输入框中选定格式“中文(English)”这样的内容时,点击下方的“转换 RUBY”的按钮,会将该字符串转换为 中文 English 样式。
  • 如果要全文使用“PingFang”字体,转换前勾选即可(最显眼的区别是,逗号和句号是垂直居中而不是底线对齐的)。

好了,老王的这些家底都给你们了,祝你们的公众号文章看起来越来越专业、越来越漂亮。

经常看公众号文章的人都知道,一般而言,公众号内是无法放超链接的。这对于一般的文章来说其实不要紧,但是对于我们这种技术类的文章,往往会带有很多链接,而不能插入链接,会导致一篇文章的价值和可信性降低。

备注:

公众号文章可以放超链接的情况有几种:

  1. 认证的服务号可以放任意链接
  2. 可以链接已经发送的任意公众号文章

针对这种情况,我们之前有过几种解决方案:

  1. 将链接 URL 以文字的方式显示在文章中或文章底部。
  2. 将链接转换成二维码,可以长按识别跳转。
  3. 将文内的链接整理放到一个专门的 HTML 页面,通过“阅读原文”引导读者访问。

其中第 3 种解决方案是我们近几年一直采用的方式。不料,前一段时间,有个读者留言问,链接怎么不能点?而这个读者居然是从 2013 年就关注我们的读者,这让我很吃惊。这说明,一方面我们对读者的提示和帮助还不够;另外一方面,大部分读者还是习惯性的去点击链接(我们文章内的链接有易于识别的样式,一看就像是链接)。

思考之下,结合最近我们正在研究的小程序,我们提出了第 4 种解决方案:用小程序来承载链接。读者点击小程序后,小程序负责将该链接复制到剪贴板中,这样读者只需要打开手机浏览器,就可以手动粘贴该链接进行访问了(有的浏览器会自动询问是否访问剪贴板中的链接)。虽然,还需要打开浏览器一个步骤,但是这样感觉直接多了。

这个功能在我们的公众号和我们专用的小程序“Linux文章”上试验打磨之后,我们决定建立一个公用的小程序,将这个功能开放给大家使用。

使用方法

1、在微信文章编辑器中,点击插入“小程序”,输入“文章助手”查找(使用这个小程序不需要公众号关联):

选择小程序

就是这个大眼睛,然后下一步:

2、这里输入路径“/pages/a?link=链接地址&title=链接标题”,请使用你的链接链接标题分别替换路径参数:

输入路径

当然,展示方式你也可以不使用“文字”,选择图片也是可以的。

插入文字链接后效果如下:

小程序链接效果

小程序效果

读者在看到你推送的公众号文章后,看到这种熟悉的链接样式,自然而然就知道可以点击了。点击后,会弹出如下小程序界面:

小程序界面

“文章助手”小程序会显示该链接,并自动复制到剪贴板。当你的剪贴板内有较多内容时,不会自动复制,以避免冲掉你的重要内容。这种情况下,可以点击一下链接框,手动复制即可。

然后就可以打开手机上的浏览器来浏览啦。

除此以外,点击小程序左上角的头像,读者还可以看到他查看过的所有链接。

重要提醒

此小程序的使用永久免费,并且我们承诺永远不会主动停止服务,所以不用担心你文章内的链接将来不能使用。

再上面的链接页面内有个预留广告位,我们保留将来投放广告的可能性——但是将来万一(我说万一)真的要投放广告了,我们会给出几种方式,以使你免除被绑架的忧虑:

  • 接受公众号或读者的捐赠或付款而享受免投放广告服务
  • 之前没有投放过广告的链接页面,我们保证不会出现广告(根据首次出现的时间线判定)

当然,如果你实在不相信我的人品,那么这个原理其实不复杂,你可以自己实现一个这样的小程序。