Day 10：DaemonSet vs. Static Pods

昨天我們談到了Taints and Tolerations與Node Affinity，前者為限制Pod不能放在哪些Node，而後者為Pod喜歡去哪些Node，但不一定會選擇這些Node。

今天我們談到的DaemonSet與Static Pods，會比較像是決定我們要把Pod部署到哪些Node，那接下來我先談DaemonSet的部分。

DaemonSet

如果我們想要部署Pods到所有的Node上運行，我們必須先知道有多少個Nodes，然後在Deployment上設定相同數量的replicas，又為了避免有多個Pods被部署到相同的Node上，必須使用反親和性(anti-affinity)。現在我們只要用了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在Control Plane Node上運行
      # 如果不希望Control Plane Node上運行Pod，可以刪除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:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log

• name：DaemonSet的名稱必須為合法的DNS子域名。
• resource：就是這個Container被分配到的資源，未來有機會會再詳談。
• volumes：可以想像這是我們幫這個Pod插上的外接硬碟，這會在未來詳細介紹。
• terminationGracePeriodSeconds：系統要將Pod刪除前，給這個Pod保留時間來完成最後的步驟(留遺言(X))。
• namespace：就是一種將系統Object互相隔離的機制，但不是每個Object都會受到此限制，明天我們來詳談。

DaemonSet可以當作是部署到各個Node上的Agent，上面的YAML中的DaemonSet的作用呢，就是在各個Node上搜集Log。

如果我們不想部署到全部的Nodes呢？

在上面的YAML我們可以得知，如果是不想部署到Master Node，那我們只要刪除Tolerations就好了。同理，如果不想部署到某個Worker Node，我們只要在這個Worker Node上加入Taints，又或著是先在這些Worker Nodes上貼上某些Labels，只要使用NodeAffinity或是NodeSelector，這樣就可以完成了～

Static Pods

這是一種由kubelet所控管的Pod，它不會受到Control Plane所管理。舉例來說，今天我們想要透過API-Server來刪除這個Pod，會發現刪除後它依然存在。因此它的YAML中也無法引用其他API Object，像是ServiceAccount、ConfigMap、Secret。

kubelet會在各個Node中，不斷地監控”/etc/kubernetes/manifests”這個路徑，我們如果在這邊放入一個Pod的YAML檔，那kubelet就會創建這個Pod。如果刪除這個YAML檔，那個Pod就會被就會被刪除。

# 在 kubelet 運行的節點上執行以下指令
mkdir -p /etc/kubernetes/manifests/
cat <<EOF >/etc/kubernetes/manifests/static-web.yaml
apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    role: myrole
spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
EOF

• mkdir -p：mkdir -p /etc/kubernetes/manifests/：建構資料夾，如果路徑上有不存在的資料夾，就連路徑上的資料夾一起建構。
• cat </etc/kubernetes/manifests/static-web.yaml：到EOF之前的文件會被寫入etc/kubernetes/manifests/static-web.yaml這個檔案中。

如何更新Static Pods？

我們前面提到過Pod是無法更新的，必須先刪除舊的Pod，再重建新版本的Pod。同理，Static Pods也是一樣，必須先刪除YAML，待Static Pods被刪除後，再放入新版本的YAML。

如何在系統上辨識Static Pods？

Static Pods的名稱後面都會加上Node Name。
假設我們今天在node1上建立上面的Static Pods，那它在系統上顯示的名稱就會是：static-web-node1

Static Pods vs. Taints

因為Static Pods是受到kubelet所控管，所以Taints也無法阻止它的腳步～

參考資料

[K8S] 如何利用terminationGracePeriodSeconds 优雅地关闭你的服务？

DaemonSet

創建靜態Pod

Best practices for upgrading static pod in kubernetes