系列目錄

DaemonSet確保集群中每個（部分）node運行一份pod副本，當node加入集群時創建pod，當node離開集群時回收pod。如果刪除DaemonSet，其創建的所有pod也被刪除，DaemonSet中的pod覆蓋整個集群。

當需要在集群內每個node運行同一個pod，使用DaemonSet是有價值的，以下是典型使用場景：

• 運行集群存儲守護進程，如glusterd、ceph。

• 運行集群日志收集守護進程，如fluentd、logstash。

• 運行節點監控守護進程，如Prometheus Node Exporter, collectd, Datadog agent, New Relic agent, or Ganglia gmond。

創建DaemonSet

以下是DaemonSet的示例spec文件，運行fluentd-elasticsearch image：

apiVersion: apps/v1 kind: DaemonSet metadata:name: fluentd-elasticsearchnamespace: kube-systemlabels:k8s-app: fluentd-logging spec: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中沒有restart policy字段，默認為Always。如果有的話，必需將值設置成Always，否則在創建時出出現不可用錯誤。

DaemonSet同樣會受到Taint的抵制，如果不在配置中加入匹配的Toleration，那么DaemonSet不會在擁有Taint屬性的node上部署pod。上例中有如下內容：

tolerations:- key: node-role.kubernetes.io/mastereffect: NoSchedule

原因就是系統默認為master節點增加了 “node-role.kubernetes.io/master”的Taint，以抵制普通pod部署，使master成為專用節點。因為我們預期上例DaemonSet在集群內全局部署，因此需要加入相匹配的Toleration。

如果預期DaemonSet只在特定節點上運行，可以在上述配置文件中加入.spec.template.spec.nodeSelector字段。.
spec.template.spec.nodeSelector字段內加入節點選擇器(node selector)或者親和選擇器(node affinity)，則DaemonSet只會在滿足條件的node上部署pod?？傊?#xff0c;可以通過Taint、Toleration、Affinity、node label控制DaemonSet部署pod的節點范圍。

將以上內容保存在daemonset.yaml文件中，執行如下命令創建DaemonSet：

kubectl create -f https://k8s.io/examples/controllers/daemonset.yaml

系統如何調度DaemonSet pod?

默認情況下DaemonSet在創建pod時，為其增加spec.nodeName字段，也就是說所創建的pod運行在那個節上在創建階段就已經確定，所以DaemonSet中的pod實際上沒有接受kubernetes scheduler的調度，它不需要調度，因此產生以下兩個特性：

• DaemonSet中的pod不遵從節點的unreachable條件，也就是即使節點被系統判定為不可達，DaemonSet仍然試圖在其上部署pod。

• 在集群引導階段，即使kubernetes scheduler還沒有部署生效，DaemonSet仍然可以將pod部署到集群中的任何節點，此特性主要是在集群引導階段使用。

因為DaemonSet不同于常規pod的調度特性，它帶來兩個問題：

• pod行為不一致。普通pod被創建以后等待調度的階段稱為pending，因為DaemonSet中的pod無需調度，因而無此狀態，用戶會因此產生迷惑。

• pod優先級特性由kubernetes scheduler實現，DaemonSet無此特性。當系統打開pod優先級功能時，pod優先級特性會被DaemonSet中的pod忽略。

為了解決以上兩個問題，kubernetes增加了通過設置允許DaemonSet使用kurbernetes scheduler的功能，并在1.11的 alpha版本中成為穩定特性。其實現機制是DaemonSet在創建pod時，不再自動添加.spec.nodeName，而是以nodeAffinity取而代之，示例如下：

nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchFields:- key: metadata.nameoperator: Invalues:- target-host-name

其中"target-host-name"就是原來.spec.nodeName的值，這樣pod就會被kubernetes scheduler調度。通過以上操作解決了上述兩個問題。但DaemonSet的調度有自己因有的特性，在上文中提到的“不受節點unreachable條件限制”，為了使DaemonSet在使用kubernetes scheduler時仍然保持此特性需要打開集群的"TaintNodesByCondition"特性，如果DaemonSet使用主機網絡那么必需在DaemonSet中添加如下的Toleration：

node.kubernetes.io/network-unavailable:NoSchedule

DaemonSet自動添加的Toleration

系統在某此條件下會自動為節點添加Taint，比如硬盤不足、網絡不可達等，以阻止新pod往不滿足條件的節點上調度。但DaemonSet的目的是在全部有資格的node上部署，不希望被這種Taint打斷，因經系統也默認為DaemonSet上的pod添加Toleration。如下表：

Toleration KeyEffectAlpha FeaturesVersionDescription

node.kubernetes.io/not-ready	NoExecute	TaintBasedEvictions	1.8+	when TaintBasedEvictions is enabled,they will not be evicted when there are node problems such as a network partition.
node.kubernetes.io/unreachable	NoExecute	TaintBasedEvictions	1.8+	when TaintBasedEvictions is enabled,they will not be evicted when there are node problems such as a network partition.
node.kubernetes.io/disk-pressure	NoSchedule	TaintNodesByCondition	1.8+
node.kubernetes.io/memory-pressure	NoSchedule	TaintNodesByCondition	1.8+
node.kubernetes.io/unschedulable	NoSchedule	ScheduleDaemonSetPods, TaintNodesByCondition	1.11+	When ScheduleDaemonSetPodsis enabled, TaintNodesByConditionis necessary to make sure DaemonSet pods tolerate unschedulable attributes by default scheduler.
node.kubernetes.io/network-unavailable	NoSchedule	ScheduleDaemonSetPods, TaintNodesByCondition, hostnework	1.11+	When ScheduleDaemonSetPodsis enabled, TaintNodesByConditionis necessary to make sure DaemonSet pods, who uses host network, tolerate network-unavailable attributes by default scheduler.
node.kubernetes.io/out-of-disk	NoSchedule	ExperimentalCriticalPodAnnotation(critical pod only), TaintNodesByCondition	1.8+

與DaemonSet中pod通信的幾種模式

• Push：收集數據并向其它服務發送，如將收集到的統計信息發送給統計類型數據庫。

• NodeIP and Known Port：DaemonSet中的pod可以被設置使用主機網絡的一個port，而客戶端可以很方便的知道節點IP列表，因此可以通過節點IP地址與port訪問DaemonSet pod。

• DNS：創建無頭服務并且讓它的選擇器匹配所有DaemonSet的pod，這樣DaemonSet中的pod就會成為無頭服務的endpoints。類似于StatefulSet。

• Service：讓Service選中DaemonSet，為訪問DaemonSet中的pod提供統一入口與負載均衡。

轉載于:https://www.cnblogs.com/tylerzhou/p/11007427.html

總結

以上是生活随笔為你收集整理的Kuebernetes之DaemonSet的全部內容，希望文章能夠幫你解決所遇到的問題。

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