理解k8s控制器DaemonSet創(chuàng)建及使用場景
DaemonSet 簡介
DaemonSet 的主要作用,是在 Kubernetes 集群里,運(yùn)行一個(gè) Daemon Pod。 DaemonSet 只管理 Pod 對象,然后通過 nodeAffinity 和 Toleration 這兩個(gè)調(diào)度器參數(shù)的功能,保證了每個(gè)節(jié)點(diǎn)上有且只有一個(gè) Pod。
DaemonSet 是一種面向特定應(yīng)用場景的 Pod 控制器,盡管它也可以管理 Pod 的多個(gè)副本,但它主要用于保證一個(gè) Node 上只運(yùn)行一個(gè) Pod 的場景:
DaemonSet 使用場景
每個(gè)節(jié)點(diǎn)上只有一個(gè)這樣的 Daemon Pod 實(shí)例,然后當(dāng)有新的節(jié)點(diǎn)加入 Kubernetes 集群后,該 Pod 會自動(dòng)地在新節(jié)點(diǎn)上被創(chuàng)建出來。當(dāng)舊節(jié)點(diǎn)被刪除后,它上面的 Pod 也會相應(yīng)地被回收掉。
Daemon Pod 的意義確實(shí)是非常重要的。比如的作用:
- 網(wǎng)絡(luò)插件的 Agent 組件,都必須運(yùn)行在每一個(gè)節(jié)點(diǎn)上,用來處理這個(gè)節(jié)點(diǎn)上的容器網(wǎng)絡(luò)。
- 存儲插件的 Agent 組件,也必須運(yùn)行在每一個(gè)節(jié)點(diǎn)上,用來在這個(gè)節(jié)點(diǎn)上掛載遠(yuǎn)程存儲目錄,操作容器的 Volume 目錄,比如:glusterd、ceph。
- 監(jiān)控組件和日志組件,也必須運(yùn)行在每一個(gè)節(jié)點(diǎn)上,負(fù)責(zé)這個(gè)節(jié)點(diǎn)上的監(jiān)控信息和日志搜集,比如:fluentd、logstash、Prometheus 等。
DaemonSet 創(chuàng)建
k8s 環(huán)境搭建參考網(wǎng)上教程,這里就不再贅述了。
先來個(gè)簡單的例子快速體驗(yàn) DaemonSet 控制器是如何應(yīng)用的。
一個(gè)簡單的 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 基本類似,唯一一個(gè)顯著的差異是 DaemonSet 不需要指定副本數(shù),因?yàn)樗母北緮?shù)取決于工作節(jié)點(diǎn)數(shù)。
DaemonSet 配置中 spec.selector 和 spec.template 作用我們已在介紹 Deployment 時(shí)介紹過,在此不再贅述。
該份配置將創(chuàng)建一個(gè) DaemonSet 對象,然后 DaemonSet 控制器會根據(jù)該對象信息分別在每個(gè)節(jié)點(diǎn)上創(chuàng)建一個(gè) 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:需求副本個(gè)數(shù),由于沒有刻意篩選節(jié)點(diǎn),所以副本個(gè)數(shù)等同于節(jié)點(diǎn)個(gè)數(shù)(默認(rèn));
- CURRENT:當(dāng)前已創(chuàng)建的副本個(gè)數(shù);
- READY:處于 Ready 狀態(tài)的副本個(gè)數(shù);
- UP-TO-DATE:已按最新 Pod 模版創(chuàng)建的 Pod 個(gè)數(shù);
- AVAILABLE:可用的副本個(gè)數(shù);
- NODE SELECTOR:節(jié)點(diǎn)選擇器,本例中我們沒有選擇,值為空;
- AGE:創(chuàng)建至今經(jīng)歷的時(shí)間。
上面的字段中,除了 NODE SELECTOR 以外,我們已在前面的章節(jié)中介紹過。其實(shí) Node Selector 并不是 DaemonSet 對象特有的配置,它是 Pod 模版中用于為 Pod 匹配節(jié)點(diǎn)的配置,DaemonSet 控制器使用該 Node Selector 來篩選需要?jiǎng)?chuàng)建副本的節(jié)點(diǎn),如果沒有指定,則默認(rèn)選擇全部節(jié)點(diǎn)。
接著,查看 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>
可以看到,在每個(gè)節(jié)點(diǎn)上均創(chuàng)建了一個(gè)副本,是符合預(yù)期的。
更新 DaemonSet
下面我們適當(dāng)?shù)恼{(diào)整下 Pod 部署策略,只希望 Pod 運(yùn)行在名為 k8s-node 的節(jié)點(diǎn)上,這樣我們只需要配置 DaemonSet 對象的 spec.template.spec.nodeSelector 來選擇節(jié)點(diǎn)即可。
在 k8s-node 的節(jié)點(diǎn)中存在一個(gè)標(biāo)識節(jié)點(diǎn)的 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 個(gè),符合預(yù)期。
原來運(yùn)行的 3 個(gè) Pod 副本減少到 1 個(gè),而且只在我們配置選定的節(jié)點(diǎn)(k8s-node1)上運(yùn)行。
刪除 DaemonSet
像其他 Pod 控制器一樣,當(dāng)刪除 DaemonSet 對象時(shí),其所管理的 Pod 默認(rèn)也會被刪除,操作如下所示:
[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 還會給這個(gè) Pod 自動(dòng)加上另外一個(gè)與調(diào)度相關(guān)的字段,叫作 tolerations。這個(gè)字段意味著這個(gè) Pod,會“容忍”(Toleration)某些 Node 的“污點(diǎn)”(Taint)。
Toleration 使用 yaml 配置如下:
apiVersion: v1 kind: Pod metadata: name: with-toleration spec: tolerations: - key: node.kubernetes.io/unschedulable operator: Exists effect: NoSchedule
在正常情況下,被標(biāo)記了 unschedulable“污點(diǎn)”的 Node,是不會有任何 Pod 被調(diào)度上去的(effect: NoSchedule)。
可是,DaemonSet 自動(dòng)地給被管理的 Pod 加上了這個(gè)特殊的 Toleration,就使得這些 Pod 可以忽略這個(gè)限制,繼而保證每個(gè)節(jié)點(diǎn)上都會被調(diào)度一個(gè) Pod。
當(dāng)然,如果這個(gè)節(jié)點(diǎn)有故障的話,這個(gè) Pod 可能會啟動(dòng)失敗,而 DaemonSet 則會始終嘗試下去,直到 Pod 啟動(dòng)成功。
主要作用:
通過這樣一個(gè) Toleration,調(diào)度器在調(diào)度這個(gè) Pod 的時(shí)候,就會忽略當(dāng)前節(jié)點(diǎn)上的“污點(diǎn)”,從而成功地將一些組件調(diào)度到這臺機(jī)器上啟動(dòng)起來。
這種機(jī)制,正是我們在部署 Kubernetes 集群的時(shí)候,能夠先部署 Kubernetes 本身、再部署網(wǎng)絡(luò)插件的根本原因:因?yàn)楫?dāng)時(shí)我們所創(chuàng)建的 Weave 的 YAML,實(shí)際上就是一個(gè) DaemonSet。
節(jié)點(diǎn)親和性 nodeAffinity 使用
正常情況下 DaemonSet Controller 會在創(chuàng)建 Pod 的時(shí)候,自動(dòng)在這個(gè) Pod 的 API 對象里,加上這樣一個(gè) nodeAffinity 定義。
在這個(gè) Pod 里,聲明了一個(gè) spec.affinity 字段,然后定義了一個(gè) nodeAffinity。其中,spec.affinity 字段,是 Pod 里跟調(diào)度相關(guān)的一個(gè)字段。
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
以上關(guān)鍵參數(shù)含義:
- requiredDuringSchedulingIgnoredDuringExecution 這個(gè)代表 nodeAffinity 必須在每次調(diào)度的時(shí)候予以考慮,同時(shí),這也意味著可以設(shè)置在某些情況下不考慮這個(gè) nodeAffinity;
- 這個(gè) Pod,將來只允許運(yùn)行在“metadata.name”是“demo-node”的節(jié)點(diǎn)上。
總結(jié)
DaemonSet 其實(shí)就是依靠 nodeAffinity 和 Toleration 實(shí)現(xiàn)的。這是一種不需要增加設(shè)計(jì)結(jié)構(gòu),而直接使用標(biāo)簽等方式完成的 Daemon 進(jìn)程。這樣的結(jié)構(gòu)非常符合 Kubernetes 的控制器模式,正所謂一切皆對象。
以上就是k8s控制器DaemonSet理解的詳細(xì)內(nèi)容,更多關(guān)于k8s控制器DaemonSet的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
在AWS-EC2中安裝Minikube集群的詳細(xì)過程
這篇文章主要介紹了在AWS-EC2中安裝Minikube集群,本文通過圖文并茂的形式給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2022-06-06Kubernetes中創(chuàng)建命名空間實(shí)現(xiàn)方法
這篇文章主要為大家介紹了Kubernetes中創(chuàng)建命名空間實(shí)現(xiàn)方法詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-11-11Google?Kubernetes?Engine?集群實(shí)戰(zhàn)詳解
這篇文章主要為大家介紹了Google?Kubernetes?Engine?集群實(shí)戰(zhàn)詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-08-08Kubernetes中使用PersistentVolume掛載云盤方式
這篇文章主要介紹了Kubernetes中使用PersistentVolume掛載云盤方式,具有很好的參考價(jià)值,希望對大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2024-02-02k8s入門實(shí)戰(zhàn)deployment使用詳解
這篇文章主要為大家介紹了k8s入門實(shí)戰(zhàn)deployment使用詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-03-03Hadoop 2.x與3.x 22點(diǎn)比較,Hadoop 3.x比2.x的改進(jìn)
本文介紹了Hadoop3版本中添加的新功能,Hadoop 2和Hadoop 3的區(qū)別,在這篇文章中,我們將討論Hadoop 2.x與Hadoop 3.x之間的比較。感興趣的朋友跟隨小編一起看一下2018-09-09kubernetes之statefulset搭建MySQL集群
這篇文章主要為大家介紹了kubernetes之statefulset搭建MySQL集群示例詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-04-04Rainbond云原生快捷部署生產(chǎn)可用的Gitlab步驟詳解
這篇文章主要為大家介紹了Rainbond云原生快捷部署生產(chǎn)可用的Gitlab步驟詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-04-04