硬核老王 发布的文章

大家好,《新闻拍一拍》栏目已经运行了将近 9 个月了,从今天开始,这个栏目将改名为《硬核观察》。新的栏目将近距离观察开源领域和互联网技术界的新动向,并由 “Linux 中国”开源社区的创始人,也就是我 —— 硬核老王来发表辛辣点评(吐槽)。

虽然我是一名从业二十多年的互联网老兵,但是,我的观点也可能会有失偏颇,所掌握的知识也或有谬误。因此,如果有讲的不对的地方,大家尽管群嘲我~~

那么,请大家跟着我来看看今天有什么值得点评(吐槽)的事情吧。

Cookie 要被废弃,谷歌找到了更好给你推送精准广告的方法

几十年来,Cookie 一直是大多数广告商在网上锁定用户的主要方式。面对美国和欧洲对在线数据的隐私保护力度的提高,苹果和 Mozilla 等致力于使广告商更难追踪在线个人用户数据。而这招致了像谷歌、Facebook 等主要依赖数字广告收入的公司的强烈反对。

面对高达 3300 亿美元的互联网广告市场,谷歌一直在寻找一种既能保护隐私而又可以跟踪用户偏好的方式,以替代 Cookie,这就是他们在研究、测试的 联合组群学习 Federated Learning of Cohorts (FLoC)技术,这是谷歌 Chrome 浏览器内的一个浏览器扩展 API。

据谷歌说,FLoC 会使用机器学习算法来分析用户数据,然后根据个人访问的网站创建一个由数千人组成的群体。从浏览器本地收集的数据永远不会被共享。相反,共享的来自更广泛数千人群体数据,然后用于精准的定向广告。

然而,我认为,FLoC 和 Cookie 技术没有本质区别,只是在去隐私化方面做的更好一些罢了,本质上还是广告商的立场。

《自然》杂志评选出改变科学的 10 个计算机代码项目

如今的科学研究已经大量的依赖于计算机硬件和软件。近日,《自然》(Nature)杂志评选出了这几十年来改变科学研究的 10 个关键的计算机项目

  • 语言先驱:Fortran 编译器(1957 年)
  • 信号处理器:快速傅立叶变换 FFT(1965 年)
  • 分子编目:生物数据库(1965 年)
  • 预测领先者:大气环流模式(1969 年)
  • 数字运算机:BLAS(1979 年)
  • 显微镜必备:NIH Image(1987 年)
  • 序列搜索器:BLAST(1990 年)
  • 预印本平台:arXiv.org(1991 年)
  • 数据浏览器:IPython Notebook (2011 年)
  • 快速学习器:AlexNet(2012 年)

原本是用于科学研究的计算机及互联网已经遍及我们的生活各个角落。但作为一个互联网技术人员,我觉得如果是由计算机和互联网从业人员来评选 10 个最重要的计算机代码项目,可能和这个名单会相差很多。

Mozilla 希望让社区接管 MDN 后续的维护工作

在去年底 Mozilla 的大裁员中,很多非常有价值的项目要么被裁员,要么被分家出去。这其中除了 Rust 语言、Servo 浏览器引擎之外,还有一个非常重要的项目团队也被整个裁撤了,这就是 Mozilla 开发者网络(MDN)。对于 Web 开发者来说,MDN 文档是非常有用而权威的资源。Mozilla 随后将所有的 MDN 文档都放到了 Github 上。

现在,Mozilla 宣布成立 Open Web Docs 组织(OWD)来让社区接手该文档的维护。OWD 得到了微软、谷歌等的支持,包括资金的支持。

当然,这个项目也非常欢迎个人贡献者参与和成为支持者。大家感兴趣的可以去看看,有钱的出钱,有力的出力,哪怕只是几美金。

昨天发的一篇新闻点评中,提及了在 Ubuntu 21.04 中准备修复一个十多年的 Bug:将用户主目录的默认的“世界可写”权限取消,并对这条新闻吐槽了一番。

不料,这条新闻引来了一些意料之外的吐槽,大家在公众号、知乎、今日头条上看到这篇内容后,纷纷表示“世界可写”是机翻,是误读,应该翻译为“ 全局 Global ”。因此,我觉得有必要就此写点文字来说明一下。

说实话,我也是第一次看到“世界可写”这个翻译(这个翻译不是我发明的),初看之下有点诧异,但是细思之下,我认为,这个翻译还是颇有意思的。

传统的 Unix 权限 traditional Unix permissions 模型将用户分为三类:

  • 属主 Owner 用户 User 类(u):文件/目录的所有者
  • 群组 Group 类(g):除所有者之外的文件/目录所属用户组的成员
  • 其他 Other 类(o):“世界”上除以上二者外的其他人

对于 chmod 命令来说,我们有时候需要给这三类人都统一赋予一些权限,这种情况下,我们采用 a 来代表“ 全部 All ”,有时也称之为“ 世界 World ”。这在各种文献中

对于“ 世界 World ”这个词汇,除看起来有点不太寻常,但是我觉得,这是一种 Unix 的古典黑客精神的幽默,可能是隐喻 Unix 机器里面就是一个世界吧,如果你连 Unix 用户都没有,那你就不是这个世界的。

Unix 世界只是 Unix 的 世界 World ,从来不是 全球 Gloabl

最后,“世界可写”万万要不得。022 赛高!

早些年,我们在建设微信公众号的时候,曾经建立过矩阵,希图针对不同类型的内容建设不同垂直方向的内容公众号,但是后来由于内容不足,这个事情后期我们就停止了。

而随着这些年微信逐渐开放了更多生态,我们也除了公众号之外,也做了更多尝试,这包括小程序、视频号等等。一段时间下来,我发现我们在微信生态方面已经有了各种入口,特此汇总整理一下。

公众号

公众号是我们的主要且最重要的内容传播渠道。

Linux中国

首先是我们最早的公众号:Linux中国。这是我们第一个也是最大的微信平台,目前已经有 16.5 万粉丝。

这个订阅号的定位是综合平台,基本上会完整的反映 Linux 中国开源社区的所有内容输出,主要包括 LCTT 翻译发布的文章、社区成员投稿文章、Linux 中国开源社区的官方动态,我们组织发布的其它内容等等。

Linux中国:综合订阅号

Linux

大家可能都订阅了很多公众号,内容多到你都看不过来。我们的“Linux中国”上推送的内容,实话说,也并不是每篇文章都是一样的好。为了给大家节约时间,我们使用“Linux”这个公众号发布精选后的内容,除了时效性稍差,每天发布的一篇都是我们认为值得推荐的好内容。

这个公众号的粉丝有 8.3 万,正好是我们的主号的一半。基本上每天都只推送一篇,一般情况下都是早上 8:30 推送。

Linux:精选订阅号

璃霓思

嗯,这个号的名称就是叫“璃霓思”——一个你可能觉得古怪的名称。其实这个词是“Linux”一词的音译,可能有的同学也注意到了,这也是我们这些社区背后的法律实体。

这个服务号主要是用来发布 Linux 中国开源社区推出的一些服务和产品,比如说小程序之类的。由于是服务号,所以每个月最多只能推送 4 条,而其实我们往往每个月也就推送一条而已。对于关注我们社区的动态的同学,可以订阅这个号,既不会造成干扰,也能及时注意到我们的动态。

璃霓思:产品服务号

Linux每日动态

最近一段时间以来,我们也在发力视频、直播方向,因此建立了一个视频号。不过经过一段时间,我们也发现视频号有一些不足,比如比较难找到历史内容,需要在各种形形色色的视频号中随机刷到等等。因此,我们想,可以将我们的视频号内容汇总到另外一个公众号当中,以便大家在订阅号内容流中也能找到。

目前这个“Linux每日动态”订阅号,主要是同步当日的视频号发布内容,包括视频版的“新闻拍一拍”。

Linux每日动态:视频垂直号

小程序

小程序更多是作为一种工具而提供的,用于完善内容阅读体验、给用户提供帮助等等。

Linux

这个小程序也叫做“Linux”,它的主要作用是提供对大多数 Linux/MacOS/Posix 命令的解释、常用用法等。经常使用 Linux 的同学可能会觉得它比 Linux 的手册页更方便一些。

这个小程序的原始数据来源于 tldr.sh 项目,并由众多贡献者完成了汉化翻译。发布以来,已经有 14400 位用户将其添加到了“小程序收藏”里。这个小程序也频繁地用在我们的公众号文章内,因为我们文章经常会有各种 Linux 命令,可以直接点击查看该命令的进一步说明——除了简要说明之外,也有我们相关文章的链接、完整手册页的入口。

Linux 小程序

文章助手

阅读我们的公众号文章的同学会发现,我们的文章内的链接是“可点击的”。很多人都知道微信文章内的链接基本上是不可点击的,对于非技术/学术类的文章,这并没有什么,但是对于我们,链接不可点击会让文章失色很多。因此,我们从发布公众号的那一天起,就在研究和解决这个问题。我们曾经做过将链接 URL 直接以文字形式呈现、放到文末汇总、通过原文链接提供点击支持等等。但是这些都不够符合用户体验,因为这一两年经常会有读者问,为啥链接不能点击……。

后来,在小程序进一步和公众号融合后,我们发现可以做一个小程序来提供“点击链接”这个用户体验,这就是“文章助手”这个小程序出现的原因。当然,我们并没有敝帚自珍,而是开放给大家公开使用,并提供了一个“文章助手”的助手来帮助订阅号编辑使用这个小程序。这个小程序目前已经提供了 22 万次的链接点击服务。更多细节和使用方法,这里不赘述,可以参考我们之前的文章

文章助手 小程序

Linux文章

其实,我们一直希望有个独立的 App,但是鉴于本身的能力和现在超级 App 垄断的情形,一直没有开发“Linux中国”的独立 App。作为折中的尝试,我们做了一个“Linux文章”的小程序。这样,这个小程序可以与其它几个小程序互动关联起来,可以提供相关文章的阅读体验。目前,这个小程序只提供了我们的文章的内容同步,并采用了一种不太寻常的导航方式。

希望以一种新的方式阅读、分享、搜索我们的文章的同学,可以用一下

Linux 文章 小程序

视频号

终于说到视频号了,视频和直播能力是我们今年以来着重发展的。

我们得到测试视频号的机会并不早,之前对视频类内容也没什么经验,因此很多时候“Linux中国”这个视频号都在摸索和寻找读者们的偏好。之前是偶发的将一些内容以视频方式展现,后来,我们决定将日更的“新闻拍一拍”栏目转换为视频方式,这才做到每日都发布视频号内容。

由于并没有专业的视频制作能力,我们想了一个取巧的做法,就是以演示文稿的方式来展现当日的“新闻拍一拍”内容。虽然对于这种形式,我们遇到了一些批评和建议,比如说,有人觉得用视频演示文稿的方式来展示文章内容是多此一举(这话说的客气了),也有人觉得为了在一分钟内传播三条新闻过于仓促。所以,我们顶着压力(汗),尝试过将视频分拆成多条;后来发现完全不必受限于视频长度,视频号和其它视频平台都支持几分钟长度的视频,因此,后来的视频内容都是一分钟以上的。

Linux 中国 视频号

直播

除了视频号,我们也在努力尝试直播,我们在视频号简单做过尝试,但是目前还没有找到合适的常规场景。一般来说,我们会对业界的一些会议进行直播,但由于视频号目前还没有开放推流支持,所以,都是进行的现场直播,希望以后可以分享给大家一些更多有趣的直播内容。

小商店

微信发布小商店之后,我们自然也尝过鲜,建立了一个“Linux小商店”。不过,目前对于如何经营小商店并没有特别好的想法,现在只是放了一个带有测试性质的“Linux中国•荣耀会员卡(电子卡)”,用于大家体验。我们也在考虑,是否放一些新奇的开源硬件,比如树莓派,不知道大家觉得如何?

Linux 小商店


好了,林林总总,整理了一下,发现我们居然做了这么多,想想我们就这么点人,我自己都有点吃惊。对于我们,大家有什么建议么?

此外,除了这些微信生态内的部分,我们还有其它内容渠道和活动方向,这里就不展开了。

最后,感谢大家的支持,没有你们,我们不会有这 7 年的历程。

云原生时代的华为,不但打造了迅猛发展的云服务业务,也为自己的云服务打造了新“引擎”。

云原生时代的容器引擎的变化

随着“云原生”逐渐从一个流行词变成了一个不那么新鲜的技术基座。以 Kubernetes 为代表的容器编排技术、以 Docker、Containerd 占据主要份额的容器引擎,云原生技术也在不断的迭代升级中日益发展成熟。

Sysdig 2019 年的容器使用报告统计,全球整体容器市场规模以高达 30% 的速度增长,容器的规模、密度愈加扩大。在企业内部的容器规模方面,9% 的企业用户容器规模已经达到 5000 以上;在容器密度方面,与 2018 年相比,每台主机中的容器密度提高了 100%,从 15 个增加到了 30 个,其中最大节点密度已经达到 250 个。

而在这一切的背后,容器技术在某些场景中也呈现了一些不足,比如:

  • 在资源敏感环境,或需要部署高密度容器节点时,容器对基础设施的资源占用会急剧升高;
  • 当大规模应用拉起或遇到突发流量时,并发速度可能成为了瓶颈。

因此,主流的 Docker 等容器引擎在特定用例下,看起来有一些力不从心,因此一些针对某种用例进行过专门优化的容器引擎技术这些年纷纷入场。比如说,以 Kata Container 为代表的专门针对容器隔离性不够严格而设计的安全容器技术;以 Container Linux 为代表的专门针对重型应用而设计的系统容器;以 iSula 为代表的专门针对资源受限的边缘计算和 IoT 环境设计的轻量级容器技术。

这里,让我们来看一个源自于摄像头场景中的轻量级容器引擎。

来自摄像头的容器引擎

说起来你可能不信,一个摄像头里面居然还能有容器引擎。

起初,华为为了在智能摄像头上达到快速、简单切换算法应用部署的功能,经过技术研究,他们决定使用容器来实现所需的功能。

一开始,技术团队考虑对开源容器引擎 Docker 进行轻量化改造,对其裁剪和精简化、去除不需要的功能、优化组件结构等,甚至还对 Go 语言环境的编译进行了优化。但是,由于要运行在端侧的嵌入式设备上,这种裁剪和压榨资源的做法所能取得的效果有限。

在这种情况下,针对端侧和 IoT 环境,华为的 iSula 容器团队做了一个大胆的决定,使用 C/C++ 来量身打造一套轻量级的容器引擎!这真是一个大胆而充满勇气的决定。要知道,随着容器技术时代被 Docker 的出现而引爆,开发 Docker 所使用的 Go 语言就成为容器技术领域的首选,几乎所有的容器技术的组件和框架,都是采用 Go 语言开发的。而要使用 C/C++ 语言全新开发一个容器引擎,面临着所有基础组件,甚至一些开发语言缺乏的特性都需要另行解决。比如说,在 C 语言中要解析容器技术中普遍使用 JSON 数据,而 C 语言并没有 Go 语言等现代编程语言内置的反射机制,这就需要自行实现一个合理的 JSON 数据解析引擎。

2017 年,iSula 容器团队开始了重新开发一个容器引擎的计划。

旁白:iSula 是中南美洲亚马逊丛林中的一种非常强大的蚂蚁,被称为“子弹蚁”,因为被它咬一口,犹如被子弹打到那般疼痛,它是世界上最强大的昆虫之一。

所幸的是,虽然拦路虎众多,但是这些付出是有丰厚回报的,采用 C/C++ 开发的容器引擎,也因此具有了 Docker 所不具有的一些优势。相比 Golang 编写的 Docker,使用 C/C++ 实现的 iSula 容器引擎,具有轻、灵、巧、快等特点,不受硬件规格和架构的限制,底噪开销更小,可应用领域更为广泛。在严苛的资源要求环境下,轻量模式下的 iSulad 本身占用资源极低(< 15M),再结合上特殊的轻量化镜像,可以达成极致的资源占用效果。

2018 年,iSula 开始在华为内部的部分产品上使用。2019 年,华为决定将 iSula 开源出来,让开源社区和 iSula 共同发展,因此针对 CRI 接口进行了一次大范围的重构和补全后,与 openEuler 操作系统一并开源发布。

新造的轮子野心大

以 2019 年的统计数据看,容器引擎领域中,Docker 占据了 80% 左右的份额,但是随着 Docker 引擎自身的发展不明朗,以及容器引擎规范的标准化,出现了更多的容器引擎竞争者。这其中,iSula 作为一个悄悄发展了 3 年的轻量级容器引擎,已经迭代到了 2.0 版本,并凭借其“轻快易灵”的优势,逐渐显露出了更大的“野心”。

在智能摄像头资源的端侧大显身手之后,iSula 容器团队决定将它更进一步。得益于 iSula 所打下的良好基础,iSula 团队认为这个引擎具备更大的潜力,可以发展为通用的端、边、云平台一体的容器引擎,提供统一的架构设计来满足云、IoT、边缘计算等多个场景的应用。

虽然由于发展时间较短,加之其起源于端侧场景,目前 iSula 还没有大规模地应用在云计算集群方面,但是从与 iSula 团队沟通了解到,他们对下一步将其推广至更广泛的云计算集群领域充满信心。按照他们的说法,鉴于华为优质的软件开发质量品控,以及社区对 iSula 特有优势的青睐,它的发展值得期许。

当然,事物总是具有两面性,iSula 在取得“轻快易灵”的独特优势的同时,其使用 C/C++ 作为开发语言,也对 iSula 的快速发展带来了一些影响。因为我们知道,合格甚至优秀的 C/C++ 程序员是有多么的难得,这也造成了 iSula 项目开源后,社区贡献者数量和参与的贡献难以取得大的突破。

鉴于此,据 iSula 团队内部消息,他们正在计划将 iSula 逐渐迁移到 Rust 语言来实现,目前已经有部分模块采用 Rust 开发。Rust 作为近些年来一个明星级的系统编程语言,已经在系统编程语言方面显露出来取代 C/C++ 的潜力。如果能够顺利地平滑过渡到 Rust 语言,想必对 iSula 的开发进展、软件质量和社区参与程度,有着积极的作用。

何以轻快易灵?

iSula 是全量的容器软件栈,包括了引擎、网络、存储、工具集与容器操作系统;而 iSulad 作为其中轻量化的容器引擎,可以为多种场景提供灵活、稳定、安全的底层支撑。

根据 iSulad 的设计目标和实现情况,它具有轻、快、易、灵等优势。

iSulad 之轻

iSulad 的第一个使用场景是在端侧设备上,这自然要求这个容器引擎具有轻量级资源占用的特性。再结合为端侧设备特殊定制的轻量化镜像,它可以达成极致的资源占用的效果。

除了在端侧环境,在通用场景下,iSulad 也具有不错的轻量化表现。利用轻量化的 LXC 运行时以及极其轻量的 monitor 进程,这简化了整个调用链路。

iSulad 之快

顺理成章的,采用 C/C++ 语言实现的 iSulad,自然具备运行速度快、底噪低等特性。再加上 iSulad 独特的架构设计,除了启动容器部分需要通过 fork/exec 的方式,其他部分均使用调用函数库的方式加快执行速度。

iSulad 之易

在对 CRI 接口进行了大范围的重构和补全后,iSulad 已经能在相当程度上兼容标准化的容器规范和工具,让使用者的使用习惯和应用迁移变得轻松。

为了使开发者迁移方便,iSulad 在开发一系列迁移工具,以帮助开发者将自己的应用平滑迁移到 iSulad 上来。甚至据透露,iSulad 还会支持热迁移,能更便捷的迁移开发者的应用。

iSulad 之灵

iSulad 还针对不同的使用场景提供了不同的模式,可以根据需要灵活配置切换注重性能的性能模式和注重资源占用的轻模式。

另外,作为一个具有支持全场景容器环境的引擎,iSulad 也支持了多种不同的容器形态,它内置了支持系统容器、安全容器和普通容器以及轻量化容器的支持。

iSula 和 openEuler

iSula 是华为的 openEuler 开源社区旗下的项目之一,因此这个项目也是根植于 openEuler 系统的。这对于推动 openEuler 在企业级应用的发展具有积极意义。

不过,作为一个野心勃勃的容器引擎来说,必然不会将自己局限在某个特定操作系统之上。根据 iSula 团队的信息,目前 iSula 在 openEuler 系统上具有一些独特的优势,但是该团队也在做将 iSula 向其它 Linux 系统迁移的工作,这涉及到内核的一些特殊特性和补丁,需要得到 Linux 主线内核的支持和与内核开发者社区的沟通。

推动云原生的新引擎

毋庸置疑,容器计算已经成为云计算领域的主流。无论你是否愿意,考虑将企业的传统计算环境和古典虚拟机环境迁移到以容器计算为代表的现代云计算平台,已经是大部分 CTO 和架构师们需要迫切考虑的工作了。

而华为开源的 iSula 容器引擎,相比 Docker,是一种新的容器解决方案,它提供了统一的架构设计来满足 CT 和 IT 领域的不同需求。这匹崭露头角的新黑马,是华为攻略云原生领域的新引擎之一。

无需去历数华为在云原生领域做了多少事情,这个崭露头角的 iSula 容器引擎只是华为云这辆快车上的一枚新引擎,它将会同其它开源组件将华为云带到什么高度,让我们拭目以待。

作为云原生的核心产品,Kubernetes 提供的编排和管理功能,能轻松完成大规模容器部署,但 Kubernetes 自身的复杂性也导致众多企业一直徘徊于容器服务之外。据调查,只有不足 10% 的用户表示使用 Kubernetes 时没有遇到阻碍。

在 2019 年的一个关于容器技术的一个调查数据中,有 40% 的受访者表示计划采用容器。然而,据 UCloud 产品经理张鹏波透露说,在他们接触的用户当中,曾经在两年前表示有兴趣迁移到容器的用户,两年过去了,这些用户很多依旧“计划采用”容器服务。

这让我好奇其中发生了什么。让我们一起来探寻一下其中的症结,以及是否可以将复杂的 Kubernetes变得不复杂。

Kubernetes 复杂吗?

自从 2017 年,Kubernetes 在容器编排三强争霸赛中胜出后,就成为了容器编排领域的事实标准,极大的助推了容器技术在业界的发展。作为企业级的容器服务编排系统,Kubernetes 从技术上是现在、乃至未来的主流。

容器拥有很多优点,包括不可变环境、轻量级、快速启动等优势;而容器编排系统又在此基础上更进一步,提供了更加强大的功能,包括自动部署、快速扩容、故障自愈等等。

然而,在这一系列令人神往的优势和功能背后,Kubernetes 也相应的引入了更多的复杂性。这些复杂性体现在多个方面,比如说:

  • 首先是 Kubernetes 架构,本质上,Kubernetes 是用来管理分布式系统的平台。而一说到分布式,复杂性是不可避免的,管理分布式系统的平台自然也不例外。
  • 另外是容器支持的网络,Kubernetes 支持的网络类型很多。很多用户对于 Kubernetes 的网络非常疑惑或者说很纠结,当业务要迁移到 Kubernetes 时,选择什么类型的网络是一个难以抉择的问题。特别是在业务迁移上去之后又遇到一些问题的话,排查起来会非常麻烦,这给用户带来很大负担。
  • 最后还有就是各种各样 Kubernetes 组件的配置,这些都是用户将业务迁移到 Kubernetes 的障碍。

有什么解决方案吗?

如上所述,并不是每个用户都能尝到桃子的美味的,还有很多渴望迁移到容器环境的用户被拒之门外。

在这种情况下,全球各家云服务商,都纷纷推出自己的容器编排服务,在 Kubernetes上构建了自己的 Kubernetes发行版或定制产品。

而作为中国第一家公有云科创板上市公司,UCloud 利用在 UK8S 产品的技术沉淀,推出新的容器管理服务产品 Cube:两步即可部署容器化应用;采用无服务器形态,不需要再维护底层基础设施;按秒后付费,无需预留资源;降低企业部署云原生产品的学习和技术门槛。

为什么要推出 Cube?

在容器和 Kubernetes 如火如荼发展的同时,UCloud 发现,在他们的 UK8S 上线大概两年多的时间里,之前曾经想把业务迁到 Kubernetes 的用户。在两年后的今天,他们还是说这个话,说我很想上 Kubernetes,还需要你们来做技术交流。

UCloud 产品经理张鹏波说:

这让我们一度很困惑,我们一开始也做了一些尝试,比如说做了很多线下的培训、线上的交流,尝试去推动用户把他们的业务迁移到 UK8S 里面来。但是发现这个过程非常缓慢,我们没有办法控制和推动用户的迁移流程。很多公司的业务在快速发展,运维和研发是没有办法做架构上的调整的。

发现沟通、培训这条路实际上是走不通之后的。后来我们想,能不能换一条路,能不能基于 Kubernetes提供这样一个产品:这个产品只具有 Kubernetes 好处,掩盖了 Kubernetes 的复杂性,只提供类似于自动部署、快速扩容这样的特性,而用户不需要关心底层的 Kubernetes 架构,不需要再操心 Kubernetes 的网络了,也不需要去学习 Kubernetes 的各种 API 了。

Cube 的设计思路

沿着这个思路,UCloud 形成了自己的 Cube 产品。它的设计是从以下几个方面考虑的:

首先,Kubernetes 里面哪些功能是会经常会用到的,比如 Deployment 控制多副本容器组的管理, Job 控制任务型容器组,Service 做服务发现,PVC可以用来抽象使用块存储以及文件存储。这是 Kubernetes 最核心的一些功能。UCloud 在设计 Cube 的时候,希望将这些功能全部保留。这意味着整个 Cube 是基于 Kubernetes 来实现的。把这些复杂性全部屏蔽掉,用户不需要维护 Kubernetes 集群,不需要操心 Kubernetes 网络方案,而是由 Cube 提供一个最优网络方案,把容器的网络和虚拟机的网络扁平化。

其次,把业务迁移到 Kubernetes 的时候,把单体业务变成分布式业务、微服务的时候,用户一定需要考虑容器日志的统一收集、统一管理的问题。在 Cube 里面自动完成了日志的采集工作,集成了日志管理工作。另外,对容器环境的监控也是同样的道理,统一在 Cube 中完成。

当把这些产品全部集成到 Cube 里以后,Cube 是一个什么样的产品形态呢?

首先保证 Kubernetes 最核心的功能,用户能够在 Cube 里面创建 Kubernetes 常用的对象;另外 Cube 的产品形态应该是无服务器的形式;最后,Cube 引入了轻量级的虚拟化技术,实现了容器组与容器组之间虚拟机级别的隔离,这样好处是什么呢?

我们都知道容器的运行是共享使用宿主机的内核的,存在一定的安全风险,Cube 为每一个容器组实现了一层虚拟机的封装,可以使用户安全的运行容器;同时 UCloud 容器团队针对虚拟机的启动进行了深入优化,虚拟机启动速度最快只需要 125 毫秒。

Cube 的功能亮点

快速迁移

让我们横向对比一下,用户使用 Kubernetes 和 Cube 的流程上会有哪些区别。

左边是 Kubernetes,用户要把业务迁移到 Kubernetes,大概要经过这几个步骤:

  • 第一个步骤学习 Kubernetes,不仅仅是一个人,也可能不仅仅是一个团队,这个过程可能需要三个月到一年。
  • 搭建集群,考虑集群的参数配置、集群的维护工作。
  • 然后是做业务镜像。
  • 之后还要考虑了解 Kubernetes的 API 以及 Kubernetes 应用。
  • 最后才部署应用。

从 UCloud 观察到的情况来看,如果是对 Kubernetes非常熟悉的用户,这个过程可能要一两个月;但是如果对 Kubernetes 不熟悉,需要半年乃至一年。

使用 Cube 的话,就不再需要学习复杂的 Kubernetes知识了,和创建虚拟机一样在 Cube 里面创建一个应用,全部都是图形化的方式。所以,Cube 整个流程只有两步:

  • 制作镜像。
  • 在 Cube 的界面上直接部署应用就好了。

UCloud 产品经理张鹏波说,“我们有几个用户知道了 Cube 公测,公测以后第一天进行了解,第二天就把自己部署的业务迁移到 Cube 上来了,一天的时间就可以完成业务迁移的工作。”

成本降低

另外在成本方面,我们知道 Kubernetes 是一个大型的分布式集群,除了工作节点以外,还有管理节点。管理节点只是用来管理 Kubernetes 支持的应用,这部分开销实际上从企业角度来看是浪费的。对业务没有起到正向的作用,所以 Kubernetes 成本会比较高。

而对于 Cube,因为只需要为容器实例来付费,容器用了多少资源就付多少钱,不再考虑管理节点的开销、资源预留的问题。

更多的便利性

此外,还有一些其他针对 Kubernetes 自身的一些的改进。在 Cube 整个研发过程中,引入了一些亮点。

第一个是镜像预热,我们知道容器的启动速度其实很快的,基本一秒钟就能拉起来容器实例。但是这是热启动的情况,就是说工作节点上有这个镜像时,拉起来速度是很快的。而在冷启动的情况下,如果虚拟机上没有对应的镜像时,并且镜像非常大时,这个过程就非常缓慢了。我们遇到过最大的镜像有 20G 以上,容器的启动的时间就要花费几分钟。这样,容器本来说快速启动的优势就没有了,比虚拟机还慢了。所以,UCloud 在研发 Cube 的时候,使用了镜像预热的技术,把容器镜像变成 MBD 设备,在容器启动的时候,把它纳入到启动容器的节点上去,省去了镜像拉起的时间,让容器冷启动的时间从以前需要十几分钟变成现在只要几秒钟就拉起来了。

另外,因为 Kubernetes 是由谷歌开源的一项方案,很多理念和大部分企业更加超前一点。所以,在这种设计理念下,Kubernetes 每一个容器在重启以后,容器的 IP 就会变化。而我们知道很多传统的应用设计上是依赖于固定 IP 的,IP 一旦变化整个应用就会出现一些问题。很多用户都希望让容器重启后 IP 保持不变。这对于特别是有状态的服务尤为重要。所以,在 Cube 里面使用了 UCloud 的 EIP 功能,能够让用户容器重启时其 IP 保持不变。

最后,Cube 要兼容原有的运维习惯。传统上,虚拟机和 IDC 里面的物理机在使用体验上是没有什么差别的。有些用户之前业务部署在虚拟机,经常需要在出现问题的时候,直接登录到虚拟机里面去排错,查看一些日志。所以,为了兼容用户以前使用虚拟机的习惯,在 Cube 里面的容器也提供了登录功能,让用户在业务出现问题的时候,能够登录到容器里去快速排查问题。

结语

说实话,关于 Kubernetes 和各种发行版,我们也看过和研究过不少产品了,但是更多的是叶公好龙,没有将自己的应用迁移到 Kubernetes上的想法。一方面对着 Kubernetes 的各种先进特性馋涎欲滴,另外一方面却担心没有足够的精力面对全新的技术变化带来的挑战。

不过,今天看到 UCloud 的 Cube 产品,我决定要去亲自试试这个桃子的味道了。

五个月前,我们开始建设“Linux中国”视频号,从刚开始懵懵懂懂,到后面逐渐摸到一些门径,我们的视频号的短视频播放量也逐渐取得了提升。

不过,一直以来略有不如意之处就是少一个爆款的短视频。而令人有点尴尬的是,我们播放量最高的短视频是最初发布的一条《Windows 98 上市宣传片》,播放量:5.8 万。之后虽然也有过万的几条,但是大多在几千甚至几百的播放量。

不料昨天,我们例行发布的《新闻拍一拍》短视频,虽然发布时间很晚,恰逢其中包含了一条《IBM 宣布将分拆为两家公司》的新闻,令人大跌眼镜的是,居然迅速取得了非常高的播放量:9.7 万。一个小时就就达到了数万播放量。而二十四小时后,该短视频几乎达到了 10 万播放量。

虽然截止到目前没有超过 10 万,略有美中不足,而且这条短视频并没有花特别多的心思去制作,但是作为第一个自制视频取得这样的好成绩,我觉得还是可以写一篇短文记录一下。

截止到本文发布时,该短视频取得的成绩如下:

虽然这个数据和结果出乎预料,但也表明我们的视频号发展方向值得继续努力。看来,只要兢兢业业的一步步去努力,总有开花的一天。

最后,附上我们的视频号“Linux中国”的二维码,欢迎关注。