曲周住房和城乡建设局网站,网站建设不用备案的,北京高端网站建设案例,厦门网站优化推广作者#xff1a;林勇#xff0c;就职于南京领行科技股份有限公司#xff0c;担任云原生负责人#xff0c;也是公司容器化项目的负责人。主要负责 T3 出行云原生生态相关的所有工作#xff0c;如服务容器化、多 Kubernetes 集群建设、应用混部、降本增效、云原生可观测性基… 作者林勇就职于南京领行科技股份有限公司担任云原生负责人也是公司容器化项目的负责人。主要负责 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 集群级别的可观测是我们提升集群资源利用率的参考依据。
未来规划
内部 DevOps 平台与 KubeSphere 深度融合给 T3 产研带来更好的体验。基于 T3 的业务场景采用更多优秀的开源项目与社区共同成长。FinOps 与 Serverless 的探索与实践。 本文由博客一文多发平台 OpenWrite 发布
