大家好，我是龚承明，在图菱（成都）科技有限公司任职，主要负责公司的产品系统研发以及公司IT基础设施的建设工作。本篇文章将为大家介绍下我司在采用 KubeSphere 平台实现公司业务系统容器化过程中的一些心路历程。
我司是一家面向互联网在线模版网站的素材资源供应商，为客户提供模版输出以及系统化解决方案。帮助客户输出规范化的设计产品。
背景介绍
迁移平台的云原生之路
早在 2020 年之前，公司 IT 团队规模比较小，开发还要兼职运维测试，太惨了~
发展初期，基本上由业务驱动开发。基于资源方面因素，所以在系统架构上首先是满足功能使用，快速开发推出产品，系统架构建设也是基于阿里云一步步从单体到多模块，再到微服务做演进。
公司初期业务方向是印刷类商品的私人订制，满足个性化的输出的移动端应用，配套生产的供应的订单管理系统，同时涉及到旅行行业，为旅行社提供定制线路设计的 SaaS 系统，模板海报的输出系统，以及图库等旅行社所需要的素材资源。
业务痛点
经过几年发展，业务系统服务开始增多，基础技术架构难以应付业务的快速变化，研发团队也亟需合理的开发流程来支持后续管理。
我们将主要面临困难进行了梳理，大致有以下几点：
- 开发环境和生产环境不一致
在项目迭代过程中，有时出现开发环境和生产环境配置不一致的问题，导致生产系统和业务问题不一致。 - 无统一发布管理系统
初期由于各方面管理粗狂，缺乏自动化构建系统，版本功能完后，开发需要专门手动编译，打包上线发布，过程复杂还不好管理。 - 资源协调
虽然业务系统已经采用 SpringCloud 整体微服务化，但各个服务资源的分配却无法协调。印刷服务在生成印刷文件时需要占用系统资源比普通业务系统高几倍，但又不是实时需要。之前都是专门用一台机器来做，但其实这种不太灵活。所以亟需能自动扩缩容的方案。
方案选型
基于上述的痛点，结合自身业务系统，准备进行容器化改造。
最开始接触 Kubernetes 时了解到官方提供的管理平台，通过调研和尝试了下后发现它只是管理 Kubernetes 容器的基本信息，并不是简单将业务放上去就能开箱即用，而涉及业务上的日志平台，监控系统，链路最终等基础运维体系还需自己去引入管理，最后还是通过朋友公司他们的一些经验建议使用一些集成的平台解决方案，类似 Rancher, KubeSphere 等。
经过对比后决定采用 KubeSphere，主要基于以下几点：
- Kubernetes 这块全新的知识体系要掌握达到生产落地学习时间成本较高，对于我们应用性企业需要的是能简单上手的产品。
- Rancher 侧重于运维管理，学习成本相对较高；KubeSphere 偏向与业务应用为中心，更符合我们公司情况。
- Rancher 需要自己部署 Jenkins 等插件；KubeSphere 在一些组件整合上做的较好，比如 DevOps 能做到开箱即用。而发布部署是我们目前最迫切需要的。
- KubeSphere 是由国内青云科技推出的产品，使用更符合国人习惯，而且完全开源。
实践过程
已有硬件资源
公司整个业务基础设施构建在阿里云上，包括 ECS、数据库和 OSS 存储等。
6 台 ECS 分布如下：
- ECS-1～ECS-4：业务服务。
- ECS-5：测试机器。
- ECS-6：公司内部项目管理，包括 Bug 管理，Git 等。
我们主要将实施步骤成如下几步：
- 搭建镜像仓库
在 ECS-6 上，搭建 Harbor 仓库。提供公司业务容器应用的私有镜像管理工具。
- 构建业务系统镜像
对每个业务服务添加相应配置文件 Dockerfile, 用于平台流水线发布时构建镜像。
- 准备系统环境
系统环境主要是 Kubernetes 搭建，这里主要考虑存储和网络选型。
存储
最开始考虑使用 Ceph，搭建 demo 使用后发现，如果和 Kubernetes 搭建于同一集群环境，对资源还是有一定消耗。基于目前业务设计（基本上没有有状态服务需要涉及）、以及当前业务体量，最终采用相对轻量的 NFS 共享盘方式。
- 网络
Kubernetes 主流的网络插件目前主要有 Calico 和 Flannel，我们参考社区的经验，最终选择了 Calico。
安装 KubeSphere 平台
KubeSphere 平台是按照官网提供的文档基于 Kubernetes 搭建的。我们先最小化搭建，然后在使用的过程中再根据需要开启一些所需组件。
KubeSphere 平台在插件安装这块的体验比较好，只需要对配置文件相应做调整就能很容易实现。
比如日志平台默认由 Elasticsearch 做存储，但我们已经自建有 Elasticsearch 集群，只需要调整 ks-installer 配置。
当然其中有可能会遇到一些问题，不过基本上 KubeSphere 社区上都能找到解决方案。
DevOps 实践
CI/CD 发布流程是这次改造的重点。
DevOps 项目是 KubeSphere 中的一个可插拔组件，提供了基于 Jenkins 的 CI/CD 流水线，支持自动化工作流，包括 Binary-to-Image (B2I) 和 Source-to-Image (S2I) 等。
KubeSphere DevOps 提供了开箱即用的 CI/CD 流水线，并通过图形化方式降低了学习门槛，我们就直接对官网的示例进行改造，采用配置文件基于流水线 Pipleline 构建和发布。
- 环境区分
我们的环境对应的是 KubeSphere 中的项目，通过在流水线中指定对应配置文件区分。
- 前端 Node 环境指定
由于 KubeSphere 平台默认提供的 Node.js 版本和我们所需版本有差异，所以结合自己经验对平台 Node.js 环境通过 Jenkins 插件方式进行了修改，后续流水线中指定对应版本即可。
说明：这种方式稍显麻烦，可能通过在流水线中指定镜像应该也能满足，但还未实践。
日志采集这块，KubeSphere 平台提供了 FluentBit Operator，在集群所有节点以 DaemonSet 运行，并统一部署配置了 Fluent Bit，同时查询方式能满足现有业务。只有 Elasticsearch 我们对接了自己的环境。
实践效果
历时差不多一个月时间完成基本业务系统容器化。
容器化后开发流程比之前有显著改善：
- 我们直接通过 KubeSphere 不同企业空间下的项目(Namespace)来进行开发、测试与生产环境的隔离以及通过不同角色赋予不同企业空间的权限做到细粒度的权限管理。
- 版本上线基于 Kubernetes 的副本以及探针来控制，基本上能在不影响业务情况下做到随时发布。
公司基本架构走向自动流程化。
未来规划
目前在服务网格这块还在探索阶段，服务治理（比如：监控指标，微服务流控）还是处于试用体验阶段。
后续随着业务复杂度提升后，这块还是希望能快速落地。尽量在 KubeSphere 平台中实现服务治理，做到业务与技术分离。
一些期望：
- 虽然产品体验上已尽力降低用户门槛，但云原生这块引入很多全新概念，单纯靠引导，普通用户还是难以驾驭。
- 如果咱们文档对产品功能点的实践描述上以及专业概念解释能再优化一些可能会更好。
- 同时也希望更多的人能参与到社区的维护，体会到开源的乐趣！
本文由博客一文多发平台 OpenWrite 发布！