出于某些目的，有時需要在Kubernetes的一個Pod中，連續依次運行多個Container。 這種有明確結束預期的運行，即Kubernetes的Job。 但是，雖然一個Job可以在一個Pod內運行多個Container，然而運行方式是并發的。

一種方法是在業務層處理。 比如，通過共享的本地Volume，使用文件鎖的機制，可以實現多個并發的Container依次執行。 但這需要在業務邏輯中，把并發強行改為同步，增加了開發復雜度。 如果能使用Kubernetes本身的機制實現，則減免了很大的開發工作量。

以下是另外的三種方案。

Kubernetes Job

經過調查發現，雖然containers不能依次運行，但是initContainers可以。 它是在containers運行前，執行的初始化操作，依次結束運行并且無異常后，正式的containers才會運行。 利用這一點，可以實現多個任務的依次執行，把前面的任務寫到initContainers、最后一個任務寫到containers即可。

以下為三個Containter依次執行的樣例。

--- apiVersion: batch/v1 kind: Job metadata:name: sequential-jobs spec:backoffLimit: 0template:spec:restartPolicy: NeverinitContainers:- name: job-1image: alpine:3.11command:- 'sh'- '-c'- >for i in 1 2 3;doecho "job-1 `date`";sleep 1s;done;echo code > /srv/input/codevolumeMounts:- mountPath: /srv/input/name: input- name: job-2image: alpine:3.11command:- 'sh'- '-c'- >for i in 1 2 3;doecho "job-2 `date`";sleep 1s;done;cat /srv/input/code &&echo artifact > /srv/input/output/artifactresources:requests:cpu: 3volumeMounts:- mountPath: /srv/input/name: input- mountPath: /srv/input/output/name: outputcontainers:- name: job-3image: alpine:3.11command:- 'sh'- '-c'- >echo "job-1 and job-2 completed";sleep 3s;cat /srv/output/artifactvolumeMounts:- mountPath: /srv/output/name: outputvolumes:- name: inputemptyDir: {}- name: outputemptyDir: {}securityContext:runAsUser: 2000runAsGroup: 2000fsGroup: 2000

• backoffLimit: 0，這句指定這個Job不要失敗重啟。
• volumes這部分，使用了input和output兩個emptyDir，作為輸入輸出。
• securityContext可以在鏡像默認用戶不確定的情況下，使用指定UID進行Volume操作，避免對root的依賴。

運行完畢后，日志如下：

$ kubectl logs sequential-jobs-r4725 job-1 job-1 Tue Jul 28 07:50:10 UTC 2020 job-1 Tue Jul 28 07:50:11 UTC 2020 job-1 Tue Jul 28 07:50:12 UTC 2020 $ kubectl logs sequential-jobs-r4725 job-2 job-2 Tue Jul 28 07:50:13 UTC 2020 job-2 Tue Jul 28 07:50:14 UTC 2020 job-2 Tue Jul 28 07:50:15 UTC 2020 code $ kubectl logs sequential-jobs-r4725 job-3 job-1 and job-2 completed artifact

Volcano

Volcano前身是kube-batch，聲稱在調度和管理方面，對原生Job進行了優化。 但是在核心邏輯上，還是一樣的，不能支持指定Container順序執行。

狀態轉移圖如下：

在實際測試中，暫時沒有發現在當前業務場景下，比原生Job有什么優勢。 以下是實測配置。

--- apiVersion: batch.volcano.sh/v1alpha1 kind: Job metadata:name: volcano-sequential-jobs spec:minAvailable: 1schedulerName: volcanoqueue: defaulttasks:- replicas: 1name: "task-1"template:spec:restartPolicy: NeverinitContainers:- name: job-1image: alpine:3.11command:- 'sh'- '-c'- >for i in 1 2 3;doecho "job-1 `date`";sleep 1s;done;echo code > /srv/input/codevolumeMounts:- mountPath: /srv/input/name: input- name: job-2image: alpine:3.11command:- 'sh'- '-c'- >for i in 1 2 3;doecho "job-2 `date`";sleep 1s;done;cat /srv/input/code &&echo artifact > /srv/input/output/artifactresources:requests:cpu: 3volumeMounts:- mountPath: /srv/input/name: input- mountPath: /srv/input/output/name: outputcontainers:- name: job-doneimage: alpine:3.11command:- 'sh'- '-c'- >echo "job-1 and job-2 completed";sleep 3s;cat /srv/output/artifactvolumeMounts:- mountPath: /srv/output/name: outputvolumes:- name: inputemptyDir: {}- name: outputemptyDir: {}securityContext:runAsUser: 2000runAsGroup: 2000fsGroup: 2000

上面與原生相比，雖然多了tasks這一層概念，但是在功能上并無幫助。

運行完畢后，日志如下：

$ kubectl logs volcano-sequential-jobs-task-1-0 job-1 job-1 Tue Jul 28 07:53:17 UTC 2020 job-1 Tue Jul 28 07:53:18 UTC 2020 job-1 Tue Jul 28 07:53:20 UTC 2020 $ kubectl logs volcano-sequential-jobs-task-1-0 job-2 job-2 Tue Jul 28 07:53:21 UTC 2020 job-2 Tue Jul 28 07:53:22 UTC 2020 job-2 Tue Jul 28 07:53:23 UTC 2020 code $ kubectl logs volcano-sequential-jobs-task-1-0 job-3 job-1 and job-2 completed artifact

另外，Volcano的文檔缺失嚴重，與kube-batch也不兼容。 目前看來有很多不清楚的問題。

argo

argo是更合適按順序、依賴關系執行的。 但是經評估，它有一個重大缺陷，不適合當前場景。

argo的每個Task都是獨立的Pod，不同Pod未必在同一臺機器上。 而Volume則必須使用NFS之類的網絡存儲位置，性能不符合某些需要密集本地IO的場景。

總結

argo是形式上最合適的，可以避免使用initContainers這種邪道。 但是獨立Pod的問題導致它不適合這個場景。

目前看來，原生的Job最合適，選用Volcano還需要更深入的了解。

原文來自：https://note.qidong.name/2020/08/k8s-sequential-container-in-pod/ 作者：匿蟒

總結

以上是生活随笔為你收集整理的plsql job执行多个存储过程_在Kubernetes的一个Pod内连续依次执行Container的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。