你好，我是張磊。今天我和你分享的主題是：容器化守護進程的意義之 DaemonSet。在上一篇文章中，我和你詳細分享了使用 StatefulSet 編排“有狀態應用”的過程。從中不難看出，StatefulSet 其實就是對現有典型運維業務的容器化抽象。也就是說，你一定有方法在不使用 Kubernetes、甚至不使用容器的情況下，自己 DIY 一個類似的方案出來。但是，一旦涉及到升級、版本管理等更工程化的能力，Kubernetes 的好處，才會更加凸現。比如，如何對 StatefulSet 進行“滾動更新”(rolling update)？很簡單。你只要修改 StatefulSet 的 Pod 模板，就會自動觸發“滾動更新”:$ kubectl patch statefulset mysql --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"mysql:5.7.23"}]' statefulset.apps/mysql patched在這里，我使用了 kubectl patch 命令。它的意思是，以“補丁”的方式(JSON 格式的)修改一個 API 對象的指定字段，也就是我在后面指定的“spec/template/spec/containers/0/image”。這樣，StatefulSet Controller 就會按照與 Pod 編號相反的順序，從最后一個 Pod 開始，逐一更新這個 StatefulSet 管理的每個 Pod。而如果更新發生了錯誤，這次“滾動更新”就會停止。此外，StatefulSet 的“滾動更新”還允許我們進行更精細的控制，比如金絲雀發布(Canary Deploy)或者灰度發布，這意味著應用的多個實例中被指定的一部分不會被更新到最新的版本。這個字段，正是 StatefulSet 的 spec.updateStrategy.rollingUpdate 的 partition 字段。比如，現在我將前面這個 StatefulSet 的 partition 字段設置為 2：$ kubectl patch statefulset mysql -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}'statefulset.apps/mysql patched其中，kubectl patch 命令后面的參數(JSON 格式的)，就是 partition 字段在 API 對象里的路徑。所以，上述操作等同于直接使用 kubectl edit 命令，打開這個對象，把 partition 字段修改為 2。這樣，我就指定了當 Pod 模板發生變化的時候，比如 MySQL 鏡像更新到 5.7.23，那么只有序號大于或者等于 2 的 Pod 會被更新到這個版本。并且，如果你刪除或者重啟了序號小于 2 的 Pod，等它再次啟動后，也會保持原先的 5.7.2 版本，絕不會被升級到 5.7.23 版本。StatefulSet 可以說是 Kubernetes 項目中最為復雜的編排對象，希望你課后能認真消化，動手實踐一下這個例子。而在今天這篇文章中，我會為你重點講解一個相對輕松的知識點：DaemonSet。顧名思義，DaemonSet 的主要作用，是讓你在 Kubernetes 集群里，運行一個 Daemon Pod。 所以，這個 Pod 有如下三個特征：這個 Pod 運行在 Kubernetes 集群里的每一個節點(Node)上；每個節點上只有一個這樣的 Pod 實例；當有新的節點加入 Kubernetes 集群后，該 Pod 會自動地在新節點上被創建出來；而當舊節點被刪除后，它上面的 Pod 也相應地會被回收掉。這個機制聽起來很簡單，但 Daemon Pod 的意義確實是非常重要的。我隨便給你列舉幾個例子：各種網絡插件的 Agent 組件，都必須運行在每一個節點上，用來處理這個節點上的容器網絡；各種存儲插件的 Agent 組件，也必須運行在每一個節點上，用來在這個節點上掛載遠程存儲目錄，操作容器的 Volume 目錄；各種監控組件和日志組件，也必須運行在每一個節點上，負責這個節點上的監控信息和日志搜集。更重要的是，跟其他編排對象不一樣，DaemonSet 開始運行的時機，很多時候比整個 Kubernetes 集群出現的時機都要早。這個乍一聽起來可能有點兒奇怪。但其實你來想一下：如果這個 DaemonSet 正是一個網絡插件的 Agent 組件呢？這個時候，整個 Kubernetes 集群里還沒有可用的容器網絡，所有 Worker 節點的狀態都是 NotReady(NetworkReady=false)。這種情況下，普通的 Pod 肯定不能運行在這個集群上。所以，這也就意味著 DaemonSet 的設計，必須要有某種“過人之處”才行。為了弄清楚 DaemonSet 的工作原理，我們還是按照老規矩，先從它的 API 對象的定義說起。apiVersion: apps/v1kind: DaemonSetmetadata:name: fluentd-elasticsearchnamespace: kube-systemlabels:k8s-app: fluentd-loggingspec:selector:matchLabels:name: fluentd-elasticsearchtemplate:metadata:labels:name: fluentd-elasticsearchspec:tolerations:- key: node-role.kubernetes.io/mastereffect: NoSchedulecontainers:- name: fluentd-elasticsearchimage: k8s.gcr.io/fluentd-elasticsearch:1.20resources:limits:memory: 200Mirequests:cpu: 100mmemory: 200MivolumeMounts:- name: varlogmountPath: /var/log- name: varlibdockercontainersmountPath: /var/lib/docker/containersreadOnly: trueterminationGracePeriodSeconds: 30volumes:- name: varloghostPath:path: /var/log- name: varlibdockercontainershostPath:path: /var/lib/docker/containers這個 DaemonSet，管理的是一個 fluentd-elasticsearch 鏡像的 Pod。這個鏡像的功能非常實用：通過 fluentd 將 Docker 容器里的日志轉發到 ElasticSearch 中。可以看到，DaemonSet 跟 Deployment 其實非常相似，只不過是沒有 replicas 字段；它也使用 selector 選擇管理所有攜帶了 name=fluentd-elasticsearch 標簽的 Pod。而這些 Pod 的模板，也是用 template 字段定義的。在這個字段中，我們定義了一個使用 fluentd-elasticsearch:1.20 鏡像的容器，而且這個容器掛載了兩個 hostPath 類型的 Volume，分別對應宿主機的 /var/log 目錄和 /var/lib/docker/containers 目錄。顯然，fluentd 啟動之后，它會從這兩個目錄里搜集日志信息，并轉發給 ElasticSearch 保存。這樣，我們通過 ElasticSearch 就可以很方便地檢索這些日志了。需要注意的是，Docker 容器里應用的日志，默認會保存在宿主機的 /var/lib/docker/containers/{{. 容器 ID}}/{{. 容器 ID}}-json.log 文件里，所以這個目錄正是 fluentd 的搜集目標。那么，DaemonSet 又是如何保證每個 Node 上有且只有一個被管理的 Pod 呢？顯然，這是一個典型的“控制器模型”能夠處理的問題。DaemonSet Controller，首先從 Etcd 里獲取所有的 Node 列表，然后遍歷所有的 Node。這時，它就可以很容易地去檢查，當前這個 Node 上是不是有一個攜帶了 name=fluentd-elasticsearch 標簽的 Pod 在運行。而檢查的結果，可能有這么三種情況：沒有這種 Pod，那么就意味著要在這個 Node 上創建這樣一個 Pod；有這種 Pod，但是數量大于 1，那就說明要把多余的 Pod 從這個 Node 上刪除掉；正好只有一個這種 Pod，那說明這個節點是正常的。其中，刪除節點(Node)上多余的 Pod 非常簡單，直接調用 Kubernetes API 就可以了。但是，如何在指定的 Node 上創建新 Pod 呢？如果你已經熟悉了 Pod API 對象的話，那一定可以立刻說出答案：用 nodeSelector，選擇 Node 的名字即可。nodeSelector:name: <Node 名字 >沒錯。不過，在 Kubernetes 項目里，nodeSelector 其實已經是一個將要被廢棄的字段了。因為，現在有了一個新的、功能更完善的字段可以代替它，即：nodeAffinity。我來舉個例子：apiVersion: v1kind: Podmetadata:name: with-node-affinityspec:affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: metadata.nameoperator: Invalues:- node-geektime在這個 Pod 里，我聲明了一個 spec.affinity 字段，然后定義了一個 nodeAffinity。其中，spec.affinity 字段，是 Pod 里跟調度相關的一個字段。關于它的完整內容，我會在講解調度策略的時候再詳細闡述。而在這里，我定義的 nodeAffinity 的含義是：requiredDuringSchedulingIgnoredDuringExecution：它的意思是說，這個 nodeAffinity 必須在每次調度的時候予以考慮。同時，這也意味著你可以設置在某些情況下不考慮這個 nodeAffinity；這個 Pod，將來只允許運行在“metadata.name”是“node-geektime”的節點上。在這里，你應該注意到 nodeAffinity 的定義，可以支持更加豐富的語法，比如 operator: In(即：部分匹配；如果你定義 operator: Equal，就是完全匹配)，這也正是 nodeAffinity 會取代 nodeSelector 的原因之一。備注：其實在大多數時候，這些 Operator 語義沒啥用處。所以說，在學習開源項目的時候，一定要學會抓住“主線”。不要顧此失彼。所以，我們的 DaemonSet Controller 會在創建 Pod 的時候，自動在這個 Pod 的 API 對象里，加上這樣一個 nodeAffinity 定義。其中，需要綁定的節點名字，正是當前正在遍歷的這個 Node。當然，DaemonSet 并不需要修改用戶提交的 YAML 文件里的 Pod 模板，而是在向 Kubernetes 發起請求之前，直接修改根據模板生成的 Pod 對象。這個思路，也正是我在前面講解 Pod 對象時介紹過的。此外，DaemonSet 還會給這個 Pod 自動加上另外一個與調度相關的字段，叫作 tolerations。這個字段意味著這個 Pod，會“容忍”(Toleration)某些 Node 的“污點”(Taint)。而 DaemonSet 自動加上的 tolerations 字段，格式如下所示：apiVersion: v1kind: Podmetadata:name: with-tolerationspec:tolerations:- key: node.kubernetes.io/unschedulableoperator: Existseffect: NoSchedule這個 Toleration 的含義是：“容忍”所有被標記為 unschedulable“污點”的 Node；“容忍”的效果是允許調度。備注：關于如何給一個 Node 標記上“污點”，以及這里具體的語法定義，我會在后面介紹調度器的時候做詳細介紹。這里，你可以簡單地把“污點”理解為一種特殊的 Label。而在正常情況下，被標記了 unschedulable“污點”的 Node，是不會有任何 Pod 被調度上去的(effect: NoSchedule)。可是，DaemonSet 自動地給被管理的 Pod 加上了這個特殊的 Toleration，就使得這些 Pod 可以忽略這個限制，繼而保證每個節點上都會被調度一個 Pod。當然，如果這個節點有故障的話，這個 Pod 可能會啟動失敗，而 DaemonSet 則會始終嘗試下去，直到 Pod 啟動成功。這時，你應該可以猜到，我在前面介紹到的DaemonSet 的“過人之處”，其實就是依靠 Toleration 實現的。假如當前 DaemonSet 管理的，是一個網絡插件的 Agent Pod，那么你就必須在這個 DaemonSet 的 YAML 文件里，給它的 Pod 模板加上一個能夠“容忍”node.kubernetes.io/network-unavailable“污點”的 Toleration。正如下面這個例子所示：...template:metadata:labels:name: network-plugin-agentspec:tolerations:- key: node.kubernetes.io/network-unavailableoperator: Existseffect: NoSchedule在 Kubernetes 項目中，當一個節點的網絡插件尚未安裝時，這個節點就會被自動加上名為node.kubernetes.io/network-unavailable的“污點”。而通過這樣一個 Toleration，調度器在調度這個 Pod 的時候，就會忽略當前節點上的“污點”，從而成功地將網絡插件的 Agent 組件調度到這臺機器上啟動起來。這種機制，正是我們在部署 Kubernetes 集群的時候，能夠先部署 Kubernetes 本身、再部署網絡插件的根本原因：因為當時我們所創建的 Weave 的 YAML，實際上就是一個 DaemonSet。這里，你也可以再回顧一下第 11 篇文章《從 0 到 1：搭建一個完整的 Kubernetes 集群》中的相關內容。至此，通過上面這些內容，你應該能夠明白，DaemonSet 其實是一個非常簡單的控制器。在它的控制循環中，只需要遍歷所有節點，然后根據節點上是否有被管理 Pod 的情況，來決定是否要創建或者刪除一個 Pod。只不過，在創建每個 Pod 的時候，DaemonSet 會自動給這個 Pod 加上一個 nodeAffinity，從而保證這個 Pod 只會在指定節點上啟動。同時，它還會自動給這個 Pod 加上一個 Toleration，從而忽略節點的 unschedulable“污點”。當然，你也可以在 Pod 模板里加上更多種類的 Toleration，從而利用 DaemonSet 實現自己的目的。比如，在這個 fluentd-elasticsearch DaemonSet 里，我就給它加上了這樣的 Toleration：tolerations:- key: node-role.kubernetes.io/mastereffect: NoSchedule這是因為在默認情況下，Kubernetes 集群不允許用戶在 Master 節點部署 Pod。因為，Master 節點默認攜帶了一個叫作node-role.kubernetes.io/master的“污點”。所以，為了能在 Master 節點上部署 DaemonSet 的 Pod，我就必須讓這個 Pod“容忍”這個“污點”。在理解了 DaemonSet 的工作原理之后，接下來我就通過一個具體的實踐來幫你更深入地掌握 DaemonSet 的使用方法。備注：需要注意的是，在 Kubernetes v1.11 之前，由于調度器尚不完善，DaemonSet 是由 DaemonSet Controller 自行調度的，即它會直接設置 Pod 的 spec.nodename 字段，這樣就可以跳過調度器了。但是，這樣的做法很快就會被廢除，所以在這里我也不推薦你再花時間學習這個流程了。首先，創建這個 DaemonSet 對象：$ kubectl create -f fluentd-elasticsearch.yaml需要注意的是，在 DaemonSet 上，我們一般都應該加上 resources 字段，來限制它的 CPU 和內存使用，防止它占用過多的宿主機資源。而創建成功后，你就能看到，如果有 N 個節點，就會有 N 個 fluentd-elasticsearch Pod 在運行。比如在我們的例子里，會有兩個 Pod，如下所示：$ kubectl get pod -n kube-system -l name=fluentd-elasticsearchNAME? ? ? ? ? ? ? ? ? ? ? ? ? READY? ?? STATUS? ? RESTARTS?? AGEfluentd-elasticsearch-dqfv9?? 1/1? ? ?? Running?? 0? ? ? ? ? 53mfluentd-elasticsearch-pf9z5?? 1/1? ? ?? Running?? 0? ? ? ? ? 53m而如果你此時通過 kubectl get 查看一下 Kubernetes 集群里的 DaemonSet 對象：$ kubectl get ds -n kube-system fluentd-elasticsearchNAME? ? ? ? ? ? ? ? ? ? DESIRED?? CURRENT?? READY? ?? UP-TO-DATE?? AVAILABLE?? NODE SELECTOR?? AGEfluentd-elasticsearch?? 2? ? ? ?? 2? ? ? ?? 2? ? ? ?? 2? ? ? ? ? ? 2? ? ? ? ?? <none>? ? ? ? ? 1h備注：Kubernetes 里比較長的 API 對象都有短名字，比如 DaemonSet 對應的是 ds，Deployment 對應的是 deploy。就會發現 DaemonSet 和 Deployment 一樣，也有 DESIRED、CURRENT 等多個狀態字段。這也就意味著，DaemonSet 可以像 Deployment 那樣，進行版本管理。這個版本，可以使用 kubectl rollout history 看到：$ kubectl rollout history daemonset fluentd-elasticsearch -n kube-systemdaemonsets "fluentd-elasticsearch"REVISION? CHANGE-CAUSE1? ? ? ?? <none>接下來，我們來把這個 DaemonSet 的容器鏡像版本到 v2.2.0：$ kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=k8s.gcr.io/fluentd-elasticsearch:v2.2.0 --record -n=kube-system這個 kubectl set image 命令里，第一個 fluentd-elasticsearch 是 DaemonSet 的名字，第二個 fluentd-elasticsearch 是容器的名字。這時候，我們可以使用 kubectl rollout status 命令看到這個“滾動更新”的過程，如下所示：$ kubectl rollout status ds/fluentd-elasticsearch -n kube-systemWaiting for daemon set "fluentd-elasticsearch" rollout to finish: 0 out of 2 new pods have been updated...Waiting for daemon set "fluentd-elasticsearch" rollout to finish: 0 out of 2 new pods have been updated...Waiting for daemon set "fluentd-elasticsearch" rollout to finish: 1 of 2 updated pods are available...daemon set "fluentd-elasticsearch" successfully rolled out注意，由于這一次我在升級命令后面加上了–record 參數，所以這次升級使用到的指令就會自動出現在 DaemonSet 的 rollout history 里面，如下所示：$ kubectl rollout history daemonset fluentd-elasticsearch -n kube-systemdaemonsets "fluentd-elasticsearch"REVISION? CHANGE-CAUSE1? ? ? ?? <none>2? ? ? ?? kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=k8s.gcr.io/fluentd-elasticsearch:v2.2.0 --namespace=kube-system --record=true有了版本號，你也就可以像 Deployment 一樣，將 DaemonSet 回滾到某個指定的歷史版本了。而我在前面的文章中講解 Deployment 對象的時候，曾經提到過，Deployment 管理這些版本，靠的是“一個版本對應一個 ReplicaSet 對象”。可是，DaemonSet 控制器操作的直接就是 Pod，不可能有 ReplicaSet 這樣的對象參與其中。那么，它的這些版本又是如何維護的呢？所謂，一切皆對象！在 Kubernetes 項目中，任何你覺得需要記錄下來的狀態，都可以被用 API 對象的方式實現。當然，“版本”也不例外。Kubernetes v1.7 之后添加了一個 API 對象，名叫ControllerRevision，專門用來記錄某種 Controller 對象的版本。比如，你可以通過如下命令查看 fluentd-elasticsearch 對應的 ControllerRevision：$ kubectl get controllerrevision -n kube-system -l name=fluentd-elasticsearchNAME? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? CONTROLLER? ? ? ? ? ? ? ? ? ? ? ? ? ?? REVISION?? AGEfluentd-elasticsearch-64dc6799c9?? daemonset.apps/fluentd-elasticsearch?? 2? ? ? ? ? 1h而如果你使用 kubectl describe 查看這個 ControllerRevision 對象：$ kubectl describe controllerrevision fluentd-elasticsearch-64dc6799c9 -n kube-systemName:? ? ? ?? fluentd-elasticsearch-64dc6799c9Namespace:? ? kube-systemLabels:? ? ?? controller-revision-hash=2087235575name=fluentd-elasticsearchAnnotations:? deprecated.daemonset.template.generation=2kubernetes.io/change-cause=kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=k8s.gcr.io/fluentd-elasticsearch:v2.2.0 --record=true --namespace=kube-systemAPI Version:? apps/v1Data:Spec:Template:$ Patch:? replaceMetadata:Creation Timestamp:? <nil>Labels:Name:? fluentd-elasticsearchSpec:Containers:Image:? ? ? ? ? ? ? k8s.gcr.io/fluentd-elasticsearch:v2.2.0Image Pull Policy:? IfNotPresentName:? ? ? ? ? ? ?? fluentd-elasticsearch...Revision:? ? ? ? ? ? ? ? ? 2Events:? ? ? ? ? ? ? ? ? ? <none>就會看到，這個 ControllerRevision 對象，實際上是在 Data 字段保存了該版本對應的完整的 DaemonSet 的 API 對象。并且，在 Annotation 字段保存了創建這個對象所使用的 kubectl 命令。接下來，我們可以嘗試將這個 DaemonSet 回滾到 Revision=1 時的狀態：$ kubectl rollout undo daemonset fluentd-elasticsearch --to-revision=1 -n kube-systemdaemonset.extensions/fluentd-elasticsearch rolled back這個 kubectl rollout undo 操作，實際上相當于讀取到了 Revision=1 的 ControllerRevision 對象保存的 Data 字段。而這個 Data 字段里保存的信息，就是 Revision=1 時這個 DaemonSet 的完整 API 對象。所以，現在 DaemonSet Controller 就可以使用這個歷史 API 對象，對現有的 DaemonSet 做一次 PATCH 操作(等價于執行一次 kubectl apply -f “舊的 DaemonSet 對象”)，從而把這個 DaemonSet“更新”到一個舊版本。這也是為什么，在執行完這次回滾完成后，你會發現，DaemonSet 的 Revision 并不會從 Revision=2 退回到 1，而是會增加成 Revision=3。這是因為，一個新的 ControllerRevision 被創建了出來。總結在今天這篇文章中，我首先簡單介紹了 StatefulSet 的“滾動更新”，然后重點講解了本專欄的第三個重要編排對象：DaemonSet。相比于 Deployment，DaemonSet 只管理 Pod 對象，然后通過 nodeAffinity 和 Toleration 這兩個調度器的小功能，保證了每個節點上有且只有一個 Pod。這個控制器的實現原理簡單易懂，希望你能夠快速掌握。與此同時，DaemonSet 使用 ControllerRevision，來保存和管理自己對應的“版本”。這種“面向 API 對象”的設計思路，大大簡化了控制器本身的邏輯，也正是 Kubernetes 項目“聲明式 API”的優勢所在。而且，相信聰明的你此時已經想到了，StatefulSet 也是直接控制 Pod 對象的，那么它是不是也在使用 ControllerRevision 進行版本管理呢？沒錯。在 Kubernetes 項目里，ControllerRevision 其實是一個通用的版本管理對象。這樣，Kubernetes 項目就巧妙地避免了每種控制器都要維護一套冗余的代碼和邏輯的問題。思考題我在文中提到，在 Kubernetes v1.11 之前，DaemonSet 所管理的 Pod 的調度過程，實際上都是由 DaemonSet Controller 自己而不是由調度器完成的。你能說出這其中有哪些原因嗎？

總結

以上是生活随笔為你收集整理的21丨容器化守护进程的意义：DaemonSet的全部內容，希望文章能夠幫你解決所遇到的問題。

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