みなさん、こんにちは。GongChengmingと申します。Tuling（Chengdu）Technology Co.、Ltd.で働いており、主に同社の製品システムの研究開発とITインフラストラクチャの構築を担当しています。この記事では、KubeSphereプラットフォームを使用して、会社のビジネスシステムのコンテナー化を実装するプロセスにおける当社の精神的な旅の一部を紹介します。
当社はインターネットオンラインテンプレートウェブサイトの材料リソースサプライヤーであり、お客様にテンプレート出力と体系的なソリューションを提供しています。顧客が標準化された設計製品を出力するのを支援します。
背景紹介
プラットフォームを移行するためのクラウドネイティブパス
早くも2020年には、会社のITチームは比較的小規模であり、開発にはパートタイムの運用および保守テストも必要でしたが、これは悲惨でした〜
開発の初期段階では、基本的にはビジネス主導の開発でした。リソース要因に基づいて、システムアーキテクチャの最初のステップは、機能の使用を満たし、製品を迅速に開発して起動することです。また、システムアーキテクチャの構築は、AlibabaCloudのシングルモジュールからマルチモジュールへの段階的な進化に基づいています。マイクロサービスへ。
同社の最初のビジネスの方向性は、印刷製品のプライベートカスタマイズ、パーソナライズされた出力を満たすモバイルアプリケーション、および生産と供給をサポートするための注文管理システムです。同時に、旅行業界が関与し、旅行代理店にカスタマイズされたルートのSaaSシステムを提供します。デザイン、テンプレートポスターの出力システム、およびギャラリーなどの旅行代理店が必要とする資料リソース。
ビジネス上の問題点
数年の開発を経て、ビジネスシステムサービスが増加し始め、ビジネスの急激な変化に対応するための基本的な技術アーキテクチャは困難です。また、研究開発チームは、その後の管理をサポートするための合理的な開発プロセスを緊急に必要としています。
主な問題点を整理しました。おおまかに次のとおりです。
- 開発環境と本番環境に一貫性がありません
プロジェクトの反復の過程で、開発環境と本番環境の構成に一貫性がなく、本番システムとビジネスの問題に一貫性がない場合があります。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 等。
我们主要将实施步骤成如下几步：
- 搭建镜像仓库 在 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 发布！