共计 4577 个字符，预计需要花费 12 分钟才能阅读完成。
概述
本文基于“KubeSphere & Friends 2021 Meetup 北京站”分享次要内容整顿而来，具体内容倡议观看视频，本文有肯定删减。
作者：胡涛（Daniel），马上生产金融高级云平台研发工程师。
本次分享次要分为四个局部：
- 什么是 AI 中台
- 为何须要 KubeSphere
- KubeSphere 的引入
- 二次开发和参加社区
什么是 AI 中台
首先简略介绍一下背景，对于咱们是谁？
马上生产金融股份有限公司 (简称“马上生产”) 是一家经中国银保监会批准，持有生产金融牌照的科技驱动型金融机构。截止 2020 年底，注册资本金达 40 亿元，注册用户已冲破 1.2 亿，累计发放贷款超过 5400 亿元，累计征税近 33 亿元，公司技术团队人数超过 1000 人。
咱们的技术类部门架构大抵如下：
能够看到 AI 中台团队隶属于“人工智能研究院”大部门下，与负责“云平台”的技术部两头有一个很高的部门墙。也因而，AI 中台所须要的底层云计算相干技术并不能很好的依赖于技术部，两边有不同的考核机制、指标、痛点，所以 AI 中台团队须要本人搭建底层云平台，这也是咱们引入 KubeSphere 的一个重要起因。
咱们这边次要开发的产品如下，AI 中台是作为三大中台之一，在公司外部运行在金融云之上。然而因为 AI 中台须要思考对外输入，而金融云临时没有这个布局，所以 AI 中台也须要独立的云方面的解决方案，换言之 AI 中台自身必须是一个残缺的容器云 + AI 架构。
目前产品主页大抵长这样：
首页次要展现的是监控相干信息，这些都来自 Promethues。另外从右边能够看到咱们的九大功能模块：数据中心、在线标注、我的项目开发、算法治理、训练任务、模型公布、模型 AB、利用治理等。监控信息相对来说还是比拟毛糙，下面三个圈局部是集群纬度的整体信息，包含 CPU、内存、GPU 整体信息，上面是机器纬度、利用纬度、应用人纬度别离的汇总信息。另外咱们也保留了原生的监控页面：
目前 grafana 社区并没有一个适合的 GPU 纬度展现模板，NVIDIA 也只给了一个主机纬度的绝对毛糙的 Dashboard。目前咱们用的 GPU Dashboard 是本人开发的。还有一个调用链纬度的监控：
另外日志咱们也是用的原生 kibana 来展现，对应的工具链是 Fluent Bit + Elasticsearch + Kibana。
日志这里能够看到一个额定的信息，咱们能够依据 app 纬度来聚合，也就是一个利用下的不同 Pod 产生的日志能够汇总展现。这里其实是简略地依据 pod 的 label 来实现的，将每个 Pod 打上利用相干的 label 信息，而后采集日志时将这个属性裸露进去，就能在展现时针对性汇总。在中台公布的利用有一个日志跳转按钮，转到 kibana 页面后会带上相干参数，实现该利用下全副日志聚合展现的性能。
到这里能够看到整个中台尽管看起来性能还算齐全，然而面板很多，日志监控和主页别离有各自的入口，尽管能够在主页跳转到日志和监控页面，然而这里的鉴权问题、格调对立问题等曾经很不谐和。然而咱们团队主打的是 AI 能力，人手也无限，没有太多的精力投入到对立 Dashboard 开发上，日志监控等尽管必不可少，但也不是外围能力。这也是引入 KubeSphere 的一个重要起因。前面还会具体谈到为什么引入 KubeSphere。
再介绍下整个中台的底层架构：
整个中台构建在 Kubernetes 之上，在引入 KubeSphere 之前大抵长这样，三主多从。
另外在网络上咱们做了三网隔离反对，也就是业务、治理、存储能够别离应用不同的网卡，如果用户现场有多张网卡。
对于三网隔离这里不赘述，前面我会专门写一篇博文来介绍这里的实现细节。
为什么须要 KubeSphere
接下来聊一下为什么须要 KubeSphere。
咱们应用 Kubernetes 会面临诸多问题与挑战，比方：
- 学习老本高：Kubernetes 引入了诸多新概念，要把握 Kubernetes 达到生产落地的能力须要不少的学习工夫，这里还会波及到网络、存储、零碎等方方面面常识，不是轻易一个高级开发人员花工夫就能把握的。
- 装置部署简单：目前尽管曾经有了 kubeadm 等一系列半自动化工具，能够靠近一键部署环境，然而要搭建高可用生产集群，还是须要花不少精力深刻把握工具的各种配置细节，能力很好落地利用。
- 性能组件选型简单：要落地一套容器云并不是部署 Kubernetes 就够了，这里还有日志、监控、服务网格、存储等一系列相干组件须要落地施行，每一个方向都是波及一系列可选计划，须要专门投入人力去学习、选型。
- 隐形老本高：就算部署了 Kubernetes，前期的日常运维也须要业余的团队，对于个别中小公司来说一个 Kubernetes 运维团队的人力老本也是不小的开销，很多时候花钱还招不到适合的人，往往会陷入部署了 Kubernetes，然而出问题无人能解决的难堪地步，通过重装来复原环境。
- 多租户模式实现简单，安全性低：在 Kubernetes 里只有简略的 Namespace 隔离，配合 Quota 等肯定水平上实现资源隔离，然而要 to C 利用还远远不够，很多时候咱们须要开发一套权限管理系统来适配企业内专有的账号权限管理系统来对接，老本很高。
- 短少本土化反对：Kubernetes 肯定水平上能够称为云操作系统，类比于 Linux，其实 Kubernets 更像是 kernel，咱们要残缺应用容器云能力，要在 Kubernets 之上附加很多的开源组件，就像 kernel 上要加很多的开源软件能力用起来 Linux 一样。很多企业，尤其是国企，会抉择购买 Redhat 等来享受企业级反对，专一于零碎提供的能力自身，而不想投入太多的人力去把握和运维零碎自身。Kubernetes 自身也有这样的问题，很多企业并不心愿额定投入太大的老本去应用这套解决方案，而是心愿有一个相似 Redhat 零碎的 Kubernetes 版本来简单化落地，而且心愿收费。
而咱们 AI 中台所面临的技术与挑战如下：
咱们波及的技术栈很广，AI 方向的，云计算方向的，还有工程开发的，也就是 Java + 前端等。然而咱们的人力很稀缺，在云方向只有 2 集体，除了我之外另外一个共事善于 IaaS 方向，在网络、存储等畛域能够很好 cover 住。所以剩下的容器方向、监控日志等方向，在大公司可能每个方向一个团队，加一起大几十号人做的事件，这边只有我一个人了。所以我再有想法，无限的工夫内也做不完一个平台。所以我也在寻找一个现成的解决方案，能够把本人解放出来，可能把精力投入到 AI 相干能力的建设上，比方模型训练等的 Operator 开发上，而不是整体钻研日志监控组件和 Kubernetes 最佳部署实际等。
KubeSphere 提供的对立门户、多租户、多场景整体化解决方案正好能解决我的很多痛点。KubeSphere 的架构大抵如下
不同于 OpenShift 的解决方案，KubeSphere 对 Kubernetes 没有侵入，而是基于 Operator 模式来拓展，这种形式也是我集体比拟推崇的。
KubeSphere 的引入
KubeSphere 里组件不少，面对这样一个简单软件，我的形式是通过思维导图来梳理外面的所有组件，而后最小化部署，看下集群里有些啥，而后可插拔组件一个个开启，看下多了哪些组件，这样一个个模块去梳理，最终实现对整个平台架构整体把握的目标：
KubeSphere 页面如下：
前面介绍下 KubeSphere 的部署架构：
在 KubeSphere 里能够看到一个叫做 kubesphere-system/ks-installer 的资源，简写 cc，全称是 ClusterConfiguration，外面保护了集群的配置信息。咱们在 ks-installer 里能够看到一个 ks-hook 配置，外面定义了 kind ClusterConfiguration，event add update，objectName ks-install，namespace kubesphere-system 等信息，这里也就是通知 shell-operator 当 cc 产生变更的时候要触发相干代码执行。ks-installer 的外围原理是利用 shell-operator 来监听 cc 资源的变更，而后运行集群部署流程。
每次 cc 产生 Add / Update 后，就会触发 installerRunner.py 运行，外围逻辑是:
- 更新 cc（patch 掉环境降级场景下存量 cc 和新版 cc 构造上的差别）
- 生成配置（将 cc 的 spec 和 status 存到本地，从而 installer 能够从 spec 中晓得以后冀望做什么，从 status 中能够晓得集群以后状态，不须要做什么）
- 执行前置部署流程（K8s 版本查看、ks-core 等不可或缺组件部署等)
- 可选模块部署(并发执行残余各个模块的部署流程）
而后再看下为什么配置里的变量能够被 ansible 辨认，如下所示，在 env 里指定里 ks-config.json 和 ks-status.json 两个文件，ks-installer 运行的时候会将 cc 的 spec 和 status 别离存到这两个文件里，这样 ansible 执行的时候就能够获取到集群的冀望状态和理论状态了。
每个 playbook 的入口逻辑都在 main.yaml 里，所以接着大家能够在每个模块里通过 main.yaml 来具体钻研每个模块的部署流程，串在一起也就晓得了整个 KubeSphere 是怎么部署起来的了。
而后 KubeSphere 和中台自身的一堆组件怎么一起部署呢？
咱们也参考 KubeSphere 的部署模式，加了一个 mail-installer 的 cc，而后依照上面流程来实现整个中台的部署：
二次开发与参加社区
接着聊下参加社区的问题。
对于老手举荐看下上面两个材料，外面有一些很好的前人总结，能够防止一些不必要的坑。
很多人在玩社区的过程中可能会有如下一些问题：
- 不善于英语形容问题怎么办?
- 提了 Issue 没人理怎么办?
- Pr 没有人给 Review 怎么办?
- 与 Reviews 意见分歧怎么办?
最初针对这些问题聊下我的一些思考。
- 不善于英语形容问题怎么办?
其实很多开源社区别看下面都是英文，背地有相当比例的中国人飙“中式英语”，你怯懦去说，各种语法错误其实一点关系也没有，相互能了解意思，交换的目标也就达到了。另外借助谷歌翻译等平台，其实有个一两千词汇量就齐全够用了，在开源社区没有必要谋求完满英语。
- 提了 Issue 没人理怎么办? Pr 没有人给 Review 怎么办?
社区是一个异步合作等过程，和在公司里团队开发不一样，相互喊一声就能彼此听见，及时反馈。参加社区的人都是手上有本人的本职工作，很多时候两三天上 Github 看一下也无可非议。如果你不是很着急，还是能够急躁多等几天。如果的确有须要，也能够给相干人员发个邮件，或者在微信群等及时通信路径去艾特对应人员，不过不是很举荐。
- 与 Reviews 意见分歧怎么办?
有时候玩开源就是这样，大家有本人不同的想法，谁也压服不了谁。个别大家产生分歧的是两个都能满足需要的实现形式哪个更优，其实满足需要的计划都是可承受的计划，如果你能压服 reviewer，这也是一种能力，如果不能，就承受另外一种形式，比拟也是实现需求了，能用就行。不要因为这种“辩论”而对开源流动失去信念，合作开发自身就充斥了“争执”与“斗争”，不会所有齐全依照某个人的志愿走上来。
本文由博客一文多发平台 OpenWrite 公布！
