0
点赞
收藏
分享

微信扫一扫

T3 出行云原生容器化平台实践

公司简介

T3 出行是南京领行科技股份有限公司打造的智慧出行生态平台,由中国第一汽车集团有限公司、东风汽车集团有限公司、重庆长安汽车股份有限公司发起,联合腾讯、阿里巴巴等互联网企业共同投资打造。公司以“成为最值得信赖的出行服务企业”为品牌愿景,“科技引领 愉悦出行”为使命,倡导“可信,更自由”的出行理念,致力为用户提供“可信、安全、品质”出行服务,让用户感受更加自由的出行体验。

背景介绍

随着 T3 出行业务体量持续上涨,服务的稳定性需要系统化的保障。容器化改造将提供标准化的环境,基于应用运行环境实现完整的版本控制,消除开发到生产的环境差异,保证应用生命周期内环境一致性和标准化。同时容器化环境可以让服务共享计算资源,并通过混部方式来提高整体计算资源的利用率,降低企业应用的基础设施运营成本。

容器化之前 T3 出行是传统的虚拟机模式,所有业务都部署在虚拟机上,全体产研通过堡垒机、传统的监控系统、日志平台等进行日常应用的运维。而一旦服务容器化开始,我们必然需要一个云原生的容器化管理平台,让 T3 出行全体产研从传统的虚拟机操作模式转变为云原生操作模式。同时,之前日常的应用运维模式需要使用多个平台进行协作,产研定位一个应用性能问题往往需要来回切换多个平台。所以我们希望容器化平台可以集成周边的配套,如日志查看、监控系统,让产研尽量在一个平台内完成日常运维的工作;也可以作为平台工程的一部分,让产研在开发环境可以拥有足够的权限创建、更新、删除非基线环境,而无需了解底层架构知识,通过自助化的环境能力可以让研发并行开发测试,最终让业务可以快速、高效增长。

选型说明

我们的选型思路基本上是根据功能、UI 体验、社区活跃度、学习成本这 4 点来的。首先必须要满足我们对容器平台的需求(在背景介绍中已经描述),其次是社区活跃度以及生态,最后是 UI 体验,在 UI 体验中包含了用户的学习成本,我们希望以低学习成本的方式让 T3 出行的研发更够快速上手容器平台,同时也具备运维视角,如此就既满足了研发的应用视角纬度,也满足了运维的集群视角维度。 我们在选型期间对比了 Rancher、Openshift、KubeSphere,最终选择了 KubeSphere 作为 T3 出行云原生容器平台。KubeSphere 定位是以应用为中心的容器平台,提供简单易用的操作界面,帮助用户屏蔽掉那些技术细节,一定程度上降低了学习成本。同时 Kubesphere 具备优秀的容器管理能力、多集群支持能力、多租户能力、天然集成的可观测能力等,让我们可以在一个平台上满足了日常运维所需。

实践过程

多集群规划

KubeSphere 多集群中角色分为主集群和成员集群,由 1 个主集群和多个成员集群组成,与我们原先的集群规划不谋而合。主集群我们作为成员集群的控制面存在,通过主集群下发不同的管理策略给到成员集群。对于成员集群而言,我们根据不同的环境、不同的租户性质也会划分到不同集群。如根据环境区分,我们会有开发集群、测试集群、预生产集群、生产集群;而根据租户性质,我们会有一些对接三方业务的集群。

T3 出行云原生容器化平台实践_多集群

项目管理

在很多传统的 DevOps 平台中,并没有与项目进行联动,服务往往只是关联了组织架构,当组织架构变动,服务的元信息就不准确了。而且,对于一个项目来说,经常会有跨部门合作的情况,而业务发布的视角却是在各自的部门下的,项目成员无法在一个视图下看到项目的所有业务,在项目的协作过程中自然就增加了许多沟通成本。而 KubeSphere 就是基于项目维度对容器服务进行管理的,在 KubeSphere 中一个项目对应的就是 Kubernetes 一个 Namespace,租户之间的视图是隔离的,日常只需要在自己的项目视图下进行协作即可。

我们的 DevOps 平台正在逐步的往项目集成方向发展,目前我们是按照业务域进行统一管理,一个业务域代表了一个 KubeSphere 中的一个项目,业务域下会有多个相关的业务服务,无论组织架构如何变换,业务域始终不变。

T3 出行云原生容器化平台实践_KubeSphere_02

多租户管理

KubeSphere 中的多租户管理是基于企业空间维度来完成的,企业空间是用来管理项目、DevOps 项目、应用模板和应用仓库的一种逻辑单元。我们可以在企业空间中控制资源访问权限,也可以安全地在团队内部分享资源。企业空间可以关联多个集群中的多个项目,并对企业空间中的成员进行权限管理,引用 KubeSphere 官方配图便于大家直观的理解:

T3 出行云原生容器化平台实践_DevOps_03

我们是以业务域为项目维度进行统一管理,那么企业空间作为 KubeSphere 最小的租户管理单元自然是被我们按照业务域进行划分。所以 T3 当下的多租户管理逻辑就是:企业空间(业务域)→ 集群(开发、测试等)→ 项目(业务域)。同时在企业空间中,我们也抽象出了部门管理纬度,使用 KubeSphere 的部门管理,便于我们给不同的人员赋予不同集群(环境)操作权限。

内部 DevOps 平台与 KubeSphere 的结合

T3 出行云原生容器化平台实践_Kubernetes_04

T3 容器化之前已有一套 DevOps 平台,这套 DevOps 平台交付的制品是部署在虚拟机上的。而容器化项目开展的前置条件就是必须支持容器发布,如果让现有的 DevOps 平台改造成云原生化的 DevOps 平台工作量巨大,项目风险不可控,所以我们最终选择了 DevOps 平台与 KubeSphere 的结合。内部 DevOps 平台新增容器发布功能,只进行容器服务的发布和 Pod 副本数的扩缩容操作,由 KubeSphere 对发布后的容器进行接管,给研发人员展示容器发布后的应用状态,让研发人员自助式的与容器进行交互。

可以说,KubeSphere 接管了 T3 容器化发布的后半场,研发人员执行发布后,便会来到 KubeSphere 上进行与容器的交互操作,如日志查看、监控查看、进入容器控制台、查看容器事件等。

T3 出行云原生容器化平台实践_DevOps_05

效果

  • T3 出行的业务已经全面容器化,所有的集群已被 KubeSphere 纳管,产研的日常应用维护工作都需要基于 KubeSphere 平台进行开展。
  • 得益于 KubeSphere 的以应用为中心的设计,帮用户屏蔽了底层技术细节,目前 T3 出行全体产研都可以自助式的使用 KubeSphere 进行日常的工作,也让 T3 产研从传统的应用维护模式成功的转向了云原生应用维护模式。
  • KubeSphere 集成了监控、日志、事件,提高了 T3 产研日常的人效。
  • KubeSphere 集群级别的可观测,是我们提升集群资源利用率的参考依据。

未来规划

  1. 内部 DevOps 平台与 KubeSphere 深度融合,给 T3 产研带来更好的体验。
  2. 基于 T3 的业务场景采用更多优秀的开源项目,与社区共同成长。
  3. FinOps 与 Serverless 的探索与实践。
举报

相关推荐

0 条评论