多集群统一管理,落地DevOps,KubeSphere帮助T3出行实现云的原生转换,
- 时间:
- 浏览:0
T3移动是南京领行科技股份有限公司搭建的智能移动生态平台,由中国第一汽车集团有限公司、东风汽车集团有限公司、重庆长安汽车股份有限公司发起,与腾讯、阿里巴巴等互联网企业共同投资搭建。公司是ldquo;rdquo;最可靠的移动性服务企业;为了品牌愿景,ldquo;科技引领快乐之旅rdquo;作为使命,提倡ldquo。可靠、更自由的rdquo;的移动性理念,致力于为用户提供ldquo。可靠性、安全性、质量rdquo;出行服务让用户感受到更自由的出行体验。
背景介绍
随着T3出行业务量持续上升,服务稳定性需要系统化保障。容器化改造提供标准化的环境,根据应用运行环境实现完整的版本控制,消除从开发到生产的环境差异,保证应用生命周期内的环境完整性和标准化。同时容器化环境可以使服务共享计算资源,通过混合方式提高整体计算资源的利用率,降低企业应用的基础设施运营成本。
集装箱化前的T3移动是传统的虚拟机模式,所有业务都部署在虚拟机上,整个产研通过堡垒机、传统监控系统、日志平台等进行日常应用运维。一旦服务开始容器化,整个T3移动产研就需要一个云本地的容器化管理平台,才能从传统的虚拟机操作模式过渡到云本地操作模式。同时,以往的日常应用运营维护模式需要多个平台配合,产研定位一个应用性能问题,多个平台需要反复切换。所以我们希望容器化平台能够整合周边配套,比如日志浏览、监控系统,让产研尽可能在一个平台内完成日常运行维护工作;作为平台工程的一部分,产研在开发环境中拥有足够的权限,可以创建、更新、删除非基线的环境,不需要了解基础结构知识,可以通过自动化的环境能力并行研发测试最终可以使业务快速、高效地增长。
类型选择说明
我们的选择性思维方式基本上基于四点:功能、UI体验、社区活跃度和学习成本。首先要满足我们对集装箱平台的需求(背景介绍中已经介绍过),其次是社区的活跃度和生态,最后是UI体验,UI体验包括用户的学习成本。我们希望能以一种低学习成本的方式,同时也具备运维视角,以便更快地进行T3出行的研发。这样就可以满足研发的应用视角纬度。运营维的群集视点维也令人满意。
与兰彻、Openshift和青云科技(qingcloud.com,股票代码:688316、推出的KubeSphere集装箱平台相比,我们最终选择KubeSphere作为T3户外自然集装箱平台。KubeSphere定位是一个以应用为中心的容器平台,提供简单的易用操作界面,帮助用户屏蔽它们的技术细节,在一定程度上降低学习成本。同时Kubesphre具备出色的容器管理能力、多集群支撑能力、多租户能力、天然集成可观测能力等,能够满足一个平台上日常运行维护的需要。
实践过程
一、多集群集成管理。
KubeSphere多集群的角色分为主集群和成员集群,由一个主集群和多个成员集群组成,与我们原来的集群计划巧合。主集群我们作为成员集群的控制面而存在,在主集群下向成员集群发送不同的管理策略。对于成员群集,环境不同,租户的性质也不同。如果根据环境来区分,我们有开发集群、测试集群、预备生产集群和生产集群。根据租户的性质,有几个将三种业务联合起来的集群。
二、项目管理。
许多传统的DevOps平台并不与项目联动。服务常常只是与组织架构相关,当组织架构发生变动时,服务的元信息并不准确。此外,对于一个项目,往往会跨部门合作,但是业务发布的视角在各个部门之下,项目成员不能在一个视图中看到项目的所有业务项目合作过程中自然会增加很多沟通成本。KubeSphere基于项目维度管理容器服务,KubeSphere中的一个项目是Kubernetes Namespace,租户之间的视图是隔离的,日常在自己的项目视图下合作即可。
DevOps平台正逐步向项目集成方向发展。目前,我们基于业务域进行集成管理。一个业务域代表KubeSphere的一个项目,业务域下面有多个相关的业务服务。无论组织结构如何更改,业务域始终保持不变。
三、多租户管理
KubeSphere中的多租户管理基于企业空间维,该维是管理项目、DevOps项目、应用程序模板和应用程序仓库的逻辑单元。我们可以在企业空间中控制对资源的访问权限,并在团队中安全地共享资源。企业空间可以将多个集群中的多个项目关联起来,并可以对企业空间中的成员进行权限管理。参考KubeSphere官方部署图,可以方便直观的理解。
由于我们统一将业务域作为项目维度进行管理,企业空间作为KubeSphere最小的租户管理单元当然是我们被业务域分割的。所以T3目前的多租户管理逻辑是企业空间(业务域)rarr、集群(开发、测试等)rarr、项目(业务域)同时,在企业空间中,我们也抽象出部门管理纬度,使用KubeSphere的部门管理,我们很容易赋予不同人员不同集群(环境)的操作权限。
四、内部DevOps平台与KubeSphere的结合。
在将T3容器化之前,有一组部署在虚拟机上的DevOps平台。集装箱化项目部署的前置条件是必须支持集装箱的发布,将现有的DevOps平台改造成云本机化的DevOps平台工作量大,项目风险不可控最终选择了DevOps平台与KubeSphere的结合。内部DevOps平台新增容器发布功能,只进行容器服务发布和Pod拷贝数放大缩小操作,由KubeSphere接管发布后的容器,让研发人员展示容器发布后的应用状态,与研发人员自助式容器对话。
可以说KubeSphere继承了T3容器化发布的后半部分,研发人员执行发布后,可以来到KubeSphere上进行与容器的交互操作,例如日志显示、监视显示、访问容器控制台、显示容器事件等。
效果
T3出行业务已全面容器化,所有集群均由KubeSphere管理,产研日常应用维护工作需基于KubeSphere平台开展。
得益于以KubeSphere应用为中心的设计,可以让用户屏蔽基础技术细节,目前T3出行目的地所有产研都可以自助使用KubeSphere进行日常工作,T3产研从传统的应用维护模式成功应用于云本机应用维护模式。
同时,KubeSphere整合了监测、日志和事件,提高了T3产研的日常人力效益。KubeSphere集群级的可观测性是提高集群资源利用率的参考依据。
将来的计划
内部DevOps平台与KubeSphere深度融合,为T3产研带来更好的体验。基于T3的业务场景采用了更优秀的开源项目,与社区一起成长。FinOps和Serverless的探索和实践。