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

作者：林勇，就职于南京领行科技股份有限公司，担任云原生负责人，也是公司容器化项目的负责人。主要负责 T3 出行云原生生态相关的所有工作，如服务容器化、多 Kubernetes 集群建设、应用混部、降本增效、云原生可观测性基础设施建设等。

公司简介

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

背景介绍

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

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

选型说明

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

实践过程

多集群统一管理

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

项目管理

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

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

多租户管理

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

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

内部 DevOps 平台与 KubeSphere 的结合

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

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

效果

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

未来规划

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

本文由博客一文多发平台 OpenWrite 发布！