6.深刻k8s：守护进程DaemonSet

转载请声明出处哦~，本篇文章发布于luozhiyun的博客：https://www.luozhiyun.com

最近也一直在加班，处理项目中的事情，发现问题越多越是感受本身的能力不足，但愿本身能多学点。我以为人生的意义就是在于可以不断的寻求突破吧。

这篇文章会讲DaemonSet和Job与CronJob一块儿。在讲其中某一块内容的时候，我会将一些其余内容也关联上，让读者尽量的看明白些，而后这篇开始我会开始加入一些主要源码的分析。

若是以为我讲的不错的，能够发个邮件鼓励一下我噢~

Daemon Pod有三个主要特征：

1. 这个 Pod 运行在 Kubernetes 集群里的每个节点（Node）上；
2. 每一个节点上只有一个这样的 Pod 实例；
3. 当有新的节点加入 Kubernetes 集群后，该 Pod 会自动地在新节点上被建立出来；而当旧节点被删除后，它上面的 Pod 也相应地会被回收掉。

Daemon Pod能够运用在网络插件的Agent组件上、日志组件、监控组件等。

建立一个DaemonSet

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。

运行：

$ kubectl apply -f ds-els.yaml

而后查看运行状况：

$ 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 对象：

$ 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执行。

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。

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。

以下：

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调度到一个节点可能不会知足规则

当咱们使用以下命令的时候：

$ 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上运行。

例如：

kubectl taint nodes node1 key=value:NoSchedule

上面给node1打上了一个污点，这将阻止pod调度到node1这个节点上。

若是要移除这个污点，能够这么作：

kubectl taint nodes node1 key:NoSchedule-

若是咱们想让pod运行在有污点的node节点上，咱们须要在pod上声明Toleration，代表能够容忍具备该Taint的Node。

好比咱们能够声明以下pod：

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 里，咱们加上了

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

是由于在默认状况下，Kubernetes 集群不容许用户在 Master 节点部署 Pod。由于，Master 节点默认携带了一个叫做node-role.kubernetes.io/master的“污点”。因此，为了能在 Master 节点上部署 DaemonSet 的 Pod，我就必须让这个 Pod“容忍”这个“污点”。

Reference

http://www.javashuo.com/article/p-nkdboqbv-ke.html

https://kubernetes.io/docs/concepts/workloads/controllers/daemonset

https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/

https://kuboard.cn/learning/k8s-intermediate/workload/wl-daemonset/