目錄
- DaemonSet 簡介
- DaemonSet 使用場景
- DaemonSet 創(chuàng)建
- 查看 DaemonSet
- 更新 DaemonSet
- 刪除 DaemonSet
- 其它使用場景
- 容忍性 Toleration 使用
- 節(jié)點親和性 nodeAffinity 使用
- 總結(jié)
DaemonSet 簡介
DaemonSet 的主要作用，是在 Kubernetes 集群里，運行一個 Daemon Pod。 DaemonSet 只管理 Pod 對象，然后通過 nodeAffinity 和 Toleration 這兩個調(diào)度器參數(shù)的功能，保證了每個節(jié)點上有且只有一個 Pod。
DaemonSet 是一種面向特定應用場景的 Pod 控制器，盡管它也可以管理 Pod 的多個副本，但它主要用于保證一個 Node 上只運行一個 Pod 的場景：
DaemonSet 使用場景
每個節(jié)點上只有一個這樣的 Daemon Pod 實例，然后當有新的節(jié)點加入 Kubernetes 集群后，該 Pod 會自動地在新節(jié)點上被創(chuàng)建出來。當舊節(jié)點被刪除后，它上面的 Pod 也會相應地被回收掉。
Daemon Pod 的意義確實是非常重要的。比如的作用：
- 網(wǎng)絡插件的 Agent 組件，都必須運行在每一個節(jié)點上，用來處理這個節(jié)點上的容器網(wǎng)絡。
- 存儲插件的 Agent 組件，也必須運行在每一個節(jié)點上，用來在這個節(jié)點上掛載遠程存儲目錄，操作容器的 Volume 目錄，比如：glusterd、ceph。
- 監(jiān)控組件和日志組件，也必須運行在每一個節(jié)點上，負責這個節(jié)點上的監(jiān)控信息和日志搜集，比如：fluentd、logstash、Prometheus 等。
DaemonSet 創(chuàng)建
k8s 環(huán)境搭建參考網(wǎng)上教程，這里就不再贅述了。
先來個簡單的例子快速體驗 DaemonSet 控制器是如何應用的。
一個簡單的 DaemonSet 配置如下：
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: nginx-daemonset
labels:
app: nginx
spec:
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.17.0
初步看，這份配置跟 Deployment 基本類似，唯一一個顯著的差異是 DaemonSet 不需要指定副本數(shù)，因為它的副本數(shù)取決于工作節(jié)點數(shù)。
DaemonSet 配置中 spec.selector 和 spec.template 作用我們已在介紹 Deployment 時介紹過，在此不再贅述。
該份配置將創(chuàng)建一個 DaemonSet 對象，然后 DaemonSet 控制器會根據(jù)該對象信息分別在每個節(jié)點上創(chuàng)建一個 Pod 副本。
接下來使用kubectl create命令將該配置提次給 kube-apiserver，如下所示：
[root@k8s-master]# kubectl create -f daemonset.yaml daemonset.apps/nginx-daemonset created
查看 DaemonSet
首先查看剛剛創(chuàng)建的 DaemonSet 對象：
[root@k8s-master]# kubectl get daemonset NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE nginx-daemonset 3 3 3 3 3 <none> 1m3s
命令行輸出中各字段含義如下：
- NAME: DaemonSet 對象名稱，同配置中的 metadata.name；
- DESIRED：需求副本個數(shù)，由于沒有刻意篩選節(jié)點，所以副本個數(shù)等同于節(jié)點個數(shù)(默認)；
- CURRENT：當前已創(chuàng)建的副本個數(shù)；
- READY：處于 Ready 狀態(tài)的副本個數(shù)；
- UP-TO-DATE：已按最新 Pod 模版創(chuàng)建的 Pod 個數(shù)；
- AVAILABLE：可用的副本個數(shù)；
- NODE SELECTOR：節(jié)點選擇器，本例中我們沒有選擇，值為空；
- AGE：創(chuàng)建至今經(jīng)歷的時間。
上面的字段中，除了 NODE SELECTOR 以外，我們已在前面的章節(jié)中介紹過。其實 Node Selector 并不是 DaemonSet 對象特有的配置，它是 Pod 模版中用于為 Pod 匹配節(jié)點的配置，DaemonSet 控制器使用該 Node Selector 來篩選需要創(chuàng)建副本的節(jié)點，如果沒有指定，則默認選擇全部節(jié)點。
接著，查看 DaemonSet 控制器所創(chuàng)建的 Pod 副本信息：
[root@k8s-master]# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-daemonset-66dbc 1/1 Running 0 5m13s 10.135.3.2 k8s-master <none> <none> nginx-daemonset-akpdg 1/1 Running 0 5m13s 10.135.1.2 k8s-node1 <none> <none> nginx-daemonset-l3wnd 1/1 Running 0 5m13s 10.135.2.2 k8s-node2 <none> <none>
可以看到，在每個節(jié)點上均創(chuàng)建了一個副本，是符合預期的。
更新 DaemonSet
下面我們適當?shù)恼{(diào)整下 Pod 部署策略，只希望 Pod 運行在名為 k8s-node 的節(jié)點上，這樣我們只需要配置 DaemonSet 對象的 spec.template.spec.nodeSelector 來選擇節(jié)點即可。
在 k8s-node 的節(jié)點中存在一個標識節(jié)點的 label：
kubernetes.io/hostname: k8s-node1
使用 kubectl edit 命令修改配置的 spec.template.spec.nodeSelector 參數(shù)如下：
apiVersion: apps/v1
kind: DaemonSet
metadata:
...
spec:
...
template:
...
spec:
...
nodeSelector:
kubernetes.io/hostname: k8s-node1
然后再次觀察 DaemonSet 對象和 Pod 副本：
[root@k8s-master]# kubectl get daemonsets NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE nginx-daemonset 1 1 1 1 1 kubernetes.io/hostname=k8s-node1 37m [root@k8s-master]# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-daemonset-66gk2 1/1 Running 0 10s 10.135.2.3 k8s-node1 <none> <none>
可以發(fā)現(xiàn) DaemonSet 狀態(tài)中，NODE SELECTOR 正確地展示了上面的修改，而且需求的 Pod 副本數(shù)也變成了 1 個，符合預期。
原來運行的 3 個 Pod 副本減少到 1 個，而且只在我們配置選定的節(jié)點（k8s-node1）上運行。
刪除 DaemonSet
像其他 Pod 控制器一樣，當刪除 DaemonSet 對象時，其所管理的 Pod 默認也會被刪除，操作如下所示：
[root@k8s-master ~]# kubectl delete daemonsets nginx-daemonset daemonset.apps "nginx-daemonset" deleted [root@k8s-master ~]# kubectl get pods No resources found in default namespace.
其它使用場景
容忍性 Toleration 使用
DaemonSet 還會給這個 Pod 自動加上另外一個與調(diào)度相關的字段，叫作 tolerations。這個字段意味著這個 Pod，會“容忍”（Toleration）某些 Node 的“污點”（Taint）。
Toleration 使用 yaml 配置如下：
apiVersion: v1
kind: Pod
metadata:
name: with-toleration
spec:
tolerations:
- key: node.kubernetes.io/unschedulable
operator: Exists
effect: NoSchedule
在正常情況下，被標記了 unschedulable“污點”的 Node，是不會有任何 Pod 被調(diào)度上去的（effect: NoSchedule）。
可是，DaemonSet 自動地給被管理的 Pod 加上了這個特殊的 Toleration，就使得這些 Pod 可以忽略這個限制，繼而保證每個節(jié)點上都會被調(diào)度一個 Pod。
當然，如果這個節(jié)點有故障的話，這個 Pod 可能會啟動失敗，而 DaemonSet 則會始終嘗試下去，直到 Pod 啟動成功。
主要作用：
通過這樣一個 Toleration，調(diào)度器在調(diào)度這個 Pod 的時候，就會忽略當前節(jié)點上的“污點”，從而成功地將一些組件調(diào)度到這臺機器上啟動起來。
這種機制，正是我們在部署 Kubernetes 集群的時候，能夠先部署 Kubernetes 本身、再部署網(wǎng)絡插件的根本原因：因為當時我們所創(chuàng)建的 Weave 的 YAML，實際上就是一個 DaemonSet。
節(jié)點親和性 nodeAffinity 使用
正常情況下 DaemonSet Controller 會在創(chuàng)建 Pod 的時候，自動在這個 Pod 的 API 對象里，加上這樣一個 nodeAffinity 定義。
在這個 Pod 里，聲明了一個 spec.affinity 字段，然后定義了一個 nodeAffinity。其中，spec.affinity 字段，是 Pod 里跟調(diào)度相關的一個字段。
nodeAffinity 使用 yaml 配置如下：
apiVersion: v1
kind: Pod
metadata:
name: demo-node-affinity
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: metadata.name
operator: In
values:
- demo-node
以上關鍵參數(shù)含義：
- requiredDuringSchedulingIgnoredDuringExecution 這個代表 nodeAffinity 必須在每次調(diào)度的時候予以考慮，同時，這也意味著可以設置在某些情況下不考慮這個 nodeAffinity；
- 這個 Pod，將來只允許運行在“metadata.name”是“demo-node”的節(jié)點上。
總結(jié)
DaemonSet 其實就是依靠 nodeAffinity 和 Toleration 實現(xiàn)的。這是一種不需要增加設計結(jié)構(gòu)，而直接使用標簽等方式完成的 Daemon 進程。這樣的結(jié)構(gòu)非常符合 Kubernetes 的控制器模式，正所謂一切皆對象。
以上就是k8s控制器DaemonSet理解的詳細內(nèi)容，更多關于k8s控制器DaemonSet的資料請關注其它相關文章！
