深入k8s：Kubernetes 守护进程DaemonSet及源码分析(1)

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 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

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

总结

我们总是喜欢瞻仰大厂的大神们，但实际上大神也不过凡人，与菜鸟程序员相比，也就多花了几分心思，如果你再不努力，差距也只会越来越大。实际上，作为程序员，丰富自己的知识储备，提升自己的知识深度和广度是很有必要的。

Mybatis源码解析

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
=“https://img-blog.csdnimg.cn/img_convert/f3591f04170add612f7158226cab9ffa.jpeg” alt=“img” style=“zoom: 33%;” />

总结

我们总是喜欢瞻仰大厂的大神们，但实际上大神也不过凡人，与菜鸟程序员相比，也就多花了几分心思，如果你再不努力，差距也只会越来越大。实际上，作为程序员，丰富自己的知识储备，提升自己的知识深度和广度是很有必要的。

Mybatis源码解析

[外链图片转存中…(img-CFMgzt95-1713746567266)]

[外链图片转存中…(img-EEiPYm0G-1713746567266)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！