接續昨天提及的，Daemon 是一個在背後運行的程式，而 DaemonSet 則是為了要實現當 Node 加入 cluster 後，會自動生成並部屬一個 Pod 在該 Node 中運行。

以下為創建 Daemonset 範例:

## daemonset.yaml
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:
      # 預設 Daemonset 不會將 Pod 部屬到 control panel 上，透過 `tolerations` 可以避免此限制
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        resources: # 定義 Pod 的資源限制
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log

可以發現在上面範例中，並沒有像 Deployment 或 Replicaset 中的 replicas 參數，因為在 Daemonset 中，固定每一個 Node 都只有一個 Daemonset 中所指定的 Pod，這也是 Daemonset 的應用，捲凡像是 logs collection 或 monitoring 等，通常需要在每一個 Node 運行一個應用程式。
舉個貼近的例子，如果想要監測某臺 Machine (不論實體或虛擬機器)的資源，如CPU使用率、Network bandwidth...等，通常會使用到 Prometheus Node exporter，將它運行在每一個 Node 上，定時汲取 Node 的資源使用情形。
其中，也可以在spec中指定 nodeselector，以選擇要全部或是部分 Node 遵守此設定，這邊會談論到該如何指定 Pod 要 run 在哪一個 Node 上的，之後來將這邊的概念補齊。

最後，Daemonset 也支持 Rolling Update，共有兩種更新策略:

• onDelete: 在更新 Daemonset 後，需手動刪除舊的Daemonset Pod，才會建立新的 Daemonset Pod。

• RollingUpdate: 預設更新策略，在更新 Daemonset 後，會自動刪除原先舊的 Daemonset Pod，漸進式更新，與此同時，一個 Node 上仍舊只會有一個 Daemonset 所指定的 Pod。

今天先這樣

Be confident with yourself and stop worrying what other people think. Do what's best for your future happiness!
共勉之