深入k8s：守护进程DaemonSet及源码分析
推荐阅读：
最近也一直在加班，处理项目中的事情，发现问题越多越是感觉自己的能力不足，希望自己能多学点。我觉得人生的意义就是在于能够不断的寻求突破吧。
这篇文章会讲DaemonSet和Job与CronJob一起。在讲其中某一块内容的时候，我会将一些其他内容也关联上，让读者尽可能的看明白些，然后这篇开始我会开始加入一些主要源码的分析。
Daemon Pod有三个主要特征：
- 这个 Pod 运行在 Kubernetes 集群里的每一个节点（Node）上；
- 每个节点上只有一个这样的 Pod 实例；
- 当有新的节点加入 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。
具体的滚动更新可以在：深入k8s：kubernetes的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“容忍”这个“污点”。
