青云 QingCloud 云原生实践:基于 KubeSphere 的 QKE 正式交付

阅读数:3004 2019 年 7 月 12 日

不少云厂商会把“云原生架构”这一术语作为迁移或构建在云上应用程序所期望的最终目标,但是实现云原生的路径各有不同,本文重点介绍青云 QingCloud 云原生实践。

随着技术的不断发展,云的边界正在被技术和开源抹平,很多软件和框架设计并不直接与云平台绑定,这也是越来越多开发者讨论“云原生”的原因,而所谓的“云原生”就是最大程度发挥云平台的价值,容器技术正是将该理念落地的重要手段之一。

在这之中,Kubernetes 项目正在尝试将应用定义、管理和交付推向新的高度,虽然该项目的现有模型还存在一些问题和不足之处,尤其是声明式 API 如何更好的与用户体验达成一致,但 Kubernetes 项目的确是云原生理念落地的核心与关键所在,这一点同样体现在青云 QingCloud 的云原生实践之中。

KubeSphere

根据 Gartner 在 2018 年做出的预测,到 2020 年,50% 的用户会将容器应用在生产环境中,而这一数字未来有望更高。单体应用时代,所有功能和服务绑定交付,一旦出现问题,所有都需要重新打包、重新交付,而微服务是每个功能单独打包,出现问题只需要单独打包某一部分即可。相应的,技术水平在整个过程也发生了改变,从大机到云计算再到容器平台,Kubernetes 已经成为容器时代的分布式操作系统内核,而 KubeSphere 正是青云 QingCloud 在此基础上开源的独立分布式容器管理平台,并于近日正式交付 QKE(QingCloud Kubernetes Engine,即 KubeSphere on QingCloud)。

2018 年 4 月份,整个团队写下了 KubeSphere 的第一行代码,当然这项工作的前期调研从 2017 年就开始了。采访中,青云 QingCloud 容器平台产品经理于爽表示,青云 QingCloud 云平台 2017 年就向用户交付了原生 Kubernetes PaaS 应用,但是原生的 Kubernetes 存在诸多问题,比如使用门槛较高等,如果把 Kubernetes 理解为分布式操作系统内核,其对终端用户的使用难度可想而知。

KubeSphere 未来还将提供可配置、可插拔的功能,用户可根据个人需要选择想要的功能进行安装。KubeSphere 的定位是分布式操作系统,Kubernetes 是其内核,用户可在这个操作系统上安装想要的功能。

综合来看,KubeSphere 的产品特性主要可以从三个方面来看:

  • 底层基础设施支持,KubeSphere 考虑的是从最底层提供稳定的网络存储方案;
  • 上层应用开发及管理,提供各种应用场景和所需功能;
  • 企业级用户体验,从用户体验层面满足客户心理诉求,降低用户 40% 的操作。

相较而言,KubeSphere 是私有化部署产品,要求用户提供虚拟主机或者物理机资源,通过安装包安装,用户登录控制台操控整个集群。实际上,这还是会为运维人员带来一定使用成本,起码要先了解安装包配置过程,虽然比原生 Kubernetes 的安装简单很多,但还是需要花费一定时间成本。实际上,有些用户的要求往往更靠上层,希望厂商可以提供辅助开发、运维工作的平台,而不用了解底层基础设施运维和主机资源管理等,这就是青云 QingCloud 开发 QKE 的初衷。

据介绍,QKE 实际上对用户屏蔽了底层基础设施运维,用户不需要关心这一层,通过鼠标点击就可以拥有完全高可用、底层使用青云 QingCloud 公有云的稳定 Kubernetes 服务。同时,因为 QKE 基于 KubeSphere,同样拥有 KubeSphere 的很多功能,比如 DevOps、微服务治理、统一监控、统一日志管理,都可在 QKE 中交付给用户,这是一整套打包服务,是一个公司级别的平台,用户只需点击鼠标即可获得,这对用户来说友好且便利。

开源项目地址: https://github.com/kubesphere

青云 QingCloud 云原生理念

打造专业平台,以让平台归平台,应用归应用。

如上于爽所言,便是青云 QingCloud 的产品理念,这同样贯穿在整个云原生实践之中。那么,这句话应该如何理解呢?早在七年前,青云 QingCloud 便开始构建平台化和产品化。具体来说,要想实现容器从上到下触及很多方面,甚至到 Linux 内核,而真正的业务用户不需要关心这些细节,平台提供者会逐一解决,这就是“平台归平台”;在这一基础上,青云 QingCloud 云平台积累了大量经验和技术,尽量降低学习曲线并将抽象功能简单化,用户只需要关注业务逻辑即可,让“应用归应用”。

在容器实践层面,谷歌开源的 Kubernetes 对开发者而言非常友好,但对非开发者而言并非如此,青云 QingCloud 在操作界面会尽量降低用户复杂度,用更直观的方式把功能交付给用户,比如灰度发布。KubeSphere 提供了一种灰度策略,用户可以先将新版本在部分区域上线,稳定后再将其余流量切换到新版本。在 KubeSphere 上,整个过程只需要鼠标拖拽进度条就可以实现,用户不需要了解灰度发布的复杂度。

对于微服务治理,青云 QingCloud 目前拥抱 Istio,因为其架构更为先进,但也没有忽视 Spring Cloud 的需求。因此,青云 QingCloud 在微服务治理上同样做了可配置、可插拔的功能,用户可以选择 Istio 框架,也可以选择 Spring Cloud。周小四认为,长远来看,由于 Istio 没有绑定任何编程语言(Spring Cloud 必须基于 Java),可能更加适合企业用户,不存在后续收费或其他风险,如果企业用户需要,青云 QingCloud 可以帮助逐渐迁移到新的微服务治理平台。

在整个过程中,青云 QingCloud 团队一直在思考如何降低开发者的学习曲线。在原生 Kubernetes 中有很多抽象的资源概念,开发者的学习曲线非常复杂。KubeSphere 尽可能多地屏蔽掉抽象概念,通过界面语言让企业用户更加易于理解,降低其学习成本。

此外,在青云 QingCloud 的云原生实践过程中,开源社区和生态同样扮演着重要角色。自正式加入 CNCF 社区之后,KubeSphere 与社区组件进行了不同程度的集成,比如监控领域的 Prometheus 项目等。为了符合 CNCF 的相应规则,青云 QingCloud 整个团队做了很多完善工作,包括文档、界面、用户体验等,同时将平时遇到的问题通过 issue 的方式提交,并将改进过的代码反馈给开源社区。于爽认为,这个过程对开发者个人、社区和企业而言是一个共同成长的过程。

结束语

采访最后,于爽表示,青云 QingCloud 会在今年交付 QKS(QingCloud Kubernetes Service),这是一个比 QKE 更加简单易用的产品。QKE 毕竟还要面对 K8s 集群并关注基础资源。QKS 会更加简单,用户只需要面对应用即可。不管是基于 FaaS 还是容器化开发方式,用户只需要把代码包、代码仓库、暴露方式告知青云 QingCloud 云平台,QKS 将自动完成后续所需事宜,这可能更适用于极度敏捷的公司,比如快速上线业务诉求的创业公司。此外,KubeSphere 容器一体机也在规划中,其在现有开箱即用的基础上,提供更便捷、更强大、更安全和更稳定的云原生服务平台,并适合 IoT 的场景,可以用其构建边缘节点。

相关文章:

《阿里巴巴云原生架构实践及热议技术解析》
《腾讯云原生战略及 Serverless 平台实践解析》

收藏

评论

微博

发表评论

注册/登录 InfoQ 发表评论