出於某些目的，有時需要在 Kubernetes 的壹個 Pod 中，連續壹次運行多個 Container。這種遊戲有明確結束預期的運行，即 Kubernetes 的 Job。但是，雖然壹個 Job 可以在壹個 Pod 內運行多個 Container，然而運行方式是並發的。
壹種方法是在業務層處理。比如，通過***享的本地 Volume，使用文件鎖的機制，可以實現多個並發的 Container 依次執行。但這需要在業務邏輯中，把並發強行改為同步，增加了開發復雜度。如果能使用 Kubernetes 本身的機制實現，則減免了很大的開發工作量。
以下是另外的三種方案。
經過調查發現，雖然 containers 不能依次運行，但是可以 initContainers 可以。它是在 containers 運行前，執行的初始化操作，依次結束運行並且無異常後，正式的 containers 才會運行。利用這壹點，可以實現多個任務的依次執行，把前面的任務寫到 initContainers 、最後壹個任務寫到 containers 即可。
以下為三個 Containter 依次執行的樣例。
運行完畢後，日誌如下：
Volcano前身是kube-batch，聲稱在調度和管理方面，對原生Job進行了優化。但是在核心邏輯上，還是壹樣的，不能支持指定 Container 順序執行。
狀態轉移圖如下：
stateDiagram [ ] → Pending Pending → Aborted Pending → Running Aborted → Pending Running → Aborted Running → Completed Running → Terminated Completed → [ *** ] Terminated → []
在實際測試中，暫時沒有發現在當前業務場景下，比原生Job有什麽優勢。以下是實測配置。
上面與原生相比，雖然多了 tasks 這是壹層概念，但是在功能上並無幫助。
運行完畢後，日誌如下：
另外，Volcano 文檔缺失嚴重，與 kube-batch 也不兼容。目前看來有很多不清楚的問題。
argo是更合適按順序、依賴關系執行的。但是經評估，它有壹個重大缺陷，不適合當前場景。
argo的每個Task都是獨立的Pod，不同Pod未必在同壹臺機器上。而Volume則必須使用NFS之類的網絡存儲位置，性能不符合某些需要密集本地IO的場景。
argo 是形式上最合適的，可以避免使用 initContainers 這種邪道。但是獨立 Pod 因為問題導致它不適合這個場景。
目前看來，原生的 Job 最合適。
選用Volcano還需要更深入的了解。