應(yīng)用編排與管理中的Job及DaemonSet怎么理解

今天就跟大家聊聊有關(guān)應(yīng)用編排與管理中的Job及DaemonSet怎么理解，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

一、Job

需求來源

Job 背景問題

首先我們來看一下 Job 的需求來源。我們知道 K8s 里面，最小的調(diào)度單元是 Pod，我們可以直接通過 Pod 來運(yùn)行任務(wù)進(jìn)程。這樣做將會(huì)產(chǎn)生以下幾種問題：

• 我們?nèi)绾伪ＷC Pod 內(nèi)進(jìn)程正確的結(jié)束？

• 如何保證進(jìn)程運(yùn)行失敗后重試？

• 如何管理多個(gè)任務(wù)，且任務(wù)之間有依賴關(guān)系？

• 如何并行地運(yùn)行任務(wù)，并管理任務(wù)的隊(duì)列大小？

Job：管理任務(wù)的控制器

我們來看一下 Kubernetes 的 Job 為我們提供了什么功能：

• 首先 kubernetes 的 Job 是一個(gè)管理任務(wù)的控制器，它可以創(chuàng)建一個(gè)或多個(gè) Pod 來指定 Pod 的數(shù)量，并可以監(jiān)控它是否成功地運(yùn)行或終止；

• 我們可以根據(jù) Pod 的狀態(tài)來給 Job 設(shè)置重置的方式及重試的次數(shù)；

• 我們還可以根據(jù)依賴關(guān)系，保證上一個(gè)任務(wù)運(yùn)行完成之后再運(yùn)行下一個(gè)任務(wù)；

• 同時(shí)還可以控制任務(wù)的并行度，根據(jù)并行度來確保 Pod 運(yùn)行過程中的并行次數(shù)和總體完成大小。

用例解讀

我們根據(jù)一個(gè)實(shí)例來看一下Job是如何來完成下面的應(yīng)用的。

Job 語法

上圖是 Job 最簡單的一個(gè) yaml 格式，這里主要新引入了一個(gè) kind 叫 Job，這個(gè) Job 其實(shí)就是 job-controller 里面的一種類型。 然后 metadata 里面的 name 來指定這個(gè) Job 的名稱，下面 spec.template 里面其實(shí)就是 pod 的 spec。

這里面的內(nèi)容都是一樣的，唯一多了兩個(gè)點(diǎn)：

• 第一個(gè)是 restartPolicy，在 Job 里面我們可以設(shè)置 Never、OnFailure、Always 這三種重試策略。在希望 Job 需要重新運(yùn)行的時(shí)候，我們可以用 Never；希望在失敗的時(shí)候再運(yùn)行，再重試可以用 OnFailure；或者不論什么情況下都重新運(yùn)行時(shí) Alway；

• 另外，Job 在運(yùn)行的時(shí)候不可能去無限的重試，所以我們需要一個(gè)參數(shù)來控制重試的次數(shù)。這個(gè) backoffLimit 就是來保證一個(gè) Job 到底能重試多少次。

所以在 Job 里面，我們主要重點(diǎn)關(guān)注的一個(gè)是 restartPolicy 重啟策略和 backoffLimit 重試次數(shù)限制。

Job 狀態(tài)

Job 創(chuàng)建完成之后，我們就可以通過 kubectl get jobs 這個(gè)命令，來查看當(dāng)前 job 的運(yùn)行狀態(tài)。得到的值里面，基本就有 Job 的名稱、當(dāng)前完成了多少個(gè) Pod，進(jìn)行多長時(shí)間。

**AGE **的含義是指這個(gè) Pod 從當(dāng)前時(shí)間算起，減去它當(dāng)時(shí)創(chuàng)建的時(shí)間。這個(gè)時(shí)長主要用來告訴你 Pod 的歷史、Pod 距今創(chuàng)建了多長時(shí)間。**DURATION **主要來看我們 Job 里面的實(shí)際業(yè)務(wù)到底運(yùn)行了多長時(shí)間，當(dāng)我們的性能調(diào)優(yōu)的時(shí)候，這個(gè)參數(shù)會(huì)非常的有用。**COMPLETIONS **主要來看我們?nèi)蝿?wù)里面這個(gè) Pod 一共有幾個(gè)，然后它其中完成了多少個(gè)狀態(tài)，會(huì)在這個(gè)字段里面做顯示。 

查看 Pod

<br />下面我們來看一下 Pod，其實(shí) Job 最后的執(zhí)行單元還是 Pod。我們剛才創(chuàng)建的 Job 會(huì)創(chuàng)建出來一個(gè)叫“pi”的一個(gè) Pod，這個(gè)任務(wù)就是來計(jì)算這個(gè)圓周率，Pod 的名稱會(huì)以“${job-name}-${random-suffix}”，我們可以看一下下面 Pod 的 yaml 格式。

它比普通的 Pod 多了一個(gè)叫 ownerReferences，這個(gè)東西來聲明此 pod 是歸哪個(gè)上一層 controller 來管理。可以看到這里的 ownerReferences 是歸 batch/v1，也就是上一個(gè) Job 來管理的。這里就聲明了它的 controller 是誰，然后可以通過 pod 返查到它的控制器是誰，同時(shí)也能根據(jù) Job 來查一下它下屬有哪些 Pod。

并行運(yùn)行 Job

我們有時(shí)候有些需求：希望 Job 運(yùn)行的時(shí)候可以最大化的并行，并行出 n 個(gè) Pod 去快速地執(zhí)行。同時(shí)，由于我們的節(jié)點(diǎn)數(shù)有限制，可能也不希望同時(shí)并行的 Pod 數(shù)過多，有那么一個(gè)管道的概念，我們可以希望最大的并行度是多少，Job 控制器都可以幫我們來做到。

這里主要看兩個(gè)參數(shù)：一個(gè)是 completions，一個(gè)是 parallelism。

• 首先第一個(gè)參數(shù)是用來指定本 Pod 隊(duì)列執(zhí)行次數(shù)?？赡苓@個(gè)不是很好理解，其實(shí)可以把它認(rèn)為是這個(gè) Job 指定的可以運(yùn)行的總次數(shù)。比如這里設(shè)置成 8，即這個(gè)任務(wù)一共會(huì)被執(zhí)行 8 次；

• 第二個(gè)參數(shù)代表這個(gè)并行執(zhí)行的個(gè)數(shù)。所謂并行執(zhí)行的次數(shù)，其實(shí)就是一個(gè)管道或者緩沖器中緩沖隊(duì)列的大小，把它設(shè)置成 2，也就是說這個(gè) Job 一定要執(zhí)行 8 次，每次并行 2 個(gè) Pod，這樣的話，一共會(huì)執(zhí)行 4 個(gè)批次。

查看并行 Job 運(yùn)行

下面來看一下它的實(shí)際運(yùn)行效果，上圖就是當(dāng)這個(gè) Job 整體運(yùn)行完畢之后可以看到的效果，首先看到 job 的名字，然后看到它一共創(chuàng)建出來了 8 個(gè) pod，執(zhí)行了 2 分 23 秒，這是創(chuàng)建的時(shí)間。

接著來看真正的 pods，pods 總共出來了 8 個(gè) pod，每個(gè) pod 的狀態(tài)都是完成的，然后來看一下它的 AGE，就是時(shí)間。從下往上看，可以看到分別有 73s、40s、110s 和 2m26s。每一組都有兩個(gè) pod 時(shí)間是相同的，即：時(shí)間段是 40s 的時(shí)候是最后一個(gè)創(chuàng)建、 2m26s 是第一個(gè)創(chuàng)建的。也就是說，總是兩個(gè) pod 同時(shí)創(chuàng)建出來，并行完畢、消失，然后再創(chuàng)建、再運(yùn)行、再完畢。

比如說，剛剛我們其實(shí)通過第二個(gè)參數(shù)來控制了當(dāng)前 Job 并行執(zhí)行的次數(shù)，這里就可以了解到這個(gè)緩沖器或者說管道隊(duì)列大小的作用。

Cronjob 語法

下面來介紹另外一個(gè) Job，叫做 CronJob，其實(shí)也可以叫定時(shí)運(yùn)行 Job。CronJob 其實(shí)和 Job 大體是相似的，唯一的不同點(diǎn)就是它可以設(shè)計(jì)一個(gè)時(shí)間。比如說可以定時(shí)在幾點(diǎn)幾分執(zhí)行，特別適合晚上做一些清理任務(wù)，還有可以幾分鐘執(zhí)行一次，幾小時(shí)執(zhí)行一次等等，這就叫定時(shí)任務(wù)。

定時(shí)任務(wù)和 Job 相比會(huì)多幾個(gè)不同的字段：

• schedule：schedule 這個(gè)字段主要是設(shè)置時(shí)間格式，它的時(shí)間格式和 Linux 的 crontime 是一樣的，所以直接根據(jù) Linux 的 crontime 書寫格式來書寫就可以了。舉個(gè)例子： */1 指每分鐘去執(zhí)行一下 Job，這個(gè) Job 需要做的事情就是打印出大約時(shí)間，然后打印出“Hello from the kubernetes cluster” 這一句話；

• **startingDeadlineSeconds：**即：每次運(yùn)行 Job 的時(shí)候，它最長可以等多長時(shí)間，有時(shí)這個(gè) Job 可能運(yùn)行很長時(shí)間也不會(huì)啟動(dòng)。所以這時(shí)，如果超過較長時(shí)間的話，CronJob 就會(huì)停止這個(gè) Job；

• concurrencyPolicy：就是說是否允許并行運(yùn)行。所謂的并行運(yùn)行就是，比如說我每分鐘執(zhí)行一次，但是這個(gè) Job 可能運(yùn)行的時(shí)間特別長，假如兩分鐘才能運(yùn)行成功，也就是第二個(gè) Job 要到時(shí)間需要去運(yùn)行的時(shí)候，上一個(gè) Job 還沒完成。如果這個(gè) policy 設(shè)置為 true 的話，那么不管你前面的 Job 是否運(yùn)行完成，每分鐘都會(huì)去執(zhí)行；如果是 false，它就會(huì)等上一個(gè) Job 運(yùn)行完成之后才會(huì)運(yùn)行下一個(gè)；

• **JobsHistoryLimit：**這個(gè)就是每一次 CronJob 運(yùn)行完之后，它都會(huì)遺留上一個(gè) Job 的運(yùn)行歷史、查看時(shí)間。當(dāng)然這個(gè)額不能是無限的，所以需要設(shè)置一下歷史存留數(shù)，一般可以設(shè)置默認(rèn) 10 個(gè)或 100 個(gè)都可以，這主要取決于每個(gè)人集群不同，然后根據(jù)每個(gè)人的集群數(shù)來確定這個(gè)時(shí)間。

操作演示

Job 的編排文件

下面看一下具體如何使用 Job。

Job 的創(chuàng)建及運(yùn)行驗(yàn)證

首先看一下 job.yaml。這是一個(gè)非常簡單的計(jì)算 pi 的一個(gè)任務(wù)。使用 kubectl creat-f job.yaml，這樣 job 就能提交成功了。來看一下 kubectl.get.jobs，可以看到這個(gè) job 正在運(yùn)行；get pods 可以看到這個(gè) pod 應(yīng)該是運(yùn)行完成了，那么接下來 logs 一下這個(gè) job 以及 pod?？梢钥吹较聢D里面打印出來了圓周率。

并行 Job 的編排文件

下面再來看第二個(gè)例子：

并行 Job 的創(chuàng)建及運(yùn)行驗(yàn)證

這個(gè)例子就是指剛才的并行運(yùn)行 Job 創(chuàng)建之后，可以看到有第二個(gè)并行的 Job。

現(xiàn)在已經(jīng)有兩個(gè) Pod 正在 running，可以看到它大概執(zhí)行了快到 30s。

30s 之后它應(yīng)該會(huì)起第二個(gè)。

第一批的 pod 已經(jīng)執(zhí)行完畢，第二批的 pod 正在 running，每批次分別是兩個(gè)Pod。也就是說后面每隔 40s 左右，就會(huì)有兩個(gè) pod 在并行執(zhí)行，它一共會(huì)執(zhí)行 4 批，共 8 個(gè) pod，等到所有的 pod 執(zhí)行完畢，就是剛才所說的并行執(zhí)行的緩沖隊(duì)列功能。

過一段時(shí)間再看這個(gè) pods，可以發(fā)現(xiàn)第二批已經(jīng)執(zhí)行結(jié)束，接下來開始創(chuàng)建第三批······

Cronjob 的編排文件

下面來看第三個(gè)例子 —— CronJob。 CronJob 是每分鐘執(zhí)行一次，每次一個(gè) job。

Cronjob 的創(chuàng)建及運(yùn)行驗(yàn)證

如下圖 CronJob 已經(jīng)創(chuàng)建了，可以通過 get cronjob 來看到當(dāng)前有一個(gè) CronJob，這個(gè)時(shí)候再來看 jobs，由于它是每分鐘執(zhí)行一次，所以得稍微等一下。

同時(shí)可以看到，上一個(gè) job 還在運(yùn)行，它的時(shí)間是 2m12s 左右，它的完成度是 7/8、6/8，剛剛看到 7/8 到 8/8，也就是說我們上一個(gè)任務(wù)執(zhí)行了最后一步，而且每次都是兩個(gè)兩個(gè)地去運(yùn)行。每次兩個(gè)運(yùn)行的 job 都會(huì)讓我們?cè)谶\(yùn)行一些大型工作流或者工作任務(wù)的時(shí)候感到特別的方便。

上圖中可以看到突然出現(xiàn)了一個(gè) job，“hello-xxxx”這個(gè) job 就是剛才所說的 CronJob。它距離剛才 CronJob 提交已經(jīng)過去 1 分鐘了，這樣就會(huì)自動(dòng)創(chuàng)建出來一個(gè) job，如果不去干擾它的話，它以后大概每一分鐘都會(huì)創(chuàng)建出來這么一個(gè) job，除非等我們什么時(shí)候指定它不可以再運(yùn)行的時(shí)候它才會(huì)停止創(chuàng)建。

在這里 CronJob 其實(shí)主要是用來運(yùn)作一些清理任務(wù)或者說執(zhí)行一些定時(shí)任務(wù)。比如說 Jenkins 構(gòu)建等方面的一些任務(wù)，會(huì)特別有效。

架構(gòu)設(shè)計(jì)

Job 管理模式

我們來看一下 job 的架構(gòu)設(shè)計(jì)。Job Controller 其實(shí)還是主要去創(chuàng)建相對(duì)應(yīng)的 pod，然后 Job Controller 會(huì)去跟蹤 Job 的狀態(tài)，及時(shí)地根據(jù)我們提交的一些配置重試或者繼續(xù)創(chuàng)建。同時(shí)我們剛剛也提到，每個(gè) pod 會(huì)有它對(duì)應(yīng)的 label，來跟蹤它所屬的 Job Controller，并且還去配置并行的創(chuàng)建， 并行或者串行地去創(chuàng)建 pod。

Job 控制器

上圖是一個(gè) Job 控制器的主要流程。所有的 job 都是一個(gè) controller，它會(huì) watch 這個(gè) API Server，我們每次提交一個(gè) Job 的 yaml 都會(huì)經(jīng)過 api-server 傳到 ETCD 里面去，然后 Job Controller 會(huì)注冊(cè)幾個(gè) Handler，每當(dāng)有添加、更新、刪除等操作的時(shí)候，它會(huì)通過一個(gè)內(nèi)存級(jí)的消息隊(duì)列，發(fā)到 controller 里面。

通過 Job Controller 檢查當(dāng)前是否有運(yùn)行的 pod，如果沒有的話，通過 Scale up 把這個(gè) pod 創(chuàng)建出來；如果有的話，或者如果大于這個(gè)數(shù)，對(duì)它進(jìn)行 Scale down，如果這時(shí) pod 發(fā)生了變化，需要及時(shí) Update 它的狀態(tài)。

同時(shí)要去檢查它是否是并行的 job，或者是串行的 job，根據(jù)設(shè)置的配置并行度、串行度，及時(shí)地把 pod 的數(shù)量給創(chuàng)建出來。最后，它會(huì)把 job 的整個(gè)的狀態(tài)更新到 API Server 里面去，這樣我們就能看到呈現(xiàn)出來的最終效果了。

二、DaemonSet

需求來源

DaemonSet 背景問題

下面介紹第二個(gè)控制器：**DaemonSet。**同樣的問題：如果我們沒有 DaemonSet 會(huì)怎么樣？下面有幾個(gè)需求：

• 首先如果希望每個(gè)節(jié)點(diǎn)都運(yùn)行同樣一個(gè) pod 怎么辦？

• 如果新節(jié)點(diǎn)加入集群的時(shí)候，想要立刻感知到它，然后去部署一個(gè) pod，幫助我們初始化一些東西，這個(gè)需求如何做？

• 如果有節(jié)點(diǎn)退出的時(shí)候，希望對(duì)應(yīng)的 pod 會(huì)被刪除掉，應(yīng)該怎么操作？

• 如果 pod 狀態(tài)異常的時(shí)候，我們需要及時(shí)地監(jiān)控這個(gè)節(jié)點(diǎn)異常，然后做一些監(jiān)控或者匯報(bào)的一些動(dòng)作，那么這些東西運(yùn)用什么控制器來做？

DaemonSet：守護(hù)進(jìn)程控制器

DaemonSet 也是 Kubernetes 提供的一個(gè) default controller，它實(shí)際是做一個(gè)守護(hù)進(jìn)程的控制器，它能幫我們做到以下幾件事情：

• 首先能保證集群內(nèi)的每一個(gè)節(jié)點(diǎn)都運(yùn)行一組相同的 pod；

• 同時(shí)還能根據(jù)節(jié)點(diǎn)的狀態(tài)保證新加入的節(jié)點(diǎn)自動(dòng)創(chuàng)建對(duì)應(yīng)的 pod；

• 在移除節(jié)點(diǎn)的時(shí)候，能刪除對(duì)應(yīng)的 pod；

• 而且它會(huì)跟蹤每個(gè) pod 的狀態(tài)，當(dāng)這個(gè) pod 出現(xiàn)異常、Crash 掉了，會(huì)及時(shí)地去 recovery 這個(gè)狀態(tài)。

用例解讀

DaemonSet 語法

下面舉個(gè)例子來看一下，DaemonSet.yaml 會(huì)稍微長一些。

首先是 kind:DaemonSet。如果之前學(xué)過 deployment，其實(shí)我們?cè)倏催@個(gè) yaml 會(huì)比較簡單。例如它會(huì)有 matchLabel，通過 matchLabel 去管理對(duì)應(yīng)所屬的 pod，這個(gè) pod.label 也要和這個(gè) DaemonSet.controller.label 想匹配，它才能去根據(jù) label.selector 去找到對(duì)應(yīng)的管理 Pod。下面 spec.container 里面的東西都是一致的。<br /> <br />這里用 fluentd 來做例子。DaemonSet 最常用的點(diǎn)在于以下幾點(diǎn)內(nèi)容：

• 首先是存儲(chǔ)，GlusterFS 或者 Ceph 之類的東西，需要每臺(tái)節(jié)點(diǎn)上都運(yùn)行一個(gè)類似于 Agent 的東西，DaemonSet 就能很好地滿足這個(gè)訴求；

• 另外，對(duì)于日志收集，比如說 logstash 或者 fluentd，這些都是同樣的需求，需要每臺(tái)節(jié)點(diǎn)都運(yùn)行一個(gè) Agent，這樣的話，我們可以很容易搜集到它的狀態(tài)，把各個(gè)節(jié)點(diǎn)里面的信息及時(shí)地匯報(bào)到上面；

• 還有一個(gè)就是，需要每個(gè)節(jié)點(diǎn)去運(yùn)行一些監(jiān)控的事情，也需要每個(gè)節(jié)點(diǎn)去運(yùn)行同樣的事情，比如說 Promethues 這些東西，也需要 DaemonSet 的支持。

查看 DaemonSet 狀態(tài)

創(chuàng)建完 DaemonSet 之后，我們可以使用 kubectl get DaemonSet（DaemonSet 縮寫為 ds）。可以看到 DaemonSet 返回值和 deployment 特別像，即它當(dāng)前一共有正在運(yùn)行的幾個(gè)，然后我們需要幾個(gè)，READY 了幾個(gè)。當(dāng)然這里面，READY 都是只有 Pod，所以它最后創(chuàng)建出來所有的都是 pod。

這里有幾個(gè)參數(shù)，分別是：需要的 pod 個(gè)數(shù)、當(dāng)前已經(jīng)創(chuàng)建的 pod 個(gè)數(shù)、就緒的個(gè)數(shù)，以及所有可用的、通過健康檢查的 pod；還有 NODE SELECTOR，因?yàn)?NODE SELECTOR 在 DaemonSet 里面非常有用。有時(shí)候我們可能希望只有部分節(jié)點(diǎn)去運(yùn)行這個(gè) pod 而不是所有的節(jié)點(diǎn)，所以有些節(jié)點(diǎn)上被打了標(biāo)的話，DaemonSet 就只運(yùn)行在這些節(jié)點(diǎn)上。比如，我只希望 master 節(jié)點(diǎn)運(yùn)行某些 pod，或者只希望 Worker 節(jié)點(diǎn)運(yùn)行某些 pod，就可以使用這個(gè) NODE SELECTOR。

更新 DaemonSet

其實(shí) DaemonSet 和 deployment 特別像，它也有兩種更新策略：一個(gè)是 RollingUpdate，另一個(gè)是 OnDelete。

• RollingUpdate 其實(shí)比較好理解，就是會(huì)一個(gè)一個(gè)的更新。先更新第一個(gè) pod，然后老的 pod 被移除，通過健康檢查之后再去見第二個(gè) pod，這樣對(duì)于業(yè)務(wù)上來說會(huì)比較平滑地升級(jí)，不會(huì)中斷；

• OnDelete 其實(shí)也是一個(gè)很好的更新策略，就是模板更新之后，pod 不會(huì)有任何變化，需要我們手動(dòng)控制。我們?nèi)h除某一個(gè)節(jié)點(diǎn)對(duì)應(yīng)的 pod，它就會(huì)重建，不刪除的話它就不會(huì)重建，這樣的話對(duì)于一些我們需要手動(dòng)控制的特殊需求也會(huì)有特別好的作用。

操作演示

DaemonSet 的編排

下面舉一個(gè)例子。比如說我們?nèi)ジ牧诵?DaemonSet 的鏡像，然后看到了它的狀態(tài)，它就會(huì)去一個(gè)一個(gè)地更新。

上圖這個(gè)就是剛才 DaemonSet 的 yaml，會(huì)比剛才會(huì)多一些， 我們做一些資源的限制，這個(gè)都不影響。

DaemonSet 的創(chuàng)建與運(yùn)行驗(yàn)證

下面我們創(chuàng)建一下 DaemonSet ，然后再看一下它的狀態(tài)。下圖就是我們剛才看到的 DaemonSet 在 ready 里打出來的狀態(tài)。

從下圖中可以看到，一共有 4 個(gè) pod 被創(chuàng)建出來。為什么是 4 個(gè) pod呢？因?yàn)橹挥?4 個(gè)節(jié)點(diǎn)，所以每個(gè)節(jié)點(diǎn)上都會(huì)運(yùn)行一個(gè)對(duì)應(yīng)的 pod。

DaemonSet 的更新

這時(shí)，我們來更新 DaemonSet， 執(zhí)行完了kubectl apply -f 后，它的 DaemonSet 就已經(jīng)更新了。接下來我們?nèi)ゲ榭?DaemonSet 的更新狀態(tài)。

上圖中可以看到：DaemonSet 默認(rèn)這個(gè)是 RollingUpdate 的，我們看到是 0-4，現(xiàn)在是 1-4，也就是說它在更新第一個(gè)，第一個(gè)更新完成會(huì)去更新第二個(gè)，第二個(gè)更新完，就更新第三個(gè)······這個(gè)就是 RollingUpdate。RollingUpdate 可以做到全自動(dòng)化的更新，不用有人值守，而是一個(gè)一個(gè)地去自動(dòng)更新，更新的過程也比較平滑，這樣可以有利于我們?cè)诂F(xiàn)場發(fā)布或者做一些其他操作。<br />

上圖結(jié)尾處可以看到，整個(gè)的 DaemonSet 已經(jīng) RollingUpdate 完畢。

架構(gòu)設(shè)計(jì)

DaemonSet 管理模式

接下來看一下 DaemonSet 架構(gòu)設(shè)計(jì)。DaemonSet 還是一個(gè) controller，它最后真正的業(yè)務(wù)單元也是 Pod，DaemonSet 其實(shí)和 Job controller 特別相似，它也是通過 controller 去 watch API Server 的狀態(tài)，然后及時(shí)地添加 pod。唯一不同的是，它會(huì)監(jiān)控節(jié)點(diǎn)的狀態(tài)，節(jié)點(diǎn)新加入或者消失的時(shí)候會(huì)在節(jié)點(diǎn)上創(chuàng)建對(duì)應(yīng)的 pod，然后同時(shí)根據(jù)你配置的一些 affinity 或者 label 去選擇對(duì)應(yīng)的節(jié)點(diǎn)。

DaemonSet 控制器

最后我們來看一下 DaemonSet 的控制器，DaemonSet 其實(shí)和 Job controller 做的差不多：兩者都需要根據(jù) watch 這個(gè) API Server 的狀態(tài)?，F(xiàn)在 DaemonSet 和 Job controller 唯一的不同點(diǎn)在于，DaemonsetSet Controller需要去 watch node 的狀態(tài)，但其實(shí)這個(gè) node 的狀態(tài)還是通過 API Server 傳遞到 ETCD 上。

當(dāng)有 node 狀態(tài)節(jié)點(diǎn)發(fā)生變化時(shí)，它會(huì)通過一個(gè)內(nèi)存消息隊(duì)列發(fā)進(jìn)來，然后DaemonSet controller 會(huì)去 watch 這個(gè)狀態(tài)，看一下各個(gè)節(jié)點(diǎn)上是都有對(duì)應(yīng)的 Pod，如果沒有的話就去創(chuàng)建。當(dāng)然它會(huì)去做一個(gè)對(duì)比，如果有的話，它會(huì)比較一下版本，然后加上剛才提到的是否去做 RollingUpdate？如果沒有的話就會(huì)重新創(chuàng)建，Ondelete 刪除 pod 的時(shí)候也會(huì)去做 check 它做一遍檢查，是否去更新，或者去創(chuàng)建對(duì)應(yīng)的 pod。

當(dāng)然最后的時(shí)候，如果全部更新完了之后，它會(huì)把整個(gè) DaemonSet 的狀態(tài)去更新到 API Server 上，完成最后全部的更新。

看完上述內(nèi)容，你們對(duì)應(yīng)用編排與管理中的Job及DaemonSet怎么理解有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。