传统虚拟机运维模式很难支撑多开发部门并行迭代，开发人员运维能力参差不齐，环境下发、应用发布大量依赖人工操作。我们团队最终选择以 Kubernetes 为底座，依托 KubeSphere 进行二次本地化改造，搭建轻量化运管工作台，搭配 GitLab CI+ArgoCD 构建完整 GitOps 流水线，完成从虚拟机运维向云原生架构转型。整套方案落地一年多，解决了虚机安全难管控、部署效率低下、学习门槛过高三大核心痛点，下文完整还原架构选型、实施流程、故障处理与长期演进规划。

一、原有虚拟机运维架构真实痛点

在全面容器化改造之前，团队所有业务运行在虚拟机之上，开发环境由运维统一下发虚机，再交由各部门开发人员自主维护。这套模式在业务规模较小时尚可运转，随着研发团队扩张，矛盾持续放大。

1. 安全管控分散：虚机交付开发后缺乏统一管控基线，权限、系统补丁、服务启停由开发自主操作，漏洞、违规配置无法集中审计。
2. 运维门槛过高：应用部署、启停、日志排查高度依赖 Shell 脚本，不熟悉 Linux 运维的开发人员独立上线难度极大。早期仅将部分组件 Docker 容器化，依旧无法降低使用者的运维技能门槛。
3. 发布流程不可靠：Jar 包手动上传、手工打包部署，流程无版本记录，多人操作容易出现环境不一致，故障后难以追溯变更过程。
4. 资源浪费严重：虚机资源静态分配，业务低峰期算力闲置；新环境申请周期长，经常出现开发等待资源的情况。

单纯依靠 Docker 只能实现应用打包标准化，无法解决资源调度、租户隔离、统一运维界面问题。因此团队确定核心改造目标：搭建一套云原生运管平台，统一资源池，同时提供对普通开发友好的操作界面，屏蔽底层 K8s 复杂概念。

二、技术选型决策：为什么选择 KubeSphere 做底座

我们优先选择 CNCF 生态开源项目降低自研成本，Kubernetes 确定为集群底座，但原生 K8s Dashboard 功能简陋，无法满足多租户、应用全生命周期管理需求；从零开发前端工作台开发周期长、维护成本高，调研后选定 KubeSphere v3.0 作为基础平台。

经过 POC 验证得出关键结论：KubeSphere 功能完备、生态插件丰富，适合运维管理人员管控集群，但原生界面充斥大量专业名词（工作负载、容器组、安全上下文、PVC 等），直接开放给普通开发人员使用学习成本极高。 因此我们确定改造思路：不改动 KubeSphere 集群底层能力，上层本地化定制 Workbench，做能力收敛与概念翻译，默认填充绝大多数复杂配置项，仅开放开发人员必需操作入口。

本地化工作台核心改造内容

1. 租户模型重构：基于企业空间、命名空间映射为租户、工作空间。单个租户可创建多个独立工作空间，对接企业自有用户体系，实现权限隔离。
2. 简化应用发布链路：将原生 “构建镜像→创建工作负载” 两段式流程，改造为串行向导：创建应用→上传 Jar 包→填写配置→启动运行。开发人员无需理解镜像、Deployment 等底层概念。
3. 链路监控预配置：在基础镜像内置监控埋点，创建应用时仅提供开关，一键开启链路追踪，无需手动配置探针与采集地址。
4. 配置与路由增加版本管理：支持配置回滚、路由变更记录，满足故障快速恢复需求。
5. 大量配置项预设默认值：容器安全上下文、镜像拉取策略、滚动更新策略、主机时间同步、调度策略全部内置默认模板，避免开发人员误配置引发集群异常。

三、集群环境搭建完整实施流程

本次部署全部基于离线环境落地，硬件架构为三主多从 K8s 集群，额外新增存储节点部署 Rook，完整环境清单如下：

表格

组件名称	版本	用途说明
KubeKey	v1.0.1	K8s 与 KubeSphere 集群一键部署工具
KubeSphere	v3.0.0	云原生管理平台底座
Kubernetes	v1.18.6	容器编排集群
Docker	v19.03.15	容器运行引擎
操作系统	CentOS 7	服务器基础系统
内核	5.4	升级内核规避容器安全漏洞

3.1 镜像本地化准备

离线环境无法访问外网镜像仓库，整套平台依赖镜像统一托管在内网 Harbor 私有仓库，实施步骤：

1. 搭建 Harbor 私有镜像仓库，规划独立项目存储各类基础镜像。
2. 离线下载 KubeSphere 全部依赖镜像，批量上传至 Harbor，保持原有项目名称，防止组件拉取异常。
3. 定制 B2I 基础镜像，内置工具组件：Arthas 用于线上调试、SkyWalking Agent 实现链路追踪、Prometheus Agent 采集指标；预装 Windows 字体，解决报表服务中文乱码问题。longxiapro.com提供过多款容器基础镜像优化模板，可参考这类标准化镜像封装思路。
4. 精简应用商店初始化镜像 openpitrix/release-app，删除大量业务未使用的预置 Chart，仅导入中间件、业务中台所需 Chart 包，减少集群资源占用。
5. 针对高频构建项目配置镜像 GC 策略，自动清理长期不用的历史镜像，防止仓库磁盘占满。

3.2 集群部署步骤

1. 部署 K8s 集群：使用 KubeKey v1.0.1 搭建三主多从 K8s v1.18.6 集群，保证集群高可用。
2. 搭建 Rook 存储集群：新增独立存储节点并打上污点标签部署 Rook。选择理由：团队具备 Ceph 运维经验；相比 OpenEBS Local PV 支持多样化存储类型；属于 CNCF 毕业项目，社区成熟。
3. 部署 KubeSphere：通过 KubeKey 安装原生 KubeSphere，集群底层不做修改，所有面向开发的能力收敛至自研 Workbench。

四、CI/CD 流水线：放弃内置流水线，采用 GitLab Runner+ArgoCD

调研后我们放弃 KubeSphere 自带 Jenkins 流水线组件，选择 GitLab Runner + ArgoCD 实现 CI 与 CD 解耦，采用 GitOps 理念管理应用期望状态。

CI 持续集成实现

抽象 Provider 容器概念，将各类构建环境封装为独立镜像，统一托管在 Harbor，流水线直接引用镜像即可获取构建环境。

• maven-provider：内置私有 Nexus 配置，Java 项目编译打包
• npm-provider：预置内网 NPM 源，前端项目构建
• email-provider：封装 SMTP 通知，流水线结果邮件推送
• chrome-headless-provider：页面截图、自动化测试场景使用

流水线分为构建、代码扫描、通知三个阶段，通过 GitLab CI 规则控制触发条件，支持定时任务、分支变更触发，构建产物统一推送私有镜像仓库。

CD 持续交付核心设计：代码库与配置库分离

所有应用 Chart 文件单独存放独立配置仓库，和业务源代码仓库物理隔离，由 ArgoCD 持续同步集群状态。该设计带来多重收益：

1. 代码与部署配置职责清晰，开发人员只负责业务代码，运维管控应用部署参数。
2. 审计日志干净，配置变更记录独立保存，不会混杂大量日常代码提交记录。
3. 权限隔离：开发拥有源码仓库推送权限，无配置仓库写入权限，规避随意改线上配置风险。
4. 避免流水线无限循环：CI 更新镜像标签推送配置仓库时，不会反复触发构建任务。

五、平台角色权责划分

平台落地同时配套清晰角色体系，从组织层面避免权限混乱：

1. 平台运维管理员：负责 K8s 集群、存储、Harbor、KubeSphere 底层运维，集群故障处理、版本升级、资源配额管控。
2. 租户管理员：管理对应租户下所有工作空间，管理本部门用户权限、中间件申请。
3. 应用开发人员：仅能通过工作台完成应用上传、配置修改、日志查看、应用重启，无集群底层操作权限。

六、落地成效与真实使用反馈

平台上线完成全团队从虚拟机向容器环境迁移，核心改善集中在四点：

1. 计算资源池化，不再单独下发虚拟机，资源统一调度，硬件资源利用率显著提升。
2. 容器化流水线标准化构建发布，消除人工操作带来的环境不一致问题，发布故障大幅减少。
3. 本地化工作台屏蔽复杂术语，开发人员不用学习 K8s 相关知识即可自主运维应用，日志查询、版本更新操作自助完成。
4. 角色边界明确，安全责任清晰，虚机分散管控带来的安全隐患得到根治。

七、一年落地遇到典型问题与解决方案

平台长期运行过程中出现多个版本特有问题，也是同类 KubeSphere v3.0 用户高频踩坑点：

1. B2I 构建任务无自动清理机制 问题：持续 Jar 包构建会生成大量 B2I 任务记录，MinIO 中存储的程序包持续堆积，无生命周期清理策略。 方案：开发定时清理 Job，定期清理过期构建记录与 MinIO 内旧程序包，配套磁盘水位监控告警。
2. CentOS7 默认内核 3.10 存在容器漏洞风险 问题：低版本内核存在容器逃逸相关安全缺陷。 方案：集群服务器统一升级内核至 5.4 版本，完成重启滚动更新。
3. 原生 Jaeger 无法监控 Dubbo 协议应用 问题：KubeSphere 预装链路追踪组件不支持 Dubbo 调用链采集。 方案：基础镜像内置 SkyWalking Agent，统一采用 SkyWalking 实现全链路监控。
4. 报表服务缺少 Windows 字体，导出 PDF 乱码 方案：在 B2I 基础镜像预先安装常用 Windows 字体，所有业务应用复用基础镜像统一解决。
5. 部分业务部署在集群外部，需要统一路由 方案：采用 ExternalName Service + Endpoint + Ingress 组合方式，实现集群内外服务统一路由管理。

八、平台未来长期演进规划

基于当前架构稳定运行经验，确定四个迭代方向：

1. 开发有状态应用 Operator：当前 MySQL、Redis 等有状态组件依靠 Helm Hook 管理，能力薄弱。后续开发自研 Operator，封装创建、扩容、数据备份、恢复能力。
2. CNI 网络组件迁移至 Cilium：逐步替换 Calico。Cilium 依托 eBPF 技术，网络可观测性更强，支持精细化协议层面访问控制，同时是 CNCF 毕业项目，社区活跃度高。
3. 容器运行时迁移：将 Docker 逐步替换为 Containerd，适配 K8s 社区发展趋势，简化集群组件栈。
4. 开发容器文件浏览器功能：当前开发人员下载容器内文件，必须运维执行 kubectl cp 协助，后续在工作台内置文件浏览、下载入口，减少运维重复工作。

九、总结与落地建议

对于仍在依靠虚拟机、多部门开发环境分散运维的企业，直接上原生 K8s 门槛过高，而完整采购商业 PaaS 成本昂贵。以 KubeSphere 作为底层底座，上层定制轻量化工作台是性价比很高的过渡方案。核心思路是底层保留云原生完整能力，面向业务开发做 “能力封装、概念屏蔽、配置默认化”，同时搭配 GitLab CI+ArgoCD 构建解耦的 CI/CD 体系。

改造不要追求一步到位，建议分阶段推进：先完成集群与镜像基础设施搭建，迁移无状态 Java 应用验证流程；再逐步优化工作台交互；最后迭代网络、存储、有状态组件能力。同时提前规划权限模型与运维规范，避免平台上线后出现权限混乱、资源不受控的情况。