自建平台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. 用户在平台通过表单提交必填字段；平台做参数约束，限制用户可传入的字段，避免用户自定义参数泛滥，造成后期不可维护。

   平台可传参的参数:

   -D 参数	类型	说明
   appname	str	应用名，用于 Deployment/Service/Ingress 名称、labels、gw hostAliases
   namespace	str	部署命名空间
   apptype	"nginx" | "node"	决定端口映射：nginx→80，node→8000，以及 node 的 npm 启动命令
   env	"dev" | "test" | "prod"	渲染 env 环境变量；offline 中还决定域名 {app}.{env}.demo.com 和 TLS secret
   replicas	int	副本数
   ingressdomains	[{"domain": str, "secret?": str}]	仅 online 需要；每个域名生成一条 rule，填了 secret 才生成对应 tls 条目
   ingressclass	str	默认值："nginx"（Ingress 名称）
   image	str	默认值："nginx:latest"（目前实际生效的是 base.k 里的 image，模板内未覆盖）
   ingressannotations		默认值：{}，与模板内置的 hsts/ssl‑redirect 注解合并
   resources	"default" | "middle" | "height"	默认值："default"，按 apptype 查 preset（nginx 用 front_，node 用 node_）

   前端对这些字段传值到后端，后端通过kcl server渲染之后保存记录部署的yaml，字段是否处理由模板的输入参数决定。

2. 平台侧的能力模板中渲染好之后，特殊配置在平台中记录用户定义的yaml片段,然后把渲染的结果和片段相结合。

3. 平台可管理 K8s 资源：ingress、svc、deploy、sts、pod。

4. 平台后端基于 FastAPI；用户提交的全部字段输入 KCL，渲染输出部署 YAML。

5. KCL 基础模板存储在数据库；仅管理员具备编辑权限，普通用户仅只读查看（界面置灰）。

6. 兼容场景：允许用户自定义 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 库执行集群操作。

后端实现思路

• 创建新app
  app配置表
  设置基本配置域名、副本、镜像、资源大小、变量、app名称、名称空间，请求到后端，后端把配置写到一张表中。

后端接收到前端发送过来的参数，把配置发送给kcl-server,得到部署的模板渲染的时间是至少得0.4s,然后把渲染的结果记录在一张表中（版本yaml配置记录表）并记录渲染的状态，这个表除了初始时候的配置还记录了每个发布时候的渲染配置用来回滚。第一次生成的yaml不能用来回滚。
1.因为本来就没有版本记录，2.yaml中的镜像也是错的。

• app详情
  app详情中只能查看这个app的CI发送过来的镜像版本。

• 版本发布
  设计版本yaml配置记录表 和 image版本记录表
  预留一个ci推送版本的接口,根据app名称，把版本image字段的值推送到cd平台。
  如何把ci中的项目和cd中的app对应上,在创建app的时候规定app名称然后ci保持一致就行。
  自定义yaml配置表
  把app基本配置 + 镜像版本 + 自定义yaml补丁生成一个版本的版本yaml配置保存在版本yaml配置记录表并发布。

• 版本回滚
  从数据库中查询（版本yaml配置记录表）这个app的历史版本然后回滚到指定的版本。
  过滤掉第一个初始化的版本。

• 日志审计
  使用装饰器在要用审计的方法前面添加

• 创建新app-复制app配置
  查询app配置表把基本指定配置的参数进行复制，比如域名配置就不要复制到新的app中。

• 自定义高级配置，给生成的yaml打补丁
  前端配置一个yaml片段作为kcl模板中渲染不出来的配置保存在数据库中，然后在渲染模板的时候与kcl-server中渲染好的模板进行拼接之后写入数据库。

• 自动更新
  一个开关打开之后有新的版本打包，会自动推送到对应的环境，这个配置是针对环境的。

• 容器状态
  发布之后检测容器的运行状态，这个是在线的后端每多久检测一次应用状态，并返回到前端。

• 集群环境
  用户在环境管理页面添加集群的kubeconfig配置以增加集群的认证信息。