.深入k8s：守護進程DaemonSet

轉載請聲明出處哦~，本篇文章發布於luozhiyun的博客

最近也一直在加班，處理項目中的事情，發現問題越多越是感覺自己的能力不足，希望自己能多學點。我覺得人生的意義就是在於能夠不斷的尋求突破吧。

這篇文章會講DaemonSet和Job與CronJob一起。在講其中某一塊內容的時候，我會將一些其他內容也關聯上，讓讀者盡可能的看明白些，然后這篇開始我會開始加入一些主要源碼的分析。

如果覺得我講的不錯的，可以發個郵件鼓勵一下我噢~

Daemon Pod有三個主要特征：

1. 這個 Pod 運行在 Kubernetes 集群里的每一個節點（Node）上；
2. 每個節點上只有一個這樣的 Pod 實例；
3. 當有新的節點加入 Kubernetes 集群后，該 Pod 會自動地在新節點上被創建出來；而當舊節點被刪除后，它上面的 Pod 也相應地會被回收掉。

Daemon Pod可以運用在網絡插件的Agent組件上、日志組件、監控組件等。

創建一個DaemonSet#

Copy

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:  - key: node-role.kubernetes.io/master  effect: NoSchedule  containers:  - name: fluentd-elasticsearch  image: mirrorgooglecontainers/fluentd-elasticsearch:v2.4.0  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，管理的是一個 fluentd-elasticsearch 鏡像的 Pod。通過 fluentd 將 Docker 容器里的日志轉發到 ElasticSearch 中。

這個DaemonSet中使用 selector 選擇管理所有攜帶了 name=fluentd-elasticsearch 標簽的 Pod。然后使用template定義了pod模板。

然后在運行這個DaemonSet后，一個叫DaemonSet Controller的控制器會從 Etcd 里獲取所有的 Node 列表，然后遍歷所有的 Node。然后檢查Node上是不是又name=fluentd-elasticsearch 標簽的 Pod 在運行。

如果沒有這樣的pod，那么就創建一個這樣的pod；如果node上這樣的pod數量大於1，那么就會刪除多余的pod。

運行：

Copy

$ kubectl apply -f ds-els.yaml 

然后查看運行情況：

Copy

$ kubectl get pod -n kube-system -l name=fluentd-elasticsearch NAME READY STATUS RESTARTS AGE fluentd-elasticsearch-nwqph 1/1 Running 0 4m11s 

由於我這是單節點，所以只有一個pod運行了。

然后查看一下 Kubernetes 集群里的 DaemonSet 對象：

Copy

$ kubectl get ds -n kube-system fluentd-elasticsearch NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE fluentd-elasticsearch 1 1 1 1 1 <none> 27m 

然后我們來稍微看一下源碼，k8s是通過daemon_controller里面的manage方法來管理Pod刪減操作的：

manage方法里面首先會獲取daemon pod 與 node 的映射關系，然后判斷每一個 node 是否需要運行 daemon pod，然后遍歷完node之后將需要創建的Pod列表和需要刪除Pod的列表交給syncNodes執行。

Copy

func (dsc *DaemonSetsController) manage(ds *apps.DaemonSet, nodeList []*v1.Node, hash string) error { // 獲取已存在 daemon pod 與 node 的映射關系 nodeToDaemonPods, err := dsc.getNodesToDaemonPods(ds) if err != nil { return fmt.Errorf("couldn't get node to daemon pod mapping for daemon set %q: %v", ds.Name, err) } // 判斷每一個 node 是否需要運行 daemon pod var nodesNeedingDaemonPods, podsToDelete []string for _, node := range nodeList { nodesNeedingDaemonPodsOnNode, podsToDeleteOnNode, err := dsc.podsShouldBeOnNode( node, nodeToDaemonPods, ds) if err != nil { continue } //將需要刪除的Pod和需要在某個節點創建Pod存入列表中 nodesNeedingDaemonPods = append(nodesNeedingDaemonPods, nodesNeedingDaemonPodsOnNode...) podsToDelete = append(podsToDelete, podsToDeleteOnNode...) } podsToDelete = append(podsToDelete, getUnscheduledPodsWithoutNode(nodeList, nodeToDaemonPods)...) //為對應的 node 創建 daemon pod 以及刪除多余的 pods if err = dsc.syncNodes(ds, podsToDelete, nodesNeedingDaemonPods, hash); err != nil { return err } return nil } 

下面我們看一下podsShouldBeOnNode方法是如何判斷哪些Pod需要創建和刪除的：

在podsShouldBeOnNode會調用nodeShouldRunDaemonPod方法來判斷該node是否需要運行 daemon pod 以及能不能調度成功，然后獲取該node上有沒有創建該daemon pod。

通過判斷shouldRun, shouldContinueRunning將需要創建 daemon pod 的 node 列表以及需要刪除的 pod 列表獲取到，shouldSchedule 主要檢查 node 上的資源是否充足，shouldContinueRunning 默認為 true。

Copy

func (dsc *DaemonSetsController) podsShouldBeOnNode( node *v1.Node, nodeToDaemonPods map[string][]*v1.Pod, ds *apps.DaemonSet, ) (nodesNeedingDaemonPods, podsToDelete []string, err error) { //判斷該 node 是否需要運行 daemon pod 以及能不能調度成功 shouldRun, shouldContinueRunning, err := dsc.nodeShouldRunDaemonPod(node, ds) if err != nil { return } //獲取該節點上的指定ds的pod列表 daemonPods, exists := nodeToDaemonPods[node.Name] switch { //如果daemon pod是可以運行在這個node上，但是還沒有創建，那么創建一個 case shouldRun && !exists: nodesNeedingDaemonPods = append(nodesNeedingDaemonPods, node.Name) // 需要 pod 一直運行 case shouldContinueRunning: var daemonPodsRunning []*v1.Pod for _, pod := range daemonPods { if pod.DeletionTimestamp != nil { continue } //如果 pod 運行狀態為 failed，則刪除該 pod if pod.Status.Phase == v1.PodFailed { ... podsToDelete = append(podsToDelete, pod.Name) } else { daemonPodsRunning = append(daemonPodsRunning, pod) } } //如果節點上已經運行 daemon pod 數 > 1，保留運行時間最長的 pod，其余的刪除 if len(daemonPodsRunning) > 1 { sort.Sort(podByCreationTimestampAndPhase(daemonPodsRunning)) for i := 1; i < len(daemonPodsRunning); i++ { podsToDelete = append(podsToDelete, daemonPodsRunning[i].Name) } } // 如果 pod 不需要繼續運行但 pod 已存在則需要刪除 pod case !shouldContinueRunning && exists: for _, pod := range daemonPods { if pod.DeletionTimestamp != nil { continue } podsToDelete = append(podsToDelete, pod.Name) } } return nodesNeedingDaemonPods, podsToDelete, nil } 

DaemonSet 對象的滾動更新和StatefulSet是一樣的，可以通過 .spec.updateStrategy.type 設置更新策略。目前支持兩種策略：

• OnDelete：默認策略，更新模板后，只有手動刪除了舊的 Pod 后才會創建新的 Pod；
• RollingUpdate：更新 DaemonSet 模版后，自動刪除舊的 Pod 並創建新的 Pod。

具體的滾動更新可以在：5.深入k8s：StatefulSet控制器回顧一下。

僅在某些節點上運行 Pod#

如果想讓DaemonSet在某個特定的Node上運行，可以使用nodeAffinity。

如下：

Copy

apiVersion: v1 kind: Pod metadata:  name: with-node-affinity spec:  affinity:  nodeAffinity:  requiredDuringSchedulingIgnoredDuringExecution:  nodeSelectorTerms:  - matchExpressions:  - key: metadata.name  operator: In  values:  - node1 

上面的這個pod，我們指定了nodeAffinity，matchExpressions的含義是這個pod只能運行在metadata.name是node1的節點上，operator=In表示部分匹配的意思，除此之外operator還可以指定：In，NotIn，Exists，DoesNotExist，Gt，Lt等。

requiredDuringSchedulingIgnoredDuringExecution表明將pod調度到一個節點必須要滿足的規則。除了這個規則還有preferredDuringSchedulingIgnoredDuringExecution將pod調度到一個節點可能不會滿足規則

當我們使用如下命令的時候：

Copy

$ kubectl edit pod -n kube-system fluentd-elasticsearch-nwqph ... spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchFields: - key: metadata.name operator: In values: - node1 ... 

可以看到DaemonSet自動幫我們加上了affinity來進行節點調度。我們也可以自己在yaml里面設置affinity，以此來覆蓋系統默認的配置。

Taints and Tolerations#

在k8s集群中，我們可以給Node打上污點，這樣可以讓pod避開那些不合適的node。在node上設置一個或多個Taint后，除非pod明確聲明能夠容忍這些污點，否則無法在這些node上運行。

例如：

Copy

kubectl taint nodes node1 key=value:NoSchedule 

上面給node1打上了一個污點，這將阻止pod調度到node1這個節點上。

如果要移除這個污點，可以這么做：

Copy

kubectl taint nodes node1 key:NoSchedule- 

如果我們想讓pod運行在有污點的node節點上，我們需要在pod上聲明Toleration，表明可以容忍具有該Taint的Node。

比如我們可以聲明如下pod：

Copy

apiVersion: v1 kind: Pod metadata:  name: pod-taints spec:  tolerations:  - key: "key"  operator: "Equal"  value: "value"  effect: "NoSchedule"  containers:  - name: pod-taints  image: busybox:latest 

operator在這里可以是Exists表示無需指定value，值為Equal表明需要指明和value相等。

NoSchedule表示如果一個pod沒有聲明容忍這個Taint，則系統不會把該Pod調度到有這個Taint的node上。除了NoSchedule外，還可以是PreferNoSchedule，表明如果一個Pod沒有聲明容忍這個Taint，則系統會盡量避免把這個pod調度到這一節點上去，但不是強制的。

在上面的fluentd-elasticsearch DaemonSet 里，我們加上了

Copy

tolerations: - key: node-role.kubernetes.io/master effect: NoSchedule 

是因為在默認情況下，Kubernetes 集群不允許用戶在 Master 節點部署 Pod。因為，Master 節點默認攜帶了一個叫作node-role.kubernetes.io/master的“污點”。所以，為了能在 Master 節點上部署 DaemonSet 的 Pod，我就必須讓這個 Pod“容忍”這個“污點”