MLOps 在 GKE 上的 Jenkins 作业和部署

在之前的系列文章中，我们解释了如何编写脚本，这些脚本将在我们的 Docker 容器组中执行，作为 CI/CD MLOps 管道的一部分。在本系列中，我们将设置一个 Google Kubernetes Engine (GKE) 集群来部署这些容器。

本系列文章假定您熟悉深度学习、DevOps、Jenkins 和 Kubernetes 的基础知识。

在本系列的上一篇文章中，我们设置了一个 GKE 集群。在本文中，我们将使用 Kubernetes 作业和部署。在这个项目中，作业（旨在完成一项任务然后终止）将执行诸如模型训练和测试之类的任务。部署（除非您明确终止它，否则永远不会结束）将保持我们的预测 API 处于活动状态。

作业、服务和部署被声明为 YAML 文件，就像我们定义机密一样。

作业 YAML 文件

让我们看一下处理 AutomaticTraining-CodeCommit 作业的 YAML 文件

apiVersion: batch/v1
kind: Job
metadata:
  name: gke-training-code-commit
spec:
  backoffLimit: 1
  activeDeadlineSeconds: 900
  ttlSecondsAfterFinished: 60
  template:
    spec:
      containers:
      - name: code-commit
        image: gcr.io/automatictrainingcicd/code-commit:latest
        env:
          - name: gmail_password
            valueFrom:
              secretKeyRef:
                name: gmail-secrets
                key: gmail_password
          - name: email_address
            value: svirahonda@gmail.com
      restartPolicy: OnFailure

在上面的文件中

• kind：明确说明部署类型为“Job”。
• name：在 Kubernetes 集群中定义作业名称。
• backoffLimit：“1”表示，如果失败，作业将重试一次。 activeDeadlineSeconds：“900”将在执行时间超过 900 秒时终止作业。
• ttlSecondsAfterFinished: "60" 将在成功执行后 60 秒删除已完成的作业。

  注意： 以上两个声明可控制资源使用情况，以防我们的程序中的某些内容不允许它结束。

• name：“code-commit”为容器命名
• image：“gcr.io/automatictrainingcicd/code-commit:latest”表示要使用我们 GCR 注册表中的哪个镜像。
• env：将存储在 secrets.yaml 文件中的数据作为环境变量传递给我们的容器。
• restartPolicy: "OnFailure" 表示如果容器失败，执行我们作业的 Pod 将重新启动。

部署 YAML 文件

让我们检查 Automatic-Training-PredictionAPI 部署的 YAML 文件中最相关的标签。

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: gke-api
  labels:
    app: api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: gcr.io/automatictrainingcicd/prediction-api:latest
          imagePullPolicy: Always
          ports:
            - containerPort: 5000
          env:
            - name: gmail_password
              valueFrom:
                secretKeyRef:
                  name: gmail-secrets
                  key: gmail_password
            - name: email_address
              value: svirahonda@gmail.com
---
apiVersion: v1
kind: Service
metadata:
  name: gke-api
  labels:
    app: api
spec:
  clusterIP: 10.127.240.120
  ports:
  - port: 5000
    protocol: TCP
  selector:
    app: api
  type: LoadBalancer

• kind：“Deployment”声明执行类型。
• name：“gke-api”是部署的名称。
• replicas：“2”定义了将执行该程序的 Pod 副本数量。
• image：“gcr.io/automatictrainingcicd/prediction-api:latest”表示要使用 GCR 中的哪个容器镜像。
• imagePullPolicy：“Always”强制容器构建过程从不使用缓存的容器。
• containerPort：“5000”打开容器的 5000 端口。
• env：“label”将存储在 secrets.yaml 文件中的信息作为环境变量传递给我们的容器。

请注意，此文件中还有另一个块——类型为“LoadBalancer”的“service”。此服务将通过固定的 API 地址和套接字将流量从集群内部路由到 Deployment pod。

文件结构

也许您想知道这些东西在哪里传递给 Kubernetes，YAML 文件应保存在 .py 文件所在的同一目录中，并带有 .yaml 扩展名，然后推送到相应的存储库。这样，每个存储库都将拥有自己的 .yaml 文件，该文件将指示 Kubernetes 如何操作。 AutomaticTraining-PredictionAPI 文件结构应如下所示

您可以在此处找到我们项目的所有 YAML 文件：AutomaticTraining-CodeCommit、AutomaticTraining-DataCommit、AutomaticTraining-UnitTesting、AutomaticTraining-PredictionAPI 和 AutomaticTraining-Interface（可选）。

后续步骤

我们已准备好开始在 Kubernetes 上进行部署。构建并将容器推送到 GCR 后，您可以通过从相应的应用程序目录运行 kubectl apply -f pod.yaml 将应用程序部署到 GKE。

在下一篇文章中，我们将为该项目设置 Jenkins CI，以便开始构建和自动化我们的 MLOps 管道。敬请期待！