Kubernetes 作业和部署

Question

我可以在单个配置文件/操作中运行作业和部署吗？部署将在哪里等待作业完成并检查它是否成功，以便它可以继续部署？

Answer 1

根据您提供我相信你可以使用Kubernetes功能，称为实现自己的目标的信息InitContainer：

Init 容器与普通容器完全一样，除了：

• 初始化容器总是运行到完成。
• 每个 init 容器必须在下一个启动之前成功完成。

如果 Pod 的 init 容器失败，Kubernetes 会反复重启 Pod，直到 init 容器成功。但是，如果 Pod 的 restartPolicy 值为 Never，Kubernetes 不会重启 Pod。

• 我将创建一个initContainerwith abusybox来运行命令 linux 以mydb在继续部署之前等待服务运行。

重现步骤： - 创建一个部署，initContainer它会运行需要在执行部署之前完成的作业：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: my-app
  name: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      run: my-app
  template:
    metadata:
      labels:
        run: my-app
    spec:
      restartPolicy: Always
      containers:
      - name: myapp-container
        image: busybox:1.28
        command: ['sh', '-c', 'echo The app is running! && sleep 3600']
      initContainers:
      - name: init-mydb
        image: busybox:1.28
        command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]

在这个领域可以使用多种命令，你只需要选择一个包含你需要的二进制文件的 docker 镜像（包括你的sequelize工作）

• 现在让我们应用它，看看部署的状态：

$ kubectl apply -f my-app.yaml 
deployment.apps/my-app created

$ kubectl get pods
NAME                      READY   STATUS     RESTARTS   AGE
my-app-6b4fb4958f-44ds7   0/1     Init:0/1   0          4s
my-app-6b4fb4958f-s7wmr   0/1     Init:0/1   0          4s

Pod 处于Init:0/1等待状态，等待 init 容器的完成。- 现在让我们创建 initcontainer 在完成任务之前等待运行的服务：

apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377

• 我们将应用它并监控 Pod 中的变化：

$ kubectl apply -f mydb-svc.yaml 
service/mydb created

$ kubectl get pods -w
NAME                      READY   STATUS     RESTARTS   AGE
my-app-6b4fb4958f-44ds7   0/1     Init:0/1   0          91s
my-app-6b4fb4958f-s7wmr   0/1     Init:0/1   0          91s
my-app-6b4fb4958f-s7wmr   0/1     PodInitializing   0          93s
my-app-6b4fb4958f-44ds7   0/1     PodInitializing   0          94s
my-app-6b4fb4958f-s7wmr   1/1     Running           0          94s
my-app-6b4fb4958f-44ds7   1/1     Running           0          95s
^C
$ kubectl get all
NAME                          READY   STATUS    RESTARTS   AGE
pod/my-app-6b4fb4958f-44ds7   1/1     Running   0          99s
pod/my-app-6b4fb4958f-s7wmr   1/1     Running   0          99s

NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/mydb         ClusterIP   10.100.106.67   <none>        80/TCP    14s

NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/my-app   2/2     2            2           99s

NAME                                DESIRED   CURRENT   READY   AGE
replicaset.apps/my-app-6b4fb4958f   2         2         2       99s

如果您需要帮助将其应用于您的环境，请告诉我。

Answer 2

尽管 initContainers 是此解决方案的一个可行选项，但如果您使用 helm 来管理和部署到集群，还有另一个选择。

Helm 具有图表挂钩Job，允许您在 Helm 图表中的其他安装发生之前运行。您提到这是为了在服务部署之前进行数据库迁移。完成此操作的一些示例 helm 配置可能是......

apiVersion: batch/v1
kind: Job
metadata:
  name: api-migration-job
  namespace: default
  labels:
    app: api-migration-job
  annotations:
    "helm.sh/hook": pre-install,pre-upgrade
    "helm.sh/hook-weight": "-1"
    "helm.sh/hook-delete-policy": before-hook-creation
spec:
  template:
    spec:
      containers:
        - name: platform-migration
        ...

这将运行作业直至完成，然后再进入 helm 图表中的安装/升级阶段。您可以看到有一个“钩子重量”变量，允许您根据需要订购这些钩子。

在我看来，这是一个比 init 容器更优雅的解决方案，并且可以实现更好的控制。