背景
中通物流是国内业务规模较大，第一方阵中倒退较快的快递企业。2019 年，中通各类零碎产生的数据流以亿计，各类物理机和虚拟机成千上万，在线微服务更是不可胜数。如此宏大的治理，使得中通业务倒退不可继续，因而着手云化革新。在革新过程中，中通抉择了 KubeSphere 来作为中通容器治理平台 ZKE 的建设计划。
本文是整顿自 2020 年 KubeSphere 社区组织的年度 meetup 上中通物流云平台研发负责人杨小飞及其共事王文虎的分享，次要介绍了中通物流基于 KubeSphere 在生产环境的实际与开发部署教训，以及中通物流的利用场景。
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 服务稳定性与高可用性
边缘节点部署与主动运维
针对上述分享和问题，也欢送大家跟咱们进一步交换，谢谢大家！
本文由博客一文多发平台 OpenWrite 公布！