1.簡介
DaemonSet 確保全部（或者某些）節(jié)點上運行一個 Pod 的副本秉沼。 當有節(jié)點加入集群時芯勘， 也會為他們新增一個 Pod 撩银。 當有節(jié)點從集群移除時刑枝，這些 Pod 也會被回收橙垢。刪除 DaemonSet 將會刪除它創(chuàng)建的所有 Pod垛叨。
DaemonSet 的一些典型用法：
- 在每個節(jié)點上運行集群守護進程
- 在每個節(jié)點上運行日志收集守護進程
- 在每個節(jié)點上運行監(jiān)控守護進程
一種簡單的用法是為每種類型的守護進程在所有的節(jié)點上都啟動一個 DaemonSet。 一個稍微復雜的用法是為同一種守護進程部署多個 DaemonSet柜某；每個具有不同的標志嗽元， 并且對不同硬件類型具有不同的內(nèi)存、CPU 要求喂击。
2. 創(chuàng)建 DaemonSet
你可以在 YAML 文件中描述 DaemonSet剂癌。 例如，下面的 daemonset.yaml 文件描述了一個運行 fluentd-elasticsearch Docker 鏡像的 DaemonSet：
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
namespace: kube-system
labels:
k8s-app: fluentd-logging
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
tolerations:
# this toleration is to have the daemonset runnable on master nodes
# remove it if your masters can't run pods
- key: node-role.kubernetes.io/master
effect: NoSchedule
containers:
- name: fluentd-elasticsearch
image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
基于 YAML 文件創(chuàng)建 DaemonSet：
kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
示例：pandas 是基于NumPy 的一種工具翰绊，該工具是為了解決數(shù)據(jù)分析任務(wù)而創(chuàng)建的佩谷。
3.配置說明
3.1 必需字段
- DaemonSet 需要 apiVersion、kind 和 metadata 字段
- DaemonSet 對象的名稱必須是一個合法的 DNS 子域名
- DaemonSet 也需要一個 .spec 配置段
3.2 Pod 模板
.spec 中唯一必需的字段是 .spec.template 监嗜。
.spec.template 是一個 Pod 模板谐檀。 除了它是嵌套的，因而不具有 apiVersion 或 kind 字段之外裁奇，它與 Pod 具有相同的 schema桐猬。
除了 Pod 必需字段外，在 DaemonSet 中的 Pod 模板必須指定合理的標簽（查看 Pod 選擇算符）刽肠。
在 DaemonSet 中的 Pod 模板必須具有一個值為 Always 的 RestartPolicy溃肪。 當該值未指定時，默認是 Always音五。
3.3Pod 選擇算符
.spec.selector 字段表示 Pod 選擇算符乍惊，它與 Job 的 .spec.selector 的作用是相同的。
從 Kubernetes 1.8 開始放仗，您必須指定與 .spec.template 的標簽匹配的 Pod 選擇算符润绎。 用戶不指定 Pod 選擇算符時，該字段不再有默認值。 選擇算符的默認值生成結(jié)果與 kubectl apply 不兼容莉撇。 此外呢蛤，一旦創(chuàng)建了 DaemonSet，它的 .spec.selector 就不能修改棍郎。 修改 Pod 選擇算符可能導致 Pod 意外懸浮其障，并且這對用戶來說是費解的。
spec.selector 是一個對象涂佃，如下兩個字段組成：
matchLabels - 與 ReplicationController 的 .spec.selector 的作用相同励翼。
matchExpressions - 允許構(gòu)建更加復雜的選擇器，可以通過指定 key辜荠、value 列表以及將 key 和 value列表關(guān)聯(lián)起來的 operator汽抚。
當上述兩個字段都指定時，結(jié)果會按邏輯與（AND）操作處理伯病。
如果指定了 .spec.selector造烁，必須與 .spec.template.metadata.labels 相匹配。 如果與后者不匹配午笛，則 DeamonSet 會被 API 拒絕惭蟋。
3.4 僅在某些節(jié)點上運行 Pod
如果指定了 .spec.template.spec.nodeSelector，DaemonSet 控制器將在能夠與 Node 選擇算符 匹配的節(jié)點上創(chuàng)建 Pod药磺。 類似這種情況告组，可以指定 .spec.template.spec.affinity，之后 DaemonSet 控制器 將在能夠與節(jié)點親和性 匹配的節(jié)點上創(chuàng)建 Pod癌佩。 如果根本就沒有指定木缝，則 DaemonSet Controller 將在所有節(jié)點上創(chuàng)建 Pod。
4. Daemon Pods 是如何被調(diào)度的
4.1 通過默認調(diào)度器調(diào)度
DaemonSet 確保所有符合條件的節(jié)點都運行該 Pod 的一個副本驼卖。 通常氨肌，運行 Pod 的節(jié)點由 Kubernetes 調(diào)度器選擇鸿秆。 不過酌畜，DaemonSet Pods 由 DaemonSet 控制器創(chuàng)建和調(diào)度。這就帶來了以下問題：
- Pod 行為的不一致性：正常 Pod 在被創(chuàng)建后等待調(diào)度時處于 Pending 狀態(tài)卿叽， DaemonSet Pods 創(chuàng)建后不會處于Pending 狀態(tài)下桥胞。這使用戶感到困惑。
- Pod 搶占 由默認調(diào)度器處理考婴。啟用搶占后贩虾，DaemonSet 控制器將在不考慮 Pod 優(yōu)先級和搶占 的情況下制定調(diào)度決策。
ScheduleDaemonSetPods 允許您使用默認調(diào)度器而不是 DaemonSet 控制器來調(diào)度 DaemonSets沥阱， 方法是將 NodeAffinity 條件而不是 .spec.nodeName 條件添加到 DaemonSet Pods缎罢。 默認調(diào)度器接下來將 Pod 綁定到目標主機。 如果 DaemonSet Pod 的節(jié)點親和性配置已存在，則被替換策精。 DaemonSet 控制器僅在創(chuàng)建或修改 DaemonSet Pod 時執(zhí)行這些操作舰始， 并且不會更改 DaemonSet 的 spec.template。
此外咽袜，系統(tǒng)會自動添加 node.kubernetes.io/unschedulable：NoSchedule 容忍度到 DaemonSet Pods丸卷。在調(diào)度 DaemonSet Pod 時，默認調(diào)度器會忽略 unschedulable 節(jié)點询刹。
4.2污點和容忍度
| node.kubernetes.io/not-ready | NoExecute | 1.13+ | 當出現(xiàn)類似網(wǎng)絡(luò)斷開的情況導致節(jié)點問題時谜嫉，DaemonSet Pod 不會被逐出。 |
|---|---|---|---|
| node.kubernetes.io/unreachable | NoExecute | 1.13+ | 當出現(xiàn)類似于網(wǎng)絡(luò)斷開的情況導致節(jié)點問題時凹联，DaemonSet Pod 不會被逐出沐兰。 |
| node.kubernetes.io/disk-pressure | NoExecute | 1.8+ | |
| node.kubernetes.io/memory-pressure | NoExecute | 1.8+ | |
| node.kubernetes.io/unschedulable | NoExecute | 1.12+ | DaemonSet Pod 能夠容忍默認調(diào)度器所設(shè)置的 unschedulable 屬性. |
| node.kubernetes.io/network-unavailable | NoExecute | 1.12+ | DaemonSet 在使用宿主網(wǎng)絡(luò)時，能夠容忍默認調(diào)度器所設(shè)置的 network-unavailable 屬性匕垫。 |
5.Daemon Pods 通信
與 DaemonSet 中的 Pod 進行通信的幾種可能模式如下：
- 推送（Push）：配置 DaemonSet 中的 Pod僧鲁，將更新發(fā)送到另一個服務(wù)，例如統(tǒng)計數(shù)據(jù)庫象泵。 這些服務(wù)沒有客戶端寞秃。
- NodeIP 和已知端口：DaemonSet 中的 Pod 可以使用 hostPort，從而可以通過節(jié)點 IP 訪問到Pod偶惠〈菏伲客戶端能通過某種方法獲取節(jié)點 IP 列表，并且基于此也可以獲取到相應(yīng)的端口忽孽。
- DNS：創(chuàng)建具有相同 Pod 選擇算符的 無頭服務(wù)绑改， 通過使用 endpoints 資源或從 DNS 中檢索到多個 A 記錄來發(fā)現(xiàn)DaemonSet。
- Service：創(chuàng)建具有相同 Pod 選擇算符的服務(wù)兄一，并使用該服務(wù)隨機訪問到某個節(jié)點上的 守護進程（沒有辦法訪問到特定節(jié)點）厘线。
6. DaemonSet更新
如果節(jié)點的標簽被修改，DaemonSet 將立刻向新匹配上的節(jié)點添加 Pod出革， 同時刪除不匹配的節(jié)點上的 Pod造壮。
你可以修改 DaemonSet 創(chuàng)建的 Pod。不過并非 Pod 的所有字段都可更新骂束。 下次當某節(jié)點（即使具有相同的名稱）被創(chuàng)建時耳璧，DaemonSet 控制器還會使用最初的模板。
您可以刪除一個 DaemonSet展箱。如果使用 kubectl 并指定 --cascade=false 選項旨枯， 則 Pod 將被保留在節(jié)點上。接下來如果創(chuàng)建使用相同選擇算符的新 DaemonSet混驰， 新的 DaemonSet 會收養(yǎng)已有的 Pod攀隔。 如果有 Pod 需要被替換皂贩，DaemonSet 會根據(jù)其 updateStrategy 來替換。
7. DaemonSet 滾動更新
Kubernetes 1.6 或者更高版本中才支持 DaemonSet 滾動更新功能
7.1 DaemonSet 更新策略
DaemonSet 有兩種更新策略：
- OnDelete: 使用 OnDelete 更新策略時昆汹，在更新 DaemonSet 模板后先紫，只有當你手動刪除老的 DaemonSet pods 之后，新的 DaemonSet Pod 才會被自動創(chuàng)建筹煮。跟 Kubernetes 1.6 以前的版本類似遮精。
- RollingUpdate: 這是默認的更新策略。使用 RollingUpdate 更新策略時败潦，在更新 DaemonSet 模板后本冲， 老的DaemonSet pods 將被終止，并且將以受控方式自動創(chuàng)建新的 DaemonSet pods劫扒。 更新期間檬洞，最多只能有DaemonSet 的一個 Pod 運行于每個節(jié)點上。
7.2 執(zhí)行滾動更新
啟用 DaemonSet 的滾動更新功能沟饥，必須設(shè)置 .spec.updateStrategy.type 為 RollingUpdate添怔。
你可能想設(shè)置 .spec.updateStrategy.rollingUpdate.maxUnavailable (默認為 1) 和 .spec.minReadySeconds (默認為 0)。
7.2.1 創(chuàng)建帶有 RollingUpdate 更新策略的 DaemonSet
下面的 YAML 包含一個 DaemonSet贤旷，其更新策略為 ‘RollingUpdate’：
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
namespace: kube-system
labels:
k8s-app: fluentd-logging
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
updateStrategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1 #滾動升級時允許的最大Unavailable的pod個數(shù)
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
tolerations:
# this toleration is to have the daemonset runnable on master nodes
# remove it if your masters can't run pods
- key: node-role.kubernetes.io/master
effect: NoSchedule
containers:
- name: fluentd-elasticsearch
image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
檢查了 DaemonSet 清單中更新策略的設(shè)置之后广料，創(chuàng)建 DaemonSet：
kubectl create -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml
另一種方式是如果你希望使用 kubectl apply 來更新 DaemonSet 的話，也可以 使用 kubectl apply 來創(chuàng)建 DaemonSet：
kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml
7.2.2 檢查 DaemonSet 的滾動更新策略
首先幼驶，檢查 DaemonSet 的更新策略艾杏，確保已經(jīng)將其設(shè)置為 RollingUpdate:
kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml
首先，檢查 DaemonSet 的更新策略盅藻，確保已經(jīng)將其設(shè)置為 RollingUpdate:
kubectl get ds/fluentd-elasticsearch -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}' -n kube-system
如果還沒在系統(tǒng)中創(chuàng)建 DaemonSet购桑，請使用以下命令檢查 DaemonSet 的清單：
kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml --dry-run=client -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}'
兩個命令的輸出都應(yīng)該為：
RollingUpdate
如果輸出不是 RollingUpdate，請返回并相應(yīng)地修改 DaemonSet 對象或者清單氏淑。
7.2.3 更新 DaemonSet 模板
對 <code>RollingUpdate DaemonSet</code> 的 <code> .spec.template</code> 的任何更新都將觸發(fā)滾動更新勃蜘。 這可以通過幾個不同的 kubectl 命令來完成。
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
namespace: kube-system
labels:
k8s-app: fluentd-logging
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
updateStrategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
tolerations:
# this toleration is to have the daemonset runnable on master nodes
# remove it if your masters can't run pods
- key: node-role.kubernetes.io/master
effect: NoSchedule
containers:
- name: fluentd-elasticsearch
image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
聲明式命令
如果你使用 配置文件 來更新 DaemonSet假残，請使用 kubectl apply:
kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset-update.yaml
指令式命令
如果你使用 指令式命令 來更新 DaemonSets缭贡，請使用kubectl edit：
kubectl edit ds/fluentd-elasticsearch -n kube-system
只更新容器鏡像
如果你只需要更新 DaemonSet 模板里的容器鏡像，比如守问，<code>.spec.template.spec.containers[*].image</code>, 請使用 kubectl set image:
kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=quay.io/fluentd_elasticsearch/fluentd:v2.6.0 -n kube-system
監(jiān)視滾動更新狀態(tài)
最后匀归，觀察 DaemonSet 最新滾動更新的進度：
kubectl rollout status ds/fluentd-elasticsearch -n kube-system
當滾動更新完成時坑资，輸出結(jié)果如下：
daemonset "fluentd-elasticsearch" successfully rolled out
8.DaemonSet 回滾
8.1 顯示DaemonSet 回滾到的歷史修訂版本（revision）
如果只想回滾到最后一個版本耗帕，可以跳過這一步。
$ kubectl rollout history daemonset <daemonset-name>
daemonsets "<daemonset-name>"
REVISION CHANGE-CAUSE
1 ...
2 ...
...
在創(chuàng)建時袱贮，DaemonSet 的變化原因從 <code>kubernetes.io/change-cause</code> 注解（annotation） 復制到其修訂版本中仿便。用戶可以在 kubectl 命令中設(shè)置<code> --record=true</code> ， 將執(zhí)行的命令記錄在變化原因注解中。
查看指定版本的詳細信息：
$ kubectl rollout history daemonset <daemonset-name> --revision=1
daemonsets "<daemonset-name>" with revision #1
Pod Template:
Labels: foo=bar
Containers:
app:
Image: ...
Port: ...
Environment: ...
Mounts: ...
Volumes: ...
8.2 回滾到指定版本
說明： 如果 <code> --record=true</code>參數(shù)未指定嗽仪，將選中最近的版本荒勇。
# 在 --to-revision 中指定你從步驟 1 中獲取的修訂版本
$ kubectl rollout undo daemonset <daemonset-name> --to-revision=<revision>
daemonset "<daemonset-name>" rolled back
8.3 監(jiān)視 DaemonSet 回滾進度
$ kubectl rollout status ds/<daemonset-name>
daemonset "<daemonset-name>" successfully rolled out
每個 ControllerRevision 中存儲了相應(yīng) DaemonSet 版本的注解和模板。
kubectl rollout undo 選擇特定的 ControllerRevision闻坚，并用 ControllerRevision 中存儲的模板代替 DaemonSet 的模板沽翔。 kubectl rollout undo 相當于通過其他命令（如 kubectl edit 或 kubectl apply） 將 DaemonSet 模板更新至先前的版本。
說明： 注意 DaemonSet 修訂版本只會正向變化窿凤。也就是說仅偎，回滾完成后，所回滾到的 ControllerRevision 版本號(.revision 字段) 會增加雳殊。 例如橘沥，如果用戶在系統(tǒng)中有版本 1 和版本 2，并從版本 2 回滾到版本 1夯秃， 帶有.revision: 1 的ControllerRevision 將變?yōu)?.revision: 3座咆。
