自建平台CD发布技术选型

第一步：技术选型

ArgoCD 两种使用模式

1. 使用 Kustomize：推荐 GitOps 模式，版本在 Git 中控制；ArgoCD 检测到版本/模板变更自动触发发布，也支持手动同步。
2. 使用 Helm：同样支持多版本控制。

各方案优缺点

1. Helm

• 优点：一套模板支持多次部署。
• 缺点：配置复杂，强依赖 values 文件；配置叠加变多后极易混乱。

2. Kustomize

• 优点：采用叠加、补丁修改方式渲染模板；应用数量少时维护简单；适配 GitOps。
• 缺点：每个应用至少维护一份 kustomize.yaml；应用规模变大后维护成本高；没有 Python SDK；如果通过 Python 操作文件系统调用 Kustomize，性能较差。

3. KCL（字节开源模板管理编程语言）

• 优点：
  • 支持字段类型定义与字段校验；
  • 提供多语言 SDK；
  • 语法设计接近 Python，上手相对友好；
  • 融合 Helm、Kustomize 的能力，同时优化二者维护痛点。
• 缺点：需要额外学习 KCL 语法。

平台的处理逻辑

1. 用户在平台通过表单提交必填字段；平台做参数约束，限制用户可传入的字段，避免用户自定义参数泛滥，造成后期不可维护。
2. 平台可管理 K8s 资源：ingress、svc、deploy、sts、pod。
3. 平台后端基于 FastAPI；用户提交的全部字段输入 KCL，渲染输出部署 YAML。
4. KCL 基础模板存储在数据库；仅管理员具备编辑权限，普通用户仅只读查看（界面置灰）。
5. 兼容场景：允许用户自定义 YAML 创建特殊资源（该能力会违背第1条参数约束设计）。

回滚逻辑

每次发布，将 KCL 渲染完成后的模板以 JSON 格式存入数据库，留存版本快照。
回滚流程：

1. 对比线上资源模板与数据库历史版本快照；
2. 内容无变化则跳过执行；
3. 存在差异则使用 SSA 方式更新资源。

部署 Diff 预览能力

• 后端：使用 python difflib 做内容对比，将差异数据返回前端。
• 前端：使用 diff2html 渲染展示差异界面。

问题：用户动作映射到 KCL 渲染如何实现？

示例场景：应用是否开启 Ingress；Ingress 是否配置多个域名等?

实现思路：

1. 将用户表单输入的参数，传入封装好的 Python 业务方法；
2. 在 Python 内部调用 KCL 执行渲染，输出 YAML / JSON；
3. Python 对渲染结果做二次加工处理，生成最终 K8s 资源定义；
4. 将最终资源交由 K8s client 库执行集群操作。