怎样利用GitOps实现模型部署的CI/CD？

简介：为什么模型部署需要GitOps？

传统的模型部署流程通常涉及脚本执行和手动干预，这在面对模型快速迭代和严格的合规性要求时，会变得不可持续。

GitOps是一种基于Git的持续交付（Continuous Delivery）实践，它将Git仓库作为基础设施和应用程序的“唯一真相来源”（Single Source of Truth）。在AI基础设施中，将模型部署纳入GitOps范畴（即MLOps + GitOps），可以确保模型的版本、配置和环境状态完全可追溯、可审计，并实现自动化的部署和回滚。我们主要使用Kubernetes（K8s）和Argo CD来实现这一目标。

核心组件和工作流

要实现模型的GitOps CD，我们需要以下关键组件：

1. 模型/应用仓库 (CI Source): 存放模型代码和构建容器镜像的定义。CI流程（如GitHub Actions, GitLab CI）负责构建、测试模型服务镜像，并将其推送到Registry，同时更新Infra仓库中的镜像标签。
2. 基础设施仓库 (Infra/Manifests Repo): 存放所有K8s部署清单（Deployment, Service, Ingress, Argo CD Application）。这是Argo CD监控的目标仓库。
3. Argo CD: 部署在K8s集群中，持续监控Infra仓库，自动同步集群的实际状态（Actual State）到Git中定义的期望状态（Desired State）。

实操步骤：使用Argo CD部署模型服务

假设我们已经有一个名为 my-model-server:v1.0.0 的Docker镜像，并且已经安装了Kubernetes和Argo CD。

第一步：设置基础设施仓库

我们首先在基础设施仓库（例如 git@github.com:my-org/model-ops-infra.git）中定义模型的K8s部署配置。

文件路径: manifests/production/model-deployment.yaml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
apiVersion: apps/v1

kind: Deployment

metadata:

  name: ai-model-service

  namespace: production

  labels:

    app: ai-model-service

spec:

  replicas: 2

  selector:

    matchLabels:

      app: ai-model-service

  template:

    metadata:

      labels:

        app: ai-model-service

    spec:

      containers:

      - name: model-server

        # 关键：这里定义的镜像标签是Argo CD监控并强制同步的状态

        image: registry.example.com/my-model-server:v1.0.0

        ports:

        - containerPort: 8080

        env:

        - name: MODEL_PATH

          value: "/mnt/model/latest.pkl"

---

apiVersion: v1

kind: Service

metadata:

  name: ai-model-service

  namespace: production

spec:

  selector:

    app: ai-model-service

  ports:

    - protocol: TCP

      port: 80

      targetPort: 8080

  type: LoadBalancer

第二步：定义Argo CD应用（Application）

接下来，我们需要告诉Argo CD去监控这个Infra仓库的特定路径，并将其同步到K8s集群中。

文件路径: argocd/app-model-prod.yaml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
apiVersion: argoproj.io/v1alpha1

kind: Application

metadata:

  name: prod-model-deployment

  namespace: argocd

  finalizers:

    - resources-finalizer.argocd.argoproj.io

spec:

  project: default

  source:

    # 1. 指向基础设施仓库

    repoURL: https://github.com/my-org/model-ops-infra.git

    targetRevision: HEAD

    # 2. 指定K8s清单所在的目录

    path: manifests/production

  destination:

    # 3. 指定目标集群和命名空间

    server: https://kubernetes.default.svc

    namespace: production

  syncPolicy:

    automated:

      # 启用自动同步

      prune: true

      selfHeal: true

    syncOptions:

      - CreateNamespace=true

将这个 app-model-prod.yaml 文件应用到集群中（通常在Argo CD部署完成后）：

1
kubectl apply -f argocd/app-model-prod.yaml

Argo CD将立即开始监控 model-ops-infra 仓库，发现 manifests/production 目录下的K8s资源，并自动将其部署到 production 命名空间，从而完成模型的首次部署。

第三步：触发模型版本更新（CD流程）

假设数据科学家训练了一个新模型，并生成了新的服务镜像 my-model-server:v1.1.0。

核心GitOps操作： 唯一需要做的就是更新基础设施仓库中的K8s清单文件。

通常，这个更新步骤是在模型CI/CD流水线的末端自动完成的：

1. CI Pipeline构建并测试新模型 v1.1.0。
2. CI Pipeline使用脚本（如 sed 或 Kustomize/Helm）更新 model-deployment.yaml 文件中的 image: 标签。
3. CI Pipeline将更新后的YAML文件提交到 model-ops-infra 仓库并推送。

更新后的 **model-deployment.yaml 片段：**

1
2
        # 更新为新的版本标签

        image: registry.example.com/my-model-server:v1.1.0

一旦新的Commit被推送到Infra仓库，Argo CD会在设定的间隔内（通常是3分钟，或者通过WebHook实时触发）检测到Git仓库与K8s集群状态之间的差异（Drift）。

由于我们在Argo CD Application中设置了 automated: true，Argo CD将自动执行同步（Sync）操作，触发K8s Deployment进行滚动更新，将旧的 v1.0.0 容器替换为新的 v1.1.0 容器，从而实现零停机部署。

优势总结

通过这种GitOps模式部署AI模型，我们获得了以下关键优势：

• 可回滚性（Rollback）: 出现问题时，只需在Infra仓库中回滚Git Commit，Argo CD将自动将集群状态同步回历史版本。
• 审计性（Auditability）: 每次部署更改都对应一个带有提交者、时间戳和变更描述的Git Commit，满足严格的MLOps合规要求。
• 声明式部署（Declarative）: K8s集群的状态始终由Git仓库决定，避免了环境漂移（Configuration Drift）。