KubeSphere 开源社区的小伙伴们,大家好。我是中通物流云平台的研发负责人杨小飞,主导容器这一块。首先感谢 KubeSphere 官方的邀请,让我有机会跟大家分享基于 KubeSphere 在生产环境的实践与开发部署经验,以及中通物流的应用场景。
业务现状和五大难点
首先,我介绍一下我们中通的业务现状。
上图是我们 2019 年的数据情况,当我们开始改造时,各类系统产生的数据流以亿 计,各类物理机和虚拟机更是成千上万 ,在线微服务更是数不胜数 。截止到 2020 年第三季度,中通快递的市场份额已扩大至 20.8%,基本上是行业领先。这么庞大的管理,随着中通业务的发展基本上是不可持续了,所以我们亟需改造。
2019 年我们面临的困难大致有以下五点 :
「1.同项目多版本多环境需求」
我们项目在迭代时,在同一个项目它已经有 N 多个版本在推进。如果仍以虚机的方式来响应资源,已经跟不上需求了。
「2.项目迭代速度要求快速初始化环境需求」
我们的版本迭代速度非常快,快到甚至是一周一迭代。
「3.资源申请麻烦,环境初始化复杂」
2019 年时,我们申请资源的方式还比较传统,走工单,搞环境初始化的交付。所以测试人员在测试时非常痛苦,要先申请资源,测试完后还要释放。
「4.现有虚机资源利用率低,僵尸机多」
有的资源随着人员的变动或者岗位的变动,变成了僵尸机,数量非常多,尤其是在开发测试环境。
「5.横向扩展差」
我们在“618”或者“双11”的时候,资源是非常稀缺的,特别是关键核心的服务,之前的做法是提前准备好资源,“618”或者“双11”结束之后,我们再把资源回收。这其实是一个非常落后的方式。
如何进行云化改造?
通过调查,我们认为云化改造可以分为三步 :云机房、云就绪和云原生。
当时我们的微服务做的比较靠前,用了 Dubbo 框架,微服务改造已经完成,但方式非常传统,是通过虚机的方式发动。而 Salt 在大量并发的时候有很多问题。所以通过评估,我们亟需对 IaaS 和容器进行改造。
因为我们介入的时候,中通整个业务的开发已经非常多、非常庞大了。我们有一个非常成熟的 DevOps 团队,把发布的 CI/CD 的需求做得非常完善。所以我们介入的话只能做 IaaS 和 Kubernetes 的建设。
KubeSphere 开发部署实践
为何选择 KubeSphere
在选型的时候,我们首先接触的就是 KubeSphere。当时我通过检索发现了 KubeSphere,然后进行试用,发现界面和体验等方面都非常棒 。试用一周之后,我们就决定,使用 KubeSphere 作为中通容器管理平台 ZKE 的建设方案 。我印象中我们当时从 KubeSphere 2.0 版本就开始采用了。同时,在 KubeSphere 的影响之下,我们很快就跟青云达成合作协议,直接使用青云的私有云产品来建设中通物流的 IaaS,而 KubeSphere 作为上层的容器 PaaS 平台承载微服务运行 。
建设方向
基于当时的现状,我们梳理了整个建设的方向。如下图所示,我们会以容器管理平台 KubeSphere 为基础来运行无状态服务,以及可视化管理 Kubernetes 和基础设施资源 。而 IaaS 这一块会提供一些有状态的服务,比如中间件。
下面这张图相信大家非常熟悉。前面三部分我们应用的效果都非常棒,暂时不作过多介绍,我还是着重讲一下微服务这部分。我们当时试用了 Istio,发现比较重,而且改造的代价比较大。因为我们的微服务本身做的就比较靠前了,所以这块我们暂时没有应用,后续可能会在 Java 的项目上尝试一下。
多租户大集群 or 单租户小集群?
选型完成后,我们开始建设。面临的第一个问题就非常棘手:我们到底是建一个多租户大集群,还是建多个单租户的小集群,把它切分开来。
与 KubeSphere 团队沟通协作,并充分评估了我们公司的需求之后,决定暂时采取多个小集群的方式,以业务场景(比如中台业务、扫描业务)或者资源应用(比如大数据、边缘的)来进行切分。我们会切成多个小集群,以上面的 DevOps 平台做 CI/CD。KubeSphere 的容器管理平台主要是做一个容器的支撑,在终端就能很好地让用户查看日志、部署、重构等等。
当时我们基于多集群设计,以 KubeSphere 2.0 为蓝图作改造 。在开发、测试和生产者三个环境中切,我们在每一个集群里都部署一套 KubeSphere,当然有一些公共的组件我们会拆出来,比如监控、日志这些。
我们整合的时候,KubeSphere 团队给了我们非常多的帮助,由于 KubeSphere 2.0 版本只支持 LDAP 对接的方式,而对接 OAuth 的计划放在3.0版本里,后来 KubeSphere 团队帮我们整合到 2.0,单独打了一个分支。因为我们公司内部的 OAuth 认证还有自定义的参数,我们开发改造后,通过扫码认证的方式很快就整合进来了。
基于 KubeSphere 二次开发实践
下面介绍一下我们在 2019 年夏天到 2020 年 10 月,我们根据自身的业务场景与 KubeSphere 融合所做的定制化开发。
1.超分设置
我们通过超分比的方式,只要你设置好 Limit ,我们很快就能把你的 Requset 算好,给你整合进来。目前生产的话,CPU是 10,内存大概是 1.5。
2.GPU 集群监控
目前我们的使用还是比较初级,只是把使用情况测出来,做 GPU 集群单独的监控数据的展示。
3.HPA(水平伸缩)
我们使用 KubeSphere,其实对水平伸缩的期望是非常高的。KubeSphere 的资源配置里有水平伸缩,所以我们把水平伸缩这一块单独抽出来设置。水平伸缩的设置配合超分设置,就可以很好地把超分比测出来。
很多核心业务已经通过 HPA 的方式,通过 KubeSphere 的界面设置,最终也获得了很好的效果,现在基本不需要运维干预 了。特别是有应急场景的需求,比如上游 MQ 消费积压了,需要我们立马扩副本,这样我们可以非常快地响应。
4.批量重启
在极端情况下可能要批量重启大量 Deployments ,我们单独把这个抽出来做了一个小模块,通过 KubeSphere 平台一键设置 ,某个项目(NameSpace)下的 Deployment 或者是集群马上可以重启,可以得到很快的响应 。
5.容器亲和性
在容器亲和性这一块,我们主要做了软性的反亲和 。因为我们有些应用它的资源使用可能是相斥的,比如都是 CPU 资源使用型的,我们简单改造了一下,加了一些亲和性的设置。
6.调度策略
在调度策略方面,因为涉及到比较敏感的后台数据,我们本来打算通过 Yaml 的方式来做。但是后面还是决定通过 KubeSphere 的高级设置页面来实现。我们简单加了一些页面的元素,把指定主机 、指定主机组 、独占主机 的功能,通过表行的形式去配置。我们现在用得特别好的是指定主机组和独占主机这两个功能。
简单介绍下独占主机的应用。我们的核心业务在晚上到凌晨六点左右,由于这个时间段服务是比较空闲的,所以用来跑大数据应用非常合适。我们通过独占主机的方式把它空出来,防止它跑满整个集群,所以只是挂了某些点。
7.网关
KubeSphere 是有独立网关 的概念的,每一个项目下都有一个单独的网关。独立网关满足了我们的生产需求(因为希望生产走独立网关的方式),但在开发测试有一个泛网关的需求,因为我们希望更快响应服务。所以我们做了一个泛网关,起了一个独立网关,所有开发、测试、域名通过泛域名 的方式直接进来。这一块配置好,通过 KubeSphere 界面简单编排一下,基本上我们的服务就直接可以访问。
8.日志收集
我们一开始是采用官方的方式,也就是通过 Fluent-Bit 的方式收集日志。但后来发现随着业务量上线越来越多,Fluent-Bit 也会经常挂掉。出现这种情况的原因,可能是我们在资源优化方面有缺陷,也可能是整个参数没有调好。所以我们决定启用 Sidecar 的方式来进行日志收集。Java 的服务都会单独起一个 Sidecar,通过 Logkit 这种小的 Agent,把它的日志推到 ElasticSearch 这种中心。在开发测试环境,我们还会用 Fluen-agent 的方式来收集日志。另外有一些生产场景,一定要保证日志的完整性,所以我们会将日志进一步进行磁盘的持久化。通过如下图中所示的四个方式,来收集全部的容器日志。
9.事件跟踪
我们直接拿了阿里云开源的 Kube-eventer 进行改造。KubeSphere 这一块我们加了事件跟踪可以配置,可以发到我们的钉钉群。尤其在生产上是比较关注业务的变动的,都可以通过定制化配到钉钉群里面。
未来规划
接下来我们可能批量推生产,我们也提了一些想法,想跟社区交流一下。
1.服务大盘
在 KubeSphere 控制台界面是以表行的形式去看我们的微服务等,但我们不知道它们之间的关系,希望通过这种图形化 的方式把它展现出来,把它关键的指标——事件、日志、异常情况等直观地呈现出来,以便于我们可视化的运营 。目前我们正在规划,明年应该会单独做。
我们想表达的是,无论任何人,包括运维、开发,只要拿到这张图就能知道我们服务的架构是什么样的,目前依赖于哪些中间件、哪些数据库,以及服务目前的状况,比如哪些服务宕了,或者哪些服务目前会有隐藏性的问题。
2.全域PODS
第二张图我们起的名字叫全域 PODS。在 KubeSphere 官方这边应该叫热力图 。我们希望从整个集群的视角上,能够看到目前所有的 PODS 现状,包括它的颜色变化和资源状态。
3.边缘计算
边缘计算这部分的规划,由我的同事王文虎为大家分享。
针对边缘计算与容器的结合,我们通过调研,最终选择了 KubeEdge ,中通适合边缘计算落地的场景包括:
「中转快件扫描数据上传」 。各个中转中心快件数据扫描后,首先经过各中转中心部署的服务进行第一次处理,然后把处理过的数据上传到数据中心。各个中转中心部署的服务现在是通过自动化脚本远程发布,目前中通所有中转中心将近 100 个,每次发布需要 5 个人/天。如果通过边缘管理方案,可以大幅度减少人力发布和运维成本,另外可以结合 Kubernetes 社区推荐的 Operator 开发模式来灵活定制发布策略。
「操作工暴力分拣自动识别」 。中通为了降低快件破损率,在各中转中心及其网点流水线安置摄像头扫描操作工日常操作,扫描到的数据会传到本地的 GPU 盒子 进行图片处理,处理完的数据传到数据中心。当前 GPU 盒子内的应用发布为手动登录发布,效率非常低;盒子经常还会出现失联,发现该问题时可能已经过了很长时间。通过 KubeEdge 边缘方案也可以解决当前发布与节点监控问题。
「各中心智慧园区项目落地」 。该项目也正在公司落地,后续也会有很多边缘场景可以借助容器技术解决当前痛点。
但是,我们也遇到了几个问题需要解决:
「海量边缘节点管理」
「KubeEdge 服务稳定性与高可用性」
「边缘节点部署与自动运维」
针对上述分享和问题,也欢迎大家跟我们进一步交流,谢谢大家!
关 于 KubeSphere
KubeSphere (https://kubesphere.io)是在 Kubernetes 之上构建的 开源容器混合云 ,提供全栈的 IT 自动化运维的能力,简化企业的 DevOps 工作流。
KubeSphere 已被 A q a r a 智 能 家 居 、 本 来 生 活 、 新 浪 、 华 夏 银 行 、 四 川 航 空 、 国 药 集 团 、 微 众 银 行 、紫金保险、中通、 中国人保寿险、中国太平保险、 中移金科、 R a d o r e 、ZaloPay 等海内外数千家企业采用。KubeSphere 提供了开发者友好 的 向导式操作界面和丰富的企业级功能,包括 多 云 与 多 集 群 管 理 、 K u b e r n e t e s 资 源 管 理 、 D e v O p s ( C I / C D ) 、 应 用 生 命 周 期 管 理 、 微 服 务 治 理 ( S e r v i c e M e s h ) 、 多 租 户 管 理 、 监 控 日 志 、 告 警 通 知 、审计事件、 存 储 与 网 络 管 理 、 G P U s u p p o r t 等功能,帮助企业快速构建一个强大和功能丰富的容器云平台。
✨ GitHub :https://github.com/kubesphere
💻 官网(中国站) :https://kubesphere.com.cn
👨💻 微信群: 请搜索添加群助手微信号 kubesphere