(二)GKE上MLOps的Jenkins作业和部署

目录

作业YAML文件

部署YAML文件

文件结构

下一步

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

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

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

作业、服务和部署都声明为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部署。

---
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地址和套接字将流量从集群内部路由到部署pod。

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

你可以找到我们的项目的所有的YAML文件：AutomaticTraining-CodeCommit，AutomaticTraining-DataCommit，AutomaticTraining，单元测试，AutomaticTraining-PredictionAPI和AutomaticTraining接口（可选）。

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

在接下来的文章中，我们将为这个项目建立Jenkins CI，以便开始建立和自动化我们的MLOps管道。

Jenkins Jobs and Deployments for MLOps on GKE - CodeProject