关于云计算:图菱科技-SaaS-系统容器化最佳实践

大家好，我是龚承明，在图菱（成都）科技有限公司任职，次要负责公司的产品零碎研发以及公司 IT 基础设施的建设工作。本篇文章将为大家介绍下我司在采纳 KubeSphere 平台实现公司业务零碎容器化过程中的一些心路历程。

我司是一家面向互联网在线模版网站的素材资源供应商，为客户提供模版输入以及系统化解决方案。帮忙客户输入规范化的设计产品。

背景介绍

迁徙平台的云原生之路

早在 2020 年之前，公司 IT 团队规模比拟小，开发还要兼职运维测试，太惨了~

倒退初期，基本上由业务驱动开发。基于资源方面因素，所以在零碎架构上首先是满足性能应用，疾速开发推出产品，零碎架构建设也是基于阿里云一步步从单体到多模块，再到微服务做演进。

公司初期业务方向是印刷类商品的私人订制，满足个性化的输入的挪动端利用，配套生产的供给的订单管理系统，同时波及到旅行行业，为旅行社提供定制线路设计的 SaaS 零碎，模板海报的输入零碎，以及图库等旅行社所须要的素材资源。

业务痛点

通过几年倒退，业务零碎服务开始增多，根底技术架构难以应酬业务的疾速变动，研发团队也亟需正当的开发流程来反对后续治理。

咱们将次要面临艰难进行了梳理，大抵有以下几点：

1. 开发环境和生产环境不统一
   在我的项目迭代过程中，有时呈现开发环境和生产环境配置不统一的问题，导致生产零碎和业务问题不统一。
2. 无对立公布管理系统
   初期因为各方面治理粗狂，不足自动化构建零碎，版本性能完后，开发须要专门手动编译，打包上线公布，过程简单还不好治理。
3. 资源协调
   尽管业务零碎曾经采纳 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 等。

咱们次要将施行步骤成如下几步：

1. 搭建镜像仓库
   在 ECS-6 上，搭建 Harbor 仓库。提供公司业务容器利用的公有镜像管理工具。

2. 构建业务零碎镜像
   对每个业务服务增加相应配置文件 Dockerfile, 用于平台流水线公布时构建镜像。

3. 筹备零碎环境
   零碎环境次要是 Kubernetes 搭建，这里次要思考存储和网络选型。

• 存储
  最开始思考应用 Ceph，搭建 demo 应用后发现，如果和 Kubernetes 搭建于同一集群环境，对资源还是有肯定耗费。

  基于目前业务设计（基本上没有有状态服务须要波及）、以及以后业务体量，最终采纳绝对轻量的 NFS 共享盘形式。

• 网络
  Kubernetes 支流的网络插件目前次要有 Calico 和 Flannel，咱们参考社区的教训，最终抉择了 Calico。

4. 装置 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 构建和公布。

1. 环境辨别

咱们的环境对应的是 KubeSphere 中的我的项目，通过在流水线中指定对应配置文件辨别。

2. 前端 Node 环境指定

因为 KubeSphere 平台默认提供的 Node.js 版本和咱们所需版本有差别，所以联合本人教训对平台 Node.js 环境通过 Jenkins 插件形式进行了批改，后续流水线中指定对应版本即可。

阐明：这种形式稍显麻烦，可能通过在流水线中指定镜像应该也能满足，但还未实际。

日志采集这块，KubeSphere 平台提供了 FluentBit Operator，在集群所有节点以 DaemonSet 运行，并对立部署配置了 Fluent Bit，同时查问形式能满足现有业务。只有 Elasticsearch 咱们对接了本人的环境。

实际成果

历时差不多一个月工夫实现根本业务零碎容器化。

容器化后开发流程比之前有显著改善：

• 咱们间接通过 KubeSphere 不同企业空间下的我的项目 (Namespace) 来进行开发、测试与生产环境的隔离以及通过不同角色赋予不同企业空间的权限做到细粒度的权限治理。
• 版本上线基于 Kubernetes 的正本以及探针来管制，基本上能在不影响业务状况下做到随时公布。

• 公司根本架构走向主动流程化。

将来布局

目前在服务网格这块还在摸索阶段，服务治理（比方：监控指标，微服务流控）还是处于试用体验阶段。

后续随着业务复杂度晋升后，这块还是心愿能疾速落地。尽量在 KubeSphere 平台中实现服务治理，做到业务与技术拆散。

一些冀望：

• 尽管产品体验上已尽力升高用户门槛，但云原生这块引入很多全新概念，单纯靠疏导，普通用户还是难以驾驭。
• 如果咱们文档对产品性能点的实际形容上以及业余概念解释能再优化一些可能会更好。
• 同时也心愿更多的人能参加到社区的保护，领会到开源的乐趣！

本文由博客一文多发平台 OpenWrite 公布！