专访青云“四爷”和他的 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 的主要原因有以下几点:
- Kubernetes 背后由 Google 支持:显然 Google 支持的 Kubernetes 会拥有更多的资源来发展,它也拥有更加强大的生命力。
- Kubernetes 是 Google 在内部基础设施的容器编排方面的经验升华:Kubernetes 的应用场景是容器编排,这种大规模容器的实践经验十分难得。而 Google 作为互联网领域的巨鳄,所拥有的经验和技术积累具有无可比拟的优势。相比之下,初创企业 Docker 公司在海量的可伸缩服务上的经验就稍显孱弱。而且 Docker 公司本身的开发力量显然有限,在容器技术日新月异的快节奏发展之下,仅仅是 Docker 引擎本身的开发和维护就已经有些不堪负荷,所以对他们在 Docker Swarm 上发展自然不如 Kubernetes 那么快。
- Kubernetes 的社区更加活跃:得益于 Google、Red Hat 等企业的开源社区基础,Kubernetes 从一开始就是整个社区目光的焦点,大量的开发者活跃在 Kubernetes 及其周边项目上,活跃的社区为企业培养了足够的储备人才,这一点是 Docker Swarm 和 Mesos 都无法比拟的。
- 容器时代已经与以虚机为基础的云计算时代有着本质的区别,以前人们关注的是功能、性能、安全等问题,创建一个虚机每个厂商可以用不同的 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 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访,将为大家介绍中国开源领域中一些积极推动开源,谙熟开源思想的技术人,并辨析其思考、挖掘其动因,揭示其背后所发生的事情,为关注开源、有志于开源的企业和技术人标出一条路径。
取名为“穿山甲”寓意有二:取穿山甲挖掘、深入之意来象征技术进步和表征技术领袖的作用;穿山甲是珍稀保护动物,宣传公益。
本文转载来自 Linux 中国: https://github.com/Linux-CN/archive