.深入k8s：守護程序DaemonSet

阿新 • • 發佈：2020-08-11

轉載請宣告出處哦~，本篇文章釋出於luozhiyun的部落格

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

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

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

Daemon Pod有三個主要特徵：

這個 Pod 執行在 Kubernetes 叢集裡的每一個節點（Node）上；
每個節點上只有一個這樣的 Pod 例項；

當有新的節點加入 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“容忍”這個“汙點”

.深入k8s：守護程序DaemonSet

建立一個DaemonSet#

僅在某些節點上執行 Pod#

Taints and Tolerations#

6.深入k8s：守護程序DaemonSet

.深入k8s：守護程序DaemonSet

38 k8s-16DaemonSet：守護程序集

4.深入k8s：容器持久化儲存

5.深入k8s：StatefulSet控制器

python：守護程序deamon

7.深入k8s：任務呼叫Job與CronJob及原始碼分析

10.深入k8s：排程的優先順序及搶佔機制原始碼分析

11.深入k8s：kubelet工作原理及原始碼分析

13.深入k8s：Pod 水平自動擴縮HPA及其原始碼分析

PHP 疑難雜症：解決守護程序時 Redis 假死

容器化守護程序：demonSet

入門Kubernetes-DaemonSet物件(守護程序)

Windows 和 Linux 上Redis的安裝守護程序配置方法

Python守護程序實現過程詳解

.net Core 3.0 WebApi 建立Linux守護程序的方法

nodejs pm2守護程序使用

PHP程式守護程序化實現方法詳解

php socket網路程式設計基礎知識（四）：多程序

Python基礎知識點：多程序的應用講解

.深入k8s：守護程序DaemonSet

建立一個DaemonSet#

僅在某些節點上執行 Pod#

Taints and Tolerations#

相關推薦