網絡插件的 Agent 組件，都必須運行在每一個節(jié)點上，用來處理這個節(jié)點上的容器網絡。
存儲插件的 Agent 組件，也必須運行在每一個節(jié)點上，用來在這個節(jié)點上掛載遠程存儲目錄，操作容器的 Volume 目錄，比如：glusterd、ceph。
監(jiān)控組件和日志組件，也必須運行在每一個節(jié)點上，負責這個節(jié)點上的監(jiān)控信息和日志搜集，比如：fluentd、logstash、Prometheus 等。

DaemonSet 創(chuàng)建

k8s 環(huán)境搭建參考網上教程，這里就不再贅述了。

先來個簡單的例子快速體驗 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 不需要指定副本數，因為它的副本數取決于工作節(jié)點數。

DaemonSet 配置中 spec.selector 和 spec.template 作用我們已在介紹 Deployment 時介紹過，在此不再贅述。

該份配置將創(chuàng)建一個 DaemonSet 對象，然后 DaemonSet 控制器會根據該對象信息分別在每個節(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：需求副本個數，由于沒有刻意篩選節(jié)點，所以副本個數等同于節(jié)點個數(默認)；
CURRENT：當前已創(chuàng)建的副本個數；
READY：處于 Ready 狀態(tài)的副本個數；
UP-TO-DATE：已按最新 Pod 模版創(chuàng)建的 Pod 個數；
AVAILABLE：可用的副本個數；
NODE SELECTOR：節(jié)點選擇器，本例中我們沒有選擇，值為空；
AGE：創(chuà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

下面我們適當的調整下 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 參數如下：

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 副本數也變成了 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 自動加上另外一個與調度相關的字段，叫作 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 被調度上去的（effect: NoSchedule）。

可是，DaemonSet 自動地給被管理的 Pod 加上了這個特殊的 Toleration，就使得這些 Pod 可以忽略這個限制，繼而保證每個節(jié)點上都會被調度一個 Pod。

當然，如果這個節(jié)點有故障的話，這個 Pod 可能會啟動失敗，而 DaemonSet 則會始終嘗試下去，直到 Pod 啟動成功。

主要作用：

通過這樣一個 Toleration，調度器在調度這個 Pod 的時候，就會忽略當前節(jié)點上的“污點”，從而成功地將一些組件調度到這臺機器上啟動起來。

這種機制，正是我們在部署 Kubernetes 集群的時候，能夠先部署 Kubernetes 本身、再部署網絡插件的根本原因：因為當時我們所創(chuàng)建的 Weave 的 YAML，實際上就是一個 DaemonSet。

節(jié)點親和性 nodeAffinity 使用

正常情況下 DaemonSet Controller 會在創(chuàng)建 Pod 的時候，自動在這個 Pod 的 API 對象里，加上這樣一個 nodeAffinity 定義。

在這個 Pod 里，聲明了一個 spec.affinity 字段，然后定義了一個 nodeAffinity。其中，spec.affinity 字段，是 Pod 里跟調度相關的一個字段。

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

以上關鍵參數含義：

requiredDuringSchedulingIgnoredDuringExecution 這個代表 nodeAffinity 必須在每次調度的時候予以考慮，同時，這也意味著可以設置在某些情況下不考慮這個 nodeAffinity；
這個 Pod，將來只允許運行在“metadata.name”是“demo-node”的節(jié)點上。