最近在公司的數(shù)據(jù)同步項(xiàng)目（以下簡(jiǎn)稱 ZDTP）中，需要使用到分布式調(diào)度數(shù)據(jù)同步執(zhí)行單元，目前使用的方案是將數(shù)據(jù)同步執(zhí)行單元打包成鏡像，使用 K8s 進(jìn)行調(diào)度。
在 ZDTP 中，數(shù)據(jù)同步的動(dòng)作可抽象成一個(gè)執(zhí)行單元（以下稱為 worker），類似于線程執(zhí)行單元 Runnable ，Runnable 放入一個(gè)隊(duì)列中等待線程的調(diào)度執(zhí)行，執(zhí)行完 Runnable 即完成了它的使命。當(dāng)用戶在 ZDTP 控制臺(tái)中創(chuàng)建同步任務(wù)并啟動(dòng)任務(wù)時(shí)，會(huì)根據(jù)同步任務(wù)的配置，產(chǎn)生若干個(gè)用于該任務(wù)的 worker，假設(shè)這些 worker 都在本地執(zhí)行，可以將其包裝成一個(gè) Runnable，然后創(chuàng)建一個(gè)線程執(zhí)行，如下圖表示：
但是在單機(jī)模式下，就會(huì)遇到性能瓶頸，此時(shí)就需要分布式調(diào)度，將 worker 調(diào)度到其他機(jī)器執(zhí)行：
問題是我們?nèi)绾螌?worker 更好地調(diào)度到其它機(jī)器中執(zhí)行呢？
Worker 部署方式調(diào)研
1、基于虛擬機(jī)部署 Worker
Worker 在提前創(chuàng)建好的虛擬機(jī)中運(yùn)行， 任務(wù)啟動(dòng)時(shí)需要根據(jù)當(dāng)前 Worker 負(fù)載情況進(jìn)行選擇空閑的 Worker，相當(dāng)于 Worker 是以 Agent 的形式運(yùn)行，如下圖表示：
伴隨而來的缺點(diǎn)主要有以下幾點(diǎn)：
- Worker Agent 數(shù)量相對(duì)固定，虛擬機(jī)創(chuàng)建成本高，擴(kuò)/縮容麻煩；
- 任務(wù)運(yùn)行情況依賴 zk 監(jiān)聽機(jī)制，如果某個(gè)任務(wù)在運(yùn)行中掛掉了，需要自行實(shí)現(xiàn)故障轉(zhuǎn)移與自動(dòng)重啟機(jī)制，增加開發(fā)周期；
- Worker Agent 負(fù)載獲取邏輯需要項(xiàng)目實(shí)現(xiàn)，精確獲取負(fù)載信息實(shí)現(xiàn)難度大，增加開發(fā)周期。
2、基于 K8s 部署 Worker
將 Worker 打包成 Docker 鏡像，使用 K8s 對(duì) worker 容器進(jìn)行調(diào)度作業(yè)，并且一個(gè) Worker 只運(yùn)行一個(gè)任務(wù)，如下圖表示：
使用 K8s 的優(yōu)點(diǎn)如下：
- 使用 K8s 集群調(diào)度的 Worker 容器具備故障恢復(fù)功能，只要將 Pod 的重啟策略設(shè)置為 restartPolicy=Always，無論 Worker 容器在運(yùn)行過程中發(fā)生什么異常，K8s 都會(huì)自動(dòng)嘗試重啟 Worker 容器，大大減少了運(yùn)維成本，提高了數(shù)據(jù)同步的高可用性；
- 自動(dòng)實(shí)現(xiàn)負(fù)載，比如當(dāng)某個(gè)節(jié)點(diǎn)負(fù)載高，就會(huì)將 Worker 容器調(diào)度到負(fù)載低的節(jié)點(diǎn)上，更重要的是，某個(gè)節(jié)點(diǎn)宕機(jī)，其上的工作負(fù)載會(huì)被 K8s 自動(dòng)將其轉(zhuǎn)移到其它節(jié)點(diǎn)上面；
- Worker 的生命周期完全交由 K8s 集群管理，只需調(diào)用相關(guān)接口即可清楚 Worker 運(yùn)行情況，大大減少開發(fā)周期。
K8s 容器調(diào)度方案調(diào)研
K8s 集群的調(diào)度對(duì)象是 Pod，調(diào)度方式有多種，這里主要介紹以下幾種方式：
1、Deployment（全自動(dòng)調(diào)度）
在講 Deployment 前，先來說下 Replica Set，它是 K8s 一個(gè)非常重要的概念，它是在 Pod 這個(gè)抽象上更為上層的一個(gè)抽象，一般大家用 Deployment 這個(gè)抽象來做應(yīng)用的真正的管理，而 Pod 是組成 Deployment 最小的單元。它可以定義某種 Pod（比如包裝了 ZDTP Worker 容器的 Pod）在任意時(shí)刻都保持符合 Replica Set 設(shè)定的預(yù)期值， 比如 Replica Set 可預(yù)期設(shè)定 Pod 副本數(shù)，當(dāng) k8s 集群定期巡檢發(fā)現(xiàn)某種 Pod 的副本數(shù)少于 Replica Set 設(shè)定的預(yù)期值，它就會(huì)按照 Replica Set 設(shè)定的 Pod 模版創(chuàng)建 Pod 實(shí)例，使得 Pod 的數(shù)量維持在預(yù)期值，也是通過 Replica Set 的特性，實(shí)現(xiàn)了集群的高可用性，同時(shí)減少了運(yùn)維成本。
Deployment 內(nèi)部使用了 Replica Set 來實(shí)現(xiàn)，他們之間高度相似，也可以將 Deployment 看作是 Replica Set 的升級(jí)版本。
2、Job（批處理調(diào)度）
我們可以通過 k8s Job 資源對(duì)象定義并啟動(dòng)一個(gè)批處理任務(wù)，并行或者串行處理一批工作項(xiàng)（Work item），處理完成后任務(wù)就結(jié)束。
1）Job Template Expansion 模式
根據(jù) ZDTP Worker 運(yùn)行方式，我們可以使用一個(gè) Job 對(duì)像對(duì)應(yīng)一個(gè) Worker，有多少個(gè) worker 就創(chuàng)建多少個(gè) Job，除非 Pod 異常，才會(huì)重啟該 Pod，正常執(zhí)行完后 Job 就退出，如下圖表示：
2）Queue with Pod Per Work Item 模式
這種模式將客戶端生成的 worker 存放在一個(gè)隊(duì)列中，然后只會(huì)創(chuàng)建一個(gè) job 去消費(fèi)隊(duì)列中的 worker item，通過設(shè)置 parallelism 參數(shù)可以同時(shí)啟動(dòng)多少個(gè) worker Pod 同時(shí)處理 worker，值得一體的是，這種模式下的 Worker 處理程序邏輯只會(huì)從隊(duì)列拉取 worker 處理，處理完就立即退出，completions 參數(shù)用于控制正常退出的 Pod 數(shù)量，當(dāng)退出的 Pod 數(shù)量達(dá)到了 completions 后，Job 結(jié)束，即 completions 參數(shù)可以控制 Job 的處理 Worker 的數(shù)量。如下圖所示：
3）Queue with Variable Pod Count 模式
這種調(diào)度模式看起來跟 Queue with Pod Per Work Item 模式差不多，其實(shí)不然，Queue with Variable Pod Count 模式的 Job 只要有一個(gè) Pod 正常退出，即說明 Job 已經(jīng)處理完數(shù)據(jù)，處于終止?fàn)顟B(tài)了，因?yàn)樗拿總€(gè) Pod 都有查詢隊(duì)列是否還有 worker 的邏輯，一旦發(fā)現(xiàn)隊(duì)列中沒有了 worker，Pod 正常退出，因此 Queue with Variable Pod Count 模式 completions 參數(shù)只能設(shè)置 1， parallelism 參數(shù)可以同時(shí)啟動(dòng)多少個(gè) worker Pod 同時(shí)處理 worker。
這種模式也要求隊(duì)列能夠讓 Pod 感知是否還存在 worker，像 RocketMQ/Kafka 之類的消息中間件并不能做到，只會(huì)讓客戶端一直等待，因此這種模式不能選用 RocketMQ/Kafka，可以選擇數(shù)據(jù)庫或者 redis 來實(shí)現(xiàn)。如下圖所示：
當(dāng)然如果后面還有定時(shí)執(zhí)行 Worker 的需求，使用 K8s 的 cronjob（定時(shí)任務(wù)調(diào)度）是一個(gè)非常好的選擇。
3、Pod（默認(rèn)調(diào)度）
直接通過 kind=pod 的方式啟動(dòng)容器，這種方式不能設(shè)置容器的運(yùn)行實(shí)例數(shù)，即 replicas = 1，通常生產(chǎn)應(yīng)用集群都不會(huì)通過這個(gè)方式啟動(dòng)容器，因?yàn)檫@種方式啟動(dòng)容器不具備 Pod 自動(dòng)擴(kuò)縮容的特性。
值得一提的是，即使你的 Pod 副本只有 1 個(gè)，官方也推薦使用 Replica Set 的方式進(jìn)行部署。
Pod 重啟策略分析
Pod 的重啟策略包括 Always、onFailure、Never：
- Always：當(dāng)容器失效時(shí)，k8s 自動(dòng)重啟該容器；
- onFailure：當(dāng)容器終止運(yùn)行時(shí)并且退出碼不為 0 時(shí)，k8s 自動(dòng)重啟該容器；
- Never：不論容器運(yùn)行狀態(tài)如何，k8s 都不會(huì)重啟該容器
Deployment/Replica Set 必須設(shè)置為 Always（因?yàn)樗鼈兌夹枰３?Pod 期待的副本數(shù)），而 Job 只能設(shè)置為 onFailure 和 Never，以確保容器執(zhí)行完成后不再重啟，直接 Pod 啟動(dòng)容器以上三個(gè)重啟策略都可以設(shè)置。
這里需要說明一點(diǎn)，如果使用 Job，情況可能稍微復(fù)雜些：
1）Pod 重啟策略 RestartPolicy=Never
假設(shè) Job 調(diào)度過程中 Pod 發(fā)生非正常退出，盡管此時(shí)容器不再重啟，由于 Job 需要至少一個(gè) Pod 執(zhí)行完成（即 completions 最少等于 1），Job 才算完成。因此，雖然非正常退出的 Pod 不再重啟，但 Job 會(huì)嘗試重新啟動(dòng)一個(gè) Pod 執(zhí)行，直到 Pod 正常完成的數(shù)量為 completions。
$ kubectl get pod --namespace zdtp-namespace
NAME READY STATUS RESTARTS AGE
zdtp-worker-hc6ld 0/1 ContainerCannotRun 0 64s
zdtp-worker-hfblk 0/1 ContainerCannotRun 0 60s
zdtp-worker-t9f6v 0/1 ContainerCreating 0 11s
zdtp-worker-v2g7s 0/1 ContainerCannotRun 0 31s
2）Pod 重啟策略 RestartPolicy=onFailure
當(dāng) RestartPolicy=onFailure，Pod 發(fā)生非正常退出時(shí)，Pod 會(huì)嘗試重啟，直到該 Pod 正常執(zhí)行完成，此時(shí) Job 就不會(huì)重新啟動(dòng)一個(gè) Pod 執(zhí)行了，如下：
$ kubectl get pod --namespace zdtp-namespace
NAME READY STATUS RESTARTS AGE
zdtp-worker-5tbxw 0/1 CrashLoopBackOff 5 67s
如何選擇 K8s 調(diào)度策略？
以上內(nèi)容把 K8s 的調(diào)度方案與 Pod 的重啟策略都研究了一番后，接下來就需要針對(duì)項(xiàng)目的調(diào)度需求選擇合適的調(diào)度方式。
1、增量同步 Worker
增量同步 Worker 會(huì)一直同步下去，中途不停止，這意味著 Pod 的重啟策略必須為 RestartPolicy=Always，那么這種方式只能選擇 Deployment 調(diào)度或者直接創(chuàng)建 Pod 部署，但建議使用 Deployment，官方已經(jīng)說明了即使 Pod 副本為 1，依然建議使用 Deployment 進(jìn)行部署。
2、 全量同步 Worker
全量同步 Worker 在數(shù)據(jù)同步完就退出，看起來 Job 調(diào)度或者直接創(chuàng)建 Pod 部署都可以滿足，但現(xiàn)階段由于全量同步暫時(shí)沒有記錄同步進(jìn)度，因此要求中途發(fā)生任何錯(cuò)誤容器退出后都不能自動(dòng)重啟，目前的做法是當(dāng) Worker 執(zhí)行過程中發(fā)生非正常退出時(shí)，需要用戶自行刪除已同步的資源，再手動(dòng)啟動(dòng) Worker 再次進(jìn)行全量同步。
因此，Job 目前還還不適合調(diào)度 Worker Pod，全量同步 Worker 現(xiàn)階段只適合直接使用 Pod 進(jìn)行部署，且需要設(shè)置 Pod 重啟策略 RestartPolicy=Never。
