基于 k8s 的发布编排工具的思考

在 PAAS 平台里，应用发布、配置变更（端口、就绪/存活探针）、灰度策略、扩缩容、规格调整（CPU/MEM/DISK）、路由策略、熔断限流等，最终都要落在 Kubernetes 资源编排与变更之上。

1. 概述

• 核心链路：定义意图 → 产出清单 → 与集群对齐（apply/sync）。
• 实现思路：
  • 首先是“能写出来”（可自动生成资源清单）。
  • 然后是“能管起来”（一致性、漂移检测、审计、回滚、协同）。
  • 期间逐步抽象：将“不变的结构”做成模板，将“变化的参数”外置化。

2. 原生 client-go 直连 kube-apiserver

最直接的实现方式：后端用 client-go 调 kube-apiserver，完成 CRUD 与控制流。

2.1 原理

用 client-go 拉取/更新对象（Deployment/Service/ConfigMap 等），以编程方式表达“变更”。

2.2 简单示例

dep, _ := client.AppsV1().Deployments(ns).Get(ctx, name, getOpts)
dep.Spec.Template.Spec.Containers[0].Image = newImage
client.AppsV1().Deployments(ns).Update(ctx, dep, updateOpts)

优缺点：

• 优点：改动即生效，表达能力强，学习与接入成本低。
• 不足：与 K8s API 强耦合；无版本审计与回滚；难以规模化复用。

3. 模板渲染（抽象结构，参数外置）

在方案一基础上把“不变的结构”抽为模板，把“变化的数值”当参数传入，渲染出最终 YAML，再 kubectl 或 client-go 等方式应用到集群。模板实现可以是 Go Template、Helm、Kustomize 等。

3.1 原理

模板负责“结构”，参数负责“取值”；把相同形态的资源一次建模、多次复用。

3.2 模板示例

以 demo/template/simple-deployment.yaml 为例，通过 等占位符参数化，运行时渲染后应用到集群。

image: {{image}}
replicas: '{{replicas}}'

优缺点：

• 优点：形态清晰、复用良好；降低重复劳动和出错率。
• 不足：解决了“怎么写”的问题，但对“怎么管”（版本、审计、漂移）还不够。

4. 引入 GitOps（把“写”升级为“管”）

当模板体系成熟后，新的问题是“如何管理”：版本历史、审计与回滚、多人协同、漂移检测与持续调协。这时将模板与参数纳入 Git 管理，把 Git 作为唯一事实来源（SSOT），由控制器（如 ArgoCD）持续对齐集群状态。

4.1 原理

• 变更即 PR/MR；合入即发布；历史天然可审计可回滚。
• 控制器（ArgoCD）提供漂移检测与持续调协，保证集群与 Git 一致。
• 模板与参数可以共存于一个仓库、拆分到独立模板仓库，或依旧存 DB（但推荐以 Git 为主）。

4.2 模板选择与组织

• 渲染方式：直接读取原始 YAML、Helm 再渲染、或 Kustomize 叠加；依据场景取舍。
• 变量提取：是写在模板里，还是由上层代码合成，实质差别不大；重点是统一规范与可维护性。

4.3 Helm 片段示例

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.name }}
spec:
  replicas: {{ .Values.replicas }}
  selector:
    matchLabels:
      app: {{ .Values.name }}
  template:
    metadata:
      labels:
        app: {{ .Values.name }}
    spec:
      containers:
      - name: {{ .Values.containerName }}
        image: {{ .Values.image }}
        ports:
        - containerPort: {{ .Values.port }}

# values.yaml
name: demo-deployment
replicas: 3
containerName: web
image: nginx:1.14
port: 80

优缺点：

• 优点：把“写”纳入“管”，提供一致性、可追溯、可回滚与自动调协。
• 不足：引入仓库治理与冲突处理成本；需要制定分支与审批策略。

5. 综合对比

方案	架构定位	可扩展性	可维护性	耦合度	资源联动	适用场景
直接调用SDK	直连 kube-apiserver	高	中	高	代码显式处理	小团队起步、快速打通链路
模板渲染	结构抽象 + 参数外置	中	中	中	模板参数化支撑	通用形态、需复用与降错
GitOps	Git 为唯一事实 + 控制器调协	高	高	低	原生支持（Helm/Kustomize）	需要审计/回滚/漂移检测/协同

6. 推荐方案

• 小团队/快速起步：从方案一开始，先跑通核心能力。
• 形成通用结构：引入方案二，把不变抽模板、把变化参数化（Go Template/Helm/Kustomize 皆可）。
• 需要“管”的能力：升级到方案三（GitOps），用控制器提供审计/回滚/漂移检测/调协。