标签 KubeSphere 下的文章

导读:本文介绍了开源项目 KubeSphere 背后的故事,以及由它引发的对开源软件发展的思考。

从一个开源项目的数据说起

作为一家主要关注于开源的技术社区,我们每年都会对以中国贡献者为主的开源项目进行一次分析。而随着云计算的发展,我们对由云计算公司发起和推动的开源项目愈加重视,在研究分析过程中,我们发现了一个开源项目的数据表现亮眼,这引起了我们对这个项目背后团队的兴趣。

图 1 KubeSphere Grank 指标图

这个项目就是 KubeSphere。和其他同类项目相比,KubeSphere 项目的启动时间不算早,2018 年初才启动。但从启动开始,社区的活跃度就屡创新高。从上面的 Grank 指标图可以看出,其在 2019 年度的整体活跃度(红色线)相当高,并在今年有继续提升的趋势。而其平均活跃度指数 6.89 可以排入 Grank 服务端分类榜的前三十。

刚好,这个项目背后的负责人我们也很熟悉,之前曾经在《穿山甲专访》栏目中接受过采访——周小四(人称“四爷”),如果你感兴趣,也可以看看之前的采访文章

如今一年过去了,为了了解现在 KubeSphere 项目有什么新的变化,我又和他约时间,再次聊聊 KubeSphere 的发展和下一步的计划,得到一些新的发现和体悟。

KubeSphere:“青云”之路

谈起 KubeSphere ,容我先简单介绍一下背景。

随着云计算技术的发展,容器编排技术 Kubernetes 已经成为云服务商们的角逐重点。按照 Kubernetes 的理念,它定义的是一套标准、一个生态规范,因此,各个生存于其间的云服务商纷纷基于 Kubernetes 推出了各自的发行版和相关的生态软件。

这其中既有 Rancher、OpenShift 这样复杂完备的的企业级平台,也有 minikube、k3s 这样简单易用的实验型工具。而今天我们提到的主角 KubeSphere就是一款开源的企业级 Kubernetes 发行版,与其外延的其它组件组成了一个完备的容器生态体系。

事实上,我们可以看到,几乎所有的主流云服务商都开发了 Kubernetes 引擎(KE),比如说 TKE、RKE、AKE 等等,并以此作为其基于容器的云服务基础。当然,这些软件作为开源软件生态的一分子,都或早或晚进行了开源。

而作为青云QingCloud QKE 服务的引擎,KubeSphere 也是其中的佼佼者,并且,值得注意的是,KubeSphere 从一开始就选择了开源,并以开源作为其产品迭代发展的模式。

相比 Kubernetes 领域的其它厂商,KubeSphere 的进入时机不算早,因此,在这种情况下仍能推动决策立项,应该压力不小。周小四和我说,他们当时深入调研和分析了企业的市场需求,发现在该领域尚存在较大的产品空隙。固然,Kubernetes 为企业级容器应用揭晓了新的篇章,但广泛的企业用户在如何用好 Kubernetes 层面,需要突破较多的技术门槛和业务适配的阻碍。因此,他认为,在该领域仍大有可为,这一建议也得到青云QingCloud 的大力支持。

而另外一方面,作为一家国内主流的企业级云服务商,青云QingCloud 也一直在密切跟进 Kubernetes 领域的技术发展和产品形态。所谓磨刀不误砍柴功,正是这一年多提前付出的预研投入,让周小四及其团队在2018 年初开始 KubeSphere 的研发时,就能迅速发布经过了精心设计的 KubeSphere,并于半年后在青云QingCloud IaaS 基础设施之上推出了 QKE——KubeSphere on QingCloud 容器服务。

图 2 KubeSphere 路线图

倏忽间过去了两年,KubeSphere 也即将迭代到 3.0,对于它发展至今,并取得今天的成绩,周小四认为主要得益于以下原因:

  • 天时:站在 Kubernetes 的肩膀上,处于容器技术的大时代;
  • 地利:开源为它赋予了成长为参天大树的土壤;
  • 人和:来自团队和社区贡献者对容器技术的深刻理解、对用户需求的精准把握和在产品设计上的匠心独运。

KubeSphere 的天时

扑面而来的云原生时代,是机遇也是挑战。这里,我们看到了 Docker 公司如荧惑一样迅速升起又快速淡去,我们也看到了谷歌力推的 Kubernetes 从天下三分到一统容器编排领域,真正揭开了云原生时代的大幕。

并不是每个身处大潮之中的都是弄潮儿。说实话,这些年我看过很多云计算领域的企业或因押错注而不得不更弦易辙,或因产品没有足够的独特优势而泯然众人。对于一家国内主流的企业级云服务商,青云QingCloud 不仅一早看好 Kubernetes,又没有匆匆下场,更在局势渐明时能决然重兵压上,其实我是有些佩服和羡慕的。

在和周小四的对话中,他说,在潜心研究了 Kubernetes 生态一年后,青云QingCloud 才正式立项,并由他带队开发运营 KubeSphere 容器平台。谈话间,生性乐观的周小四并没有表现出曾经面对的困难和压力,但是如果易位而处,我能感受到他的那种魄力和信心。

KubeSphere 的地利

那么,KubeSphere 的地利是什么?是开源。

有一个强大而完善的团队,确实可以打造一款好产品,有可能取得一时之胜。但是,时代如汤汤大河,如今开源已经成为数字世界的血脉,触达和营养了各种互联网技术的急速发展。

在21世纪的第二个十年间,连微软都已经摇身一变,成为了世界上最大的开源企业之一,可以说,开源已经成为了一种时髦的技术文化,它从一种软件分发和开发模式,变成一种可以以之为脉络的商业模式。但是,开源到底只是一种时髦文化、用来迎合大众和媒体的流行词,还是可以赖之生存和发展的一种机制呢?

在这方面,我们看到了企业在开源领域的众生相,略举几例:

  • 买椟还珠式开源:有的公司是只是希望贴上开源的标签,并不真正了解开源对公司的实质价值,也无从将开源的好处和公司的发展机制相结合,空耗人力与财力,甚至没能给开源世界带来什么贡献。
  • 叶公好龙式开源,有的公司的开源成为了技术部门的 KPI 工具,他们并不真正依赖开源来提升软件质量和改善软件的业务生态,甚至害怕开源伤害到公司以专有代码建立起来的业务护城河;
  • 竭泽而渔式开源,还有的公司对待开源则是奉行“拿来主义”,只有索取和利用,而不对开源软件和开源社区做出适当的回哺,甚至倒逼一些开源软件纷纷修改其许可证,避免被吸血。

而作为 KubeSphere 项目的负责人,周小四认为青云QingCloud 是真正把开源做为一条切实可行的发展路线的

周小四认为,虽然目前开源领域看起来热闹非凡,但是真正可以称之为成功的、健康的、可复制的开源模式尚寥寥无几,失败者并不鲜见。而青云QingCloud 作为一家主流的企业级云服务商,根植于云技术之上,已经找到了一个切实可行的开源模式。周小四说,“公司(青云QingCloud)给予了强有力的支持,希望 KubeSphere 可以走出一条新的开源模式路线来,真正践行开源的思想和路径。”

KubeSphere 的人和

说完了天时、地利,让我们再来看看 KubeSphere 成功背后的人和。

对于一位资深的技术专家来说,精通云计算技术并能跟上全球云时代的技术浪潮,并不算最难的挑战,难的在于可以站在技术之外看到用户需求、用户体验和产品运营之道。

在对话中,周小四和我说,他很幸运,“总是能在对的时候找到对的人”,因此 KubeSphere 的各个细节才处理得很好。这里他专门提到了 KubeSphere “特别易用的前端界面”和“丰富完备的中英文文档”,并特别庆幸每次总能找到最好的伙伴们来做这一切。当然,这些都是建立在精心设计的架构和底层 API 之上的,只是想必这部分是周小四亲自操刀的,但他并没有专门提及。

而我想,在这样的一个团队中,有这样的一位领头羊,也是一种幸运吧。

图 3 KubeSphere and Friends

开源是如何为 KubeSphere 添砖加瓦的

缘何开源可以为 KubeSphere 提供助力呢?这是由开源模式本身的优势所决定的。

或许有些人直觉上会感到意外,开源本身并不会因代码的公开,导致该软件及软件背后的企业或组织丧失竞争力。事实上,几乎不存在一段极其精妙的代码可以形成长久的优势,更重要的是,在软件的发展过程中的工程能力才是真正的竞争力,这一点,其实和开源与否并无直接的联系。

那么既然开源对竞争力并无负面影响,是否有正面的影响呢?

有的。

首先,无论是什么软件,其必然要满足各种不同场景需求,才能与时俱进,不断发展下去,而该软件的团队和决策者往往并不能照顾到(或遇到)各种场景,也不一定总是能做出最佳选择。但是在开源模式下,由于代码是公开的,总会有层出不穷的用户场景,这些意料之内或之外的场景和需求,极大地刺激了开源软件的生命力。

其次,通过开源极大地降低了用户接触门槛,因为用户可以近乎无成本地接触和使用这些开源软件,并在满足场景需求和形成知识领域之后,还会进一步的扩散该软件的传播范围,而这本质上是对用户和市场的争夺。

最后,通过开源,软件的参与者就不仅仅是内部团队了。不限于对代码的贡献,任何提出错误反馈、功能需求,甚至寻求帮助的用户,都能加速代码的迭代和发展。一个快速迭代的软件,其活力远不是闭门造车所能比拟的。

而在 KubeSphere 中,对于以上几点的践行,实实在在地收获到了成绩。

KubeSphere 的开源成绩

从 KubeSphere 的 GitHub 仓库的活跃度看,来自青云QingCloud 和社区贡献者的提交、 议题 issue 都非常活跃。周小四还说,“我们的项目的 星标 Star 数现在有三千多,有人分析过,星标的质量很高,它们来自于全世界各地。”这意味着,KubeSphere 已经取得了社区的一定认可。而且,社区用户也在主动地自发向更多的人去推荐 KubeSphere,提到这一点,周小四的振奋之情让我感同身受。

图 4 KubeSphere 星标增长图

从上图的星标增长趋势来看,KubeSphere 的用户关注度在持续地自然增高。

在我们对开源项目的评判当中(Grank 模型),有两个重要的维度:

  • 项目活跃度:通过项目的提交、拉取请求、贡献者等数据的变化幅度计算得来的一个指标;
  • 项目健康度:通过项目的社区化程度来判断项目的健康发展程度。

从文章开始部分的图 1 可以看到,KubeSphere 的活跃度能维持在较高水准上。尤其是经过了最近几个月的全球性疫情之后,KubeSphere 的项目活跃度再次取得了新高。如果维持这个发展态势,KubeSphere 的变化将日新月异。

社区化

而 KubeSphere 项目的健康度,我们可以从图 1中看出,来自社区的代码贡献者的比例并不算很高,这对于一个由企业主导推动的开源项目来说,属于正常水准。但在代码贡献者之外,据周小四称,目前 KubeSphere 的社区活跃度还是很不错的,从社区支持的多个交流平台,如国内用户惯用的论坛、微信群,到国际用户惯用的 Slack、邮件列表等,都有很多活跃的贡献者和用户。而另一方面,KubeSphere 的独立下载量已经达上万次,周小四表示,他的目标是这个数量将来可以进一步提升到十万、百万级别。

目前的贡献者除了青云QingCloud,还有来自本来生活、中通、VNG 等海内外多家企业,并且还有不少社区的独立开发者希望能够更多地参与到 KubeSphere 的直接贡献当中。但是从目前看起来,晋升为 KubeSphere 的核心开发成员的外部贡献者占比还不够高,主要还是来自于青云周小四说,他们还在着手丰富 KubeSphere 贡献者生态,主要努力方向在以下两个方面:

  • 一方面,在如何降低贡献者的贡献门槛方面,比如文档、代码规范、贡献流程方面不断地改进和完善;
  • 另一方面,由于 KubeSphere 本身迭代速度较快,新的功能不断推出、原有功能不断改善,在高歌猛进的同时,一些需要夯实的基础性工作,比如国际化、教程、bug修复和用户需求管理方面继续加大投入更多的人力。

周小四说,他希望 KubeSphere 是属于社区的开源项目—— 这一点,从项目本身的 GitHub 仓库放在 KubeSphere 组织下可见初心。对此,周小四也设定了一个评判标准,什么时候 KubeSphere 社区的技术委员会(TOC)里面,除了青云QingCloud 的人员以外,还有其它公司或社区的成员,才叫真正的成功

图 5 KubeSphere 社区组织图

对于一个开源项目的发展,周小四有着清晰的认知,从最初的产品设计,到进一步成熟迎来更多用户,再到社区成员参与贡献并走到更高的社区决策层面,都标志开源社区的开放性和健康发展。

图 6 GitHub 数据

生态化

作为云原生领域的生态软件,KubeSphere 坚持完全开源和开放的迭代思路,联合多个企业与开源社区,共同打造了以 KubeSphere 容器平台为核心的开源项目。

除了集成主流的开源组件如 Jenkins、Istio、Prometheus 等,还围绕 KubeSphere 开源了 Porter、OpenPitrix、KubeKey、Kube-events、Fluent-bit Operator、Notification Manager、CSI 插件等 80 余个开源项目,甚至 Porter——面向裸金属环境的 Kubernetes 开源负载均衡器这样优秀的子项目已经进入了 CNCF 云原生全景图。

国际化

但是,KubeSphere 并没有满足于当前的发展,而是更积极地谋求国际化发展。周小四说,得益于该项目在发展之初就以国际化为目标,其文档、社区交流,除了立足于中国本土的中文环境之外,国际化是在创立之初就从头贯彻的。甚至,他还专门招聘有国际化社区运营经验的人员来负责全球社区建设和运营。

然而这些努力并没有白费,他发现最近几个月以来,KubeSphere 的国外下载量已经超过了国内的下载量,其贡献者中也不乏来自于中国以外各个国家和地区的技术爱好者和用户。甚至还有国外的公司主动联系他们,希望共同合作建立欧洲市场和社区,并提供相关的本地化工作。

周小四说,对于 KubeSphere 来说,开源的属性为其带来了天然的全球化属性,但让 KubeSphere 真正的成为一个全球化项目,正是他寄予期望的目标之一。

结语

有人说,一叶而知秋,我们讲开源讲了这么多年,也从心里认可和推行开源思想,但是只有我们真正在具体的项目中践行开源的理念,

我也希望读者可以从这样一个具体的项目中,观察和吸收到开源模式的精粹,我觉得,是时候在你的下一个,不,现在手里的这个项目开始,落地开源思维了。你说呢?

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

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

在国内的云服务市场当中,青云QingCloud 一直是一个积极活跃的身影,但是我却从来没有和他们直接接触过,而在上个月刚刚结束的 KubeCon 2019 上,我见到了江湖人称“四爷”的青云QingCloud 容器平台负责人周小四。自以为尚不算健谈的我,跟人聊起技术来,居然聊得非常投机。期间,我和四爷聊起了 KubeSphere 容器平台,也对青云QingCloud 的容器战略有了一些管中窥豹的了解。我想将这些谈话整理出来分享给大家,希望可以通过我的侧写让大家也认识一下这位“四爷”和他的团队打造的 KubeSphere。

谈话自然是从我所不了解的青云QingCloud 开始的。

天然的企业服务提供者

说起青云QingCloud,自然不能放过其背后的历史,这段与众不同的历史,造就了这家与众不同的云计算企业。

谈起云计算,大家会想起国内公有云市场占有率较高的一些互联网公司旗下的云服务商,这些公司的云计算业务最初大多是从内部的云计算技术能力转化出来的,将其在内部打造的云计算能力开放给公众,从而形成了我们所熟悉的多个云计算平台。

青云QingCloud 从一开始就走上了和绝大多数云计算创业企业不同的道路——自研云计算架构。

“与这些云计算公司不同,青云QingCloud 从 2012 年公司创立的那一刻开始,就是一个立足于为企业服务的云计算企业,其三位创始人均有多年在 IBM 工作的深厚背景,使得他们对于企业级用户的市场和用户的需求更加敏感,也能更加准确把握企业用户的需求和痛点。”四爷介绍说,“并且,青云QingCloud 的创始人均是资深的技术研发出身,对于技术方向的发展更加敏感,也正是如此,青云从一开始就走上了和绝大多数云计算创业企业不同的道路——自研云计算架构。”说到这里,四爷眼中洋溢着自信的眼神,作为一个同样从事了多年技术工作的老兵,我对这种技术驱动型的公司更加感兴趣了。

私有云成就下的青云

从 2012 年开始,青云QingCloud 便开始进行自研底层云计算架构的研究。自研架构所需要付出的技术成本,使得青云的公有云服务上线花费了一年半的时间,但是,付出总有回报,在自研架构上的投入,使得青云QingCloud更加灵活和富有创造力,可以更加专心地为企业提供更优质的服务。

而同时期一些使用 OpenStack 作为基础设施的云计算企业,却受制于社区的发展速度,不得不在底层基础设施的优化上花费大量的精力。说到这里,四爷表示,“这为青云争取到了宝贵的时间!”

到了 2014 年,青云QingCloud 已经取得了长足的发展。这个时候他们意识到,在当时的环境下只做公有云服务是“一条腿走路”,无法获得长时间的可持续发展,而私有云服务能够更好的发挥青云QingCloud 在企业服务的能力和经验。因此,青云开始正式进军私有云市场,并在次年年初,成功拿下中国银行、招商银行等的私有云业务。

随着青云QingCloud 的私有云业务的发展一路开疆拓土,他们逐渐建立起来成熟完善的公有云、私有云、托管云、混合云一体化的产品服务体系,后续不断得到越来越多客户的认可,我们耳熟能详的光大银行、泰康保险、中国太平、江苏交通控股、华润创业、本钢集团、国航、四川航空、好未来、VIPKID 等,都是青云的客户。

在云业务一片向好的环境下,容器时代正在悄悄的来临了。

容器时代来临,KubeSphere 应运而生

容器时代的到来,让各家云服务商都开始积极布局容器服务,而在青云QingCloud,容器服务的负责人便是我们今天谈话的主角周小四——圈内亲切的称其为“四爷”。

从 Docker 开始

在当时,开源社区内的主流容器方案,一种是一出现就迅速风靡技术世界的 Docker 技术,另一个则是同样源自 CGroup 技术的 LXC。那个时候,看起来 LXC 的目标更远大,但是在对这两种技术方向进行分析后,最终四爷选择了 Docker 的方案。

我们也曾经在容器技术初现萌芽时,对出现的各种容器技术做过跟踪,因此,我也好奇为什么四爷会在 Docker 技术初生时就押注 Docker,因为这不仅仅是社区爱好,这个决策肯定会影响到公司的技术方向和时间差优势。

四爷对此的解释说,“2013 年才提出的 Docker 虽然很年轻,但是作为一个新的容器化解决方案,它所提出的解决方案适合这个面向应用、快速迭代、微服务正在兴起的大趋势,符合并适合现行的软件开发模式发展,可以让技术把更多的精力放在如何构建一个更好的应用上。”而 LXC 则延续了重型虚拟机时代的思路,将更多的精力放在了如何更好的隔离宿主环境与容器内的环境上。这很重要,但是已经不再适合如今快节奏、快迭代的开发环境了,因此,他认为 Docker 一定会是最终的胜利者,决定选择 Docker 作为青云QingCloud 容器服务平台的底层设施。

虽然现在回过头看,Docker 容器技术在初期确实存在容器逃逸的安全问题,如今也有专注于提高隔离性的安全容器技术的出现,但是在当时,这种折中确实极大地激发了 DevOps 和相关生态的迅速发展。而正当其时,能敏锐地发现这一点,并果断下注,我认为这离不开一位技术领袖的远瞻。

在选择了容器技术方向之后,四爷的下一个挑战就来了。Docker 最初主要是一个容器引擎,其外围的生态尚不完善,尤其是对于企业大规模应用所需要的容器编排才刚刚开始获得发展。业界也推出几种不同的容器编排技术方案,这包括 Docker 推出的 Swarm、Google 推出的 Kubernetes,以及 Apache Mesos,那么作为面对企业提供服务的青云QingCloud,该如何选择呢?

押注 Kubernetes

现在看起来,当初四爷选择 Kubernetes 作为技术方向似乎是在技术人直觉之下做的选择。但是,这背后是经过了深思熟虑和足够的技术远见之下的选择。

四爷告诉我,他选择 Kubernetes 的主要原因有以下几点:

  1. Kubernetes 背后由 Google 支持:显然 Google 支持的 Kubernetes 会拥有更多的资源来发展,它也拥有更加强大的生命力。
  2. Kubernetes 是 Google 在内部基础设施的容器编排方面的经验升华:Kubernetes 的应用场景是容器编排,这种大规模容器的实践经验十分难得。而 Google 作为互联网领域的巨鳄,所拥有的经验和技术积累具有无可比拟的优势。相比之下,初创企业 Docker 公司在海量的可伸缩服务上的经验就稍显孱弱。而且 Docker 公司本身的开发力量显然有限,在容器技术日新月异的快节奏发展之下,仅仅是 Docker 引擎本身的开发和维护就已经有些不堪负荷,所以对他们在 Docker Swarm 上发展自然不如 Kubernetes 那么快。
  3. Kubernetes 的社区更加活跃:得益于 Google、Red Hat 等企业的开源社区基础,Kubernetes 从一开始就是整个社区目光的焦点,大量的开发者活跃在 Kubernetes 及其周边项目上,活跃的社区为企业培养了足够的储备人才,这一点是 Docker Swarm 和 Mesos 都无法比拟的。
  4. 容器时代已经与以虚机为基础的云计算时代有着本质的区别,以前人们关注的是功能、性能、安全等问题,创建一个虚机每个厂商可以用不同的 API 提供,用户要的是资源,不会太在意这些差异性,因此自研的云平台有存在的市场空间。但容器时代是面向应用的,用户更关注的是开放、标准等问题。简单来说,如果大家都用 Java 语言,你去采用一个只能使用汇编语言的平台,这个平台基本上很难有市场。容器编排系统一样,用 YAML 或 JSON 定义的声明式接口就是标准,大家害怕的就是选错标准。所以当大家都选择 Kubernetes 的时候,实际上选择的是标准。

经过权衡,四爷及其团队最终选择了 Kubernetes 作为青云QingCloud容器平台的编排工具。而随着对 Kubernetes 的不断的深入研究,更是让他相信,Kubernetes 会成为最终的胜利者。

他补充道:“Kubernetes 的一个主要关注是规范化,应用可以随意的在不同的基础设施间迁移,从而避免了供应商锁定。这会使得越来越多的人主动尝试使用 Kubernetes,此长彼消之下,Kubernetes 会成为最终的赢家。”

KubeSphere 的诞生

确定了 Kubernetes 方向后,四爷开始对各个 Kubernetes 产品进行了调研。通过不断试用、体验后,他敏锐的发现,现有市场上大多数厂商都没有认真做产品,要么是为了尽快抢占市场、在市场上发布尚不完善的产品,要么就是厂商的防御性产品。

“他们是以做项目的心态在做产品,没有精细化地打磨产品,更多的是功能的堆砌。”周小四解释到。

“就好像考试做题,一共十道题,每道题 10 分。他们可以做八道题,但是因为做得不好,每道题都只能得五分。而我们即使只做了 6 道题,但是每道题都是 10 分。最后的总分还是我们高,企业还是会选择我们。”四爷举了一个例子来说明“做项目”和“做产品”的不同。

在他看来,也正是这些企业以“做项目”的心态来做容器产品,才给了 KubeSphere 弯道超车的机会,以满分的心态,做出更好的产品。

从 2017 年 6 月开始,周小四便开始调研和思考如何设计 KubeSphere 的原型。2018 年 4 月,KubeSphere 项目正式立项,经过了三个月的苦干,终于在同年 6 月正式发布了 KubeSphere 的社区版,并邀请了部分用户进行内测。

精细化打磨的 KubeSphere 得到了用户的很多好评。而这一切并没有让 KubeSphere 团队止步,他们又进行了 5 个月的研发迭代,继而在 2018 年的 12 月发布了 KubeSphere 高级版,并进入了公测期。KubeSphere 团队吸收了在社区版上积累的经验,高级版将更多的精力放在企业用户的专业性、高可用性、易用性需求上。而就在前不久的 4 月发布的 KubeSphere 高级版 2.0 中,融合了更多的企业级特性。

四爷向我介绍说,KubeSphere 容器平台在企业增强特性上主要可总结为四点:

  • 极简:向导式图形化的 UI 全方位覆盖调度、管理、运维监控等功能,低学习成本高效使用。
  • 安全:基于微服务级别细粒度的多租户权限管理,完美实现资源隔离,保障数据安全性。
  • 运维友好:可视化、自动化的统一运维,以及全方位、立体化的秒级频率监控,极大程度降低运维复杂度。
  • 兼容企业传统 IT:尊重企业 IT 管理规范,兼容企业既有 IT 管理流程,可平滑整合到现有 IT 体系中。

比如说,在 Kubernetes 社区中,官方仪表盘糟糕的监控功能饱受诟病,为了解决这个问题,KubeSphere 团队为用户提供了更细粒度的权限控制、自定义控制、日志查看等功能,帮助企业更好的解决监控的需求。此外,KubeSphere 还提供了诸如 DevOps、微服务治理等能力,可以帮助企业更加简单的完成 Kubernetes 生态的接入。这些方面的差异性体现在以下几点:

  • DevOps:无需Jenkins配置、图形化拖拽编辑、即点即用
  • 微服务:治理功能完善、全可视化治理、低成本运维(轻点即用、零 Istio 基础也可以)

在接下来会发布的版本中,四爷透露道,新版会更加适配企业用户的需求,将会为企业用户提供诸如多集群、多租户、多网络、AI平台等企业亟需的特性,还将对 KubeSphere 进行架构层面的改造,让 KubeSphere 支持模块化配置,用户可以根据自己的需要,选择所需的产品模块,从而让 KubeSphere 的架构更加灵活、自如。

KubeSphere 的开源基因

如今是开源的年代,而云计算、容器和 Kubernetes 更在开源中诞生并茁壮成长起来的奇迹花园。作为开源社区,我们也非常关心 KubeSphere 的开源情况。

四爷表示,KubeSphere 项目从一开始,就是抱着开源的想法去做的,项目从初期便开源。他提到,青云QingCloud 做 KubeSphere 一开始就和其他的企业的思路不同。青云有天然的企业服务基因,从一开始 KubeSphere 就是面向企业设计和研发的,企业对于开源产品会更加的信任,而开源模式也能够让 KubeSphere 走得更远。

这种开放的策略,让 KubeSphere 在早期收获了大量用户,也让 KubeSphere 赢得了用户的信赖。

此外,四爷表示,KubeSphere 的开源也是符合用户利益的。实际上,有不少用户在开始使用青云QingCloud 的云服务之前,已经采购了其他的云服务、虚拟化或者物理设备,很难马上迁移到青云上来。开源的 KubeSphere 可以帮助他们在其它基础设施上先用起来。这种开放的策略,让 KubeSphere 在早期收获了大量用户,也让 KubeSphere 赢得了用户的信赖。

当 KubeSphere 根植于青云时

开源的 KubeSphere 与云平台是完全解耦的,这意味着 KubeSphere 可以运行于任何公有云基础设施之上,而当 KubeSphere 根植于青云QingCloud 自身所提供的基础设施时,就出现了 QKE。

周小四说,“QKE 是我们在 KubeSphere 容器平台的基础上,加入了青云的基础设施,以进一步的降低用户的使用成本。”

“从一开始做我们就知道,KubeSphere 的最终形态一定是对接公有云的,也只有公有云才有足够的资源提供给企业进行弹性伸缩。我们在 KubeSphere 的基础之上,对接了青云的高可扩展性网络和高性能存储,帮助企业用户更加简便地使用 Kubernetes 完成应用开发,而无需将大量的精力投放在底层基础设施的运维上。”

进一步的,在 QKE 之上,QKS(QingCloud Kubernetes Service)也会很快推出,QKS 是 QKE 的升级版。“QKS 也在 KubeSphere 之上,提供了不少非常有价值的功能,比如说,相比于其他家的容器服务,QKS 能够根据用量付费,这和其他家以集群来付费的理念是完全不同的。他们的本质上还是购买计算资源,然后在资源内部进行弹性。而 QKS 的底层是一个大的资源池,所有的用户都从这个资源池内调取资源进行计算,使用完成后就可以释放,从而达到真正的‘按量计费’。”

尾声

或许都是技术人吧,两个有共同话题的人聊起来技术就滔滔不绝,聊天中,我问起了“四爷”这个颇为霸气的昵称的来历,据说最初这来自同事们的戏称,周小四在技术问题上非常较真,十分霸气;而在攻关重大技术难关时,又能领着大家迎头挑战,颇有侠气,因此这个昵称在技术部门内不胫而走,最后在整个青云公司内,甚至连客户都这样亲切称呼他。我想,这正是一个技术人对技术的自信、对自己做出来的产品自信,才能自信立于云计算的潮头吧。

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

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