容器化守护进程的意义:DaemonSet
DaemonSet 的主要作用,是让你在 Kubernetes 集群里,运行一个 Daemon Pod。 所以,这个 Pod 有如下三个特征:
- 这个 Pod 运行在 Kubernetes 集群里的每一个节点(Node)上;
- 每个节点上只有一个这样的 Pod 实例;
- 当有新的节点加入 Kubernetes 集群后,该 Pod 会自动地在新节点上被创建出来;而当旧节点被删除后,它上面的 Pod 也相应地会被回收掉。
使用场景:
-
各种网络插件的 Agent 组件,都必须运行在每一个节点上,用来处理这个节点上的容器网 络;
-
各种存储插件的 Agent 组件,也必须运行在每一个节点上,用来在这个节点上挂载远程存 储目录,操作容器的 Volume 目录;
-
各种监控组件和日志组件,也必须运行在每一个节点上,负责这个节点上的监控信息和日志 搜集。
实例:
yaml
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:
# 这些容忍度设置是为了让该守护进程集在控制平面节点上运行
# 如果你不希望自己的控制平面节点运行 Pod,可以删除它们
- key: node-role.kubernetes.io/control-plane
operator: Exists
effect: NoSchedule
- key: node-role.kubernetes.io/master
operator: Exists
effect: NoSchedule
containers:
- name: fluentd-elasticsearch
image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
volumeMounts:
- name: varlog
mountPath: /var/log
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
DaemonSet,管理的是一个 fluentd-elasticsearch 镜像的 Pod,通过 fluentd 将 Docker 容器里的日志转发到 ElasticSearch 中。
它也使用 selector 选择管理所有携带了 name=fluentd-elasticsearch 标签的 Pod。
容器挂载了两个 hostPath 类型的 Volume,分别对应宿主机的 /var/log 目录和 /var/lib/docker/containers 目录。
显然,fluentd 启动之后,它会从这两个目录里搜集日志信息,并转发给 ElasticSearch 保存。 这样,我们通过 ElasticSearch 就可以很方便地检索这些日志了。
需要注意的是,Docker 容器里应用的日志,默认会保存在宿主机的 /var/lib/docker/containers/{{. 容器 ID}}/{{. 容器 ID}}-json.log 文件里,所以这个目录正是 fluentd 的搜集目标。
那么,DaemonSet 又是如何保证每个 Node 上有且只有一个被管理的 Pod 呢?
DaemonSet Controller,首先从 Etcd 里获取所有的 Node 列表,然后遍历所有的 Node。这 时,它就可以很容易地去检查,当前这个 Node 上是不是有一个携带了 name=fluentdelasticsearch 标签的 Pod 在运行。
而检查的结果,可能有这三种情况:
-
没有这种 Pod,那么就意味着要在这个 Node 上创建这样一个 Pod;
-
有这种 Pod,但是数量大于 1,那就说明要把多余的 Pod 从这个 Node 上删除掉;
-
正好只有一个这种 Pod,那说明这个节点是正常的。
如何在指定的 Node 上创建新 Pod 呢?
答案:使用 nodeSelector ,但其实已经是一个将要被废弃的字段了,代替它是 nodeAffinity。
总结:
DaemonSet 其实是一个非常简单的控制器。在它 的控制循环中,只需要遍历所有节点,然后根据节点上是否有被管理 Pod 的情况,来决定是否 要创建或者删除一个 Pod。
只不过,在创建每个 Pod 的时候,DaemonSet 会自动给这个 Pod 加上一个 nodeAffinity,从 而保证这个 Pod 只会在指定节点上启动。同时,它还会自动给这个 Pod 加上一个 Toleration,从而忽略节点的 unschedulable"污点"。
DaemonSet 原理及源码分析
内容的涵盖
将介绍 DaemonSet 是如何进行状态的同步、Pod 与 Node 之间的调度方式和滚动更新的过程以及实现原理。
什么是 DaemonSet ?
DaemonSet 作用就是保证 kubernetes 集群中部分或所有节点都能够运行同一份 Pod 副本,如果当有新的 Node 加入到集群,Pod 就会在目标的节点上启动;如果节点在集群中被剔除,那么该节点上 Pod 也会被剔除(被垃圾收集器清理掉)。
DaemonSet 典型使用场景
(1)日志和监控数据,在 Kubernetes 集群中收集每个节点上的日志及监控数据,可以启动 fluentd 和 Prometheus 来收集;
(2)如网络插件的 Agent 组件,都必须运行在每一个节点上,那么可以创建 DaemonSet 守护进程用来处理这个节点上的容器网络;
(3)各种存储插件的 Agent 组件,也必须运行在每一个节点上,用来在这个节点上挂载远程存储目录,操作容器的 Volume 目录;
DaemonSet 例子
官网例子
daemonset.yaml
yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
namespace: kube-system
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
containers:
- name: fluentd-elasticsearch
image: k8s.gcr.io/fluentd-elasticsearch:2.5.2
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
基于 YAML 文件创建 DaemonSet:kubectl apply -f daemonset.yaml
创建成功后,在 Kubernetes 集群的 kube-system
命名空间中创建 DaemonSet 资源并在所有的节点上创建新的 Pod。
当添加新的节点时,Kubernetes 就会创建在新节点上创建新的副本,看下面拓扑结构图清晰:
实现原理
所有的 DaemonSet 都是由控制器负责管理的,与其他的资源一样,用于管理 DaemonSet 的控制器是 DaemonSetsController
,该控制器会监听 DaemonSet、ControllerRevision、Pod 和 Node 资源的变动。
DaemonSetsController 结构体源码位于:pkg/controller/daemon/daemon_controller.go
daemonset controller架构图
daemonset controller核心逻辑
DaemonSetsController
同步 DaemonSet 资源使用的方法就是syncDaemonSet
,这个方法会从队列中拿到 DaemonSet 的名字时,但会先从集群中获取最新的 DaemonSet 对象并通过constructHistory
方法查找当前 DaemonSet 全部的历史版本:
go
func (dsc *DaemonSetsController) syncDaemonSet(ctx context.Context, key string) error {
// 获取当前时间计算该方法总执行时间,也即统计对一个 daemonset 进行同步调谐操作的耗时情况
startTime := dsc.failedPodsBackoff.Clock.Now()
// 根据 daemonset 对象的命名空间与名称,获取 daemonset 对象
ds, err := dsc.dsLister.DaemonSets(namespace).Get(name)
// 获取所有node的对象列表
nodeList, err := dsc.nodeLister.List(labels.Everything())
// 获取daemonset的历史版本
cur, old, err := dsc.constructHistory(ctx, ds)
// 判断该 daemonset 对象是否满足expectations机制
if !dsc.expectations.SatisfiedExpectations(dsKey) {
// 不满足则更新daemonset状态后直接return
return dsc.updateDaemonSetStatus(ctx, ds, nodeList, hash, false)
}
// manage 保证 daemonset 的pod运行在每台合适条件的node上,如果遇到合适的node上没有daemonset的pod时就会创建pod,
// 且不符合条件的node上的daemonset pod删除掉
err = dsc.manage(ctx, ds, nodeList, hash)
if err != nil {
return err
}
// Process rolling updates if we're ready.
// 再次调用,判断是否满足expectations机制:
// 如果策略为OnDelete不做额外处理
// 因为只有当手动删除旧的DaemonSet pods之后,新的 DaemonSet Pod 才会被自动创建(创建新版本的pod在dsc.manage方法中)
if dsc.expectations.SatisfiedExpectations(dsKey) {
switch ds.Spec.UpdateStrategy.Type {
case apps.OnDeleteDaemonSetStrategyType:
case apps.RollingUpdateDaemonSetStrategyType:
// 如果是滚动更新则调用 rollingUpdate
err = dsc.rollingUpdate(ctx, ds, nodeList, hash)
}
}
// 清理daemonset的已经不存在pod的历史版本
err = dsc.cleanupHistory(ctx, ds, old)
if err != nil {
return fmt.Errorf("failed to clean up revisions of DaemonSet: %v", err)
}
// 根据当前daemonset pod的状态及node是否满足pod运行条件等信息,然后更新daemonset的状态
return dsc.updateDaemonSetStatus(ctx, ds, nodeList, hash, true)
}
daemonset controller如何对pod创建和删除操作
控制器调用 syncNodes
对这些需要创建和删除的 Pod 进行同步的。