出于某些目的，有時(shí)需要在Kubernetes的一個(gè)Pod中，連續(xù)依次運(yùn)行多個(gè)Container。 這種有明確結(jié)束預(yù)期的運(yùn)行，即Kubernetes的Job。 但是，雖然一個(gè)Job可以在一個(gè)Pod內(nèi)運(yùn)行多個(gè)Container，然而運(yùn)行方式是并發(fā)的。

一種方法是在業(yè)務(wù)層處理。 比如，通過(guò)共享的本地Volume，使用文件鎖的機(jī)制，可以實(shí)現(xiàn)多個(gè)并發(fā)的Container依次執(zhí)行。 但這需要在業(yè)務(wù)邏輯中，把并發(fā)強(qiáng)行改為同步，增加了開發(fā)復(fù)雜度。 如果能使用Kubernetes本身的機(jī)制實(shí)現(xiàn)，則減免了很大的開發(fā)工作量。

以下是另外的三種方案。

Kubernetes Job

經(jīng)過(guò)調(diào)查發(fā)現(xiàn)，雖然containers不能依次運(yùn)行，但是initContainers可以。 它是在containers運(yùn)行前，執(zhí)行的初始化操作，依次結(jié)束運(yùn)行并且無(wú)異常后，正式的containers才會(huì)運(yùn)行。 利用這一點(diǎn)，可以實(shí)現(xiàn)多個(gè)任務(wù)的依次執(zhí)行，把前面的任務(wù)寫到initContainers、最后一個(gè)任務(wù)寫到containers即可。

以下為三個(gè)Containter依次執(zhí)行的樣例。

--- 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，這句指定這個(gè)Job不要失敗重啟。
• volumes這部分，使用了input和output兩個(gè)emptyDir，作為輸入輸出。
• securityContext可以在鏡像默認(rèn)用戶不確定的情況下，使用指定UID進(jìn)行Volume操作，避免對(duì)root的依賴。

運(yùn)行完畢后，日志如下：

$ 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，聲稱在調(diào)度和管理方面，對(duì)原生Job進(jìn)行了優(yōu)化。 但是在核心邏輯上，還是一樣的，不能支持指定Container順序執(zhí)行。

狀態(tài)轉(zhuǎn)移圖如下：

在實(shí)際測(cè)試中，暫時(shí)沒(méi)有發(fā)現(xiàn)在當(dāng)前業(yè)務(wù)場(chǎng)景下，比原生Job有什么優(yōu)勢(shì)。 以下是實(shí)測(cè)配置。

--- 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這一層概念，但是在功能上并無(wú)幫助。

運(yùn)行完畢后，日志如下：

$ 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的文檔缺失嚴(yán)重，與kube-batch也不兼容。 目前看來(lái)有很多不清楚的問(wèn)題。

argo

argo是更合適按順序、依賴關(guān)系執(zhí)行的。 但是經(jīng)評(píng)估，它有一個(gè)重大缺陷，不適合當(dāng)前場(chǎng)景。

argo的每個(gè)Task都是獨(dú)立的Pod，不同Pod未必在同一臺(tái)機(jī)器上。 而Volume則必須使用NFS之類的網(wǎng)絡(luò)存儲(chǔ)位置，性能不符合某些需要密集本地IO的場(chǎng)景。

總結(jié)

argo是形式上最合適的，可以避免使用initContainers這種邪道。 但是獨(dú)立Pod的問(wèn)題導(dǎo)致它不適合這個(gè)場(chǎng)景。

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。