了解k8s控制器DaemonSet的创建和使用场景。

DaemonSet简介DaemonSet的主要功能是在Kubernetes集群中运行一个Daemon Pod。DaemonSet只管理Pod对象，然后通过nodeAffinity和Toleration两个调度器参数的作用，保证每个节点上只有一个Pod。

DaemonSet是一款针对特定应用场景的Pod控制器。虽然它也可以管理Pod的多个副本，但它主要用于确保一个节点上只运行一个Pod:

在DaemonSet使用场景中，每个节点上只有一个这样的Daemon Pod实例，然后当一个新节点加入Kubernetes集群时，将在新节点上自动创建Pod。当旧节点被删除时，其上的Pod将被相应地回收。

Daemon Pod的意义真的非常重要。如的作用:

插件网络的代理组件必须在每个节点上运行，以处理该节点上的容器网络。存储插件的代理组件也必须在每个节点上运行，用来在这个节点上挂载远程存储目录，操作容器的卷目录，比如glusterd和ceph。监控组件和日志组件也必须在每个节点上运行，负责收集本节点上的监控信息和日志，如fluentd、logstash、Prometheus等。

DaemonSet创建k8s环境搭建参考在线教程，这里就不赘述了。

我们举个简单的例子，快速体验一下DaemonSet控制器是如何应用的。

一个简单的DaemonSet配置如下:

API version:apps/v1 kind:DaemonSetmetadata:name:nginx -daemonset标签:app: nginxspec:selector:matchLabels:app:nginx模板:元数据:标签:app:nginx规格:容器:-name: nginx映像:nginx: 1.17.0乍一看，这种配置基本类似于部署。唯一显著的区别是DaemonSet不需要指定副本的数量，因为它的副本数量取决于工作节点的数量。

DaemonSet配置中spec.selector和spec.template功能在部署介绍中已经介绍过了，这里不再赘述。

该配置将创建一个DaemonSet对象，然后DaemonSet控制器将根据对象信息在每个节点上创建一个Pod副本。

接下来，使用kubectl create命令将这个配置升级到kube-apiserver，如下所示:

[root @ k8s -master]# ku bectl create -f daemonset.yamldaemonset.apps/nginx-daemonset已创建

检查DaemonSet。首先检查您刚刚创建的DaemonSet对象:

[root @ k8s -master]# ku bectl get daemon set name DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR agenginx -daemon set 3 3 3 3 & lt；无& gt1m3s命令行输出中每个字段的含义如下:

NAME: DaemonSet对象名，与metadata.name相同。在配置上；DESIRED:所需的副本数，等于节点数(默认)，因为节点没有被刻意过滤；当前:当前创建的副本数量；就绪:处于就绪状态的份数；UP-TO-DATE:根据最新的POD模板创建的POD的数量；可用:可用的份数；节点选择器:节点选择器。在这个例子中，我们没有选择它，值为null年龄:自创建以来经过的时间。在以上字段中，除了节点选择器，我们已经在上一章介绍过了。实际上，节点选择器不是DaemonSet对象的唯一配置，而是Pod模板中用于为Pod匹配节点的配置。DaemonSet控制器使用此节点选择器来筛选需要复制的节点。如果未指定，默认情况下将选择所有节点。

然后，检查由DaemonSet控制器创建的Pod复制信息:

[root @ k8s -master]# ku bectl get pods -o wideNAME就绪状态重新启动AGE IP节点提名节点就绪状态gate gin x-daemonset -66 DBC 1/1运行0 5m 13s 10 . 135 . 3 . 2 k8s -master & lt；无& gt& lt无& gtnginx-daemonset-akpdg 1/1运行0 5m 13s 10 . 135 . 1 . 2 k8s -node 1 & lt；无& gt& lt无& gtnginx-daemonset-l3wnd 1/1运行0 5m 13s 10 . 135 . 2 . 2 k8s -node 2 & lt；无& gt& lt无& gt如您所见，在每个节点上都创建了一个副本，这是意料之中的。

更新DaemonSet。让我们适当地调整吊舱部署策略。我们只希望Pod运行在名为k8s-node的节点上，所以只需要配置DaemonSet对象的spec . template . spec . node selector来选择节点。

在k8s -节点的节点中，有一个标识该节点的标签:

Kubernetes.io/hostname: k8s -node 1使用kubectl edit命令修改已配置的spec . template . spec . node selector参数，如下所示:

API:apps/v1k ind:DaemonSetmetadata:...规格:...模板:...规格:...节点选择器:kubernetes.io/hostname: k8s -节点1然后再次观察daemonset对象和Pod的副本:

[root @ k8s -master]# ku bectl get daemonsetsNAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR agenginx -daemonse t 1 1 1 1 1 1 kubernetes.io/hostname=k8s-node1 37m[root @ k8s -master]# ku bectl get pods -o wideNAME READY状态重新启动AGE IP节点提名节点就绪gatesnginx -daemonset -66 GK 2 1/1运行0 10s 10 . 135 . 2 . 3 k8s -NODE 1 & lt；无& gt& lt无& gt可以发现，在DaemonSet状态下，NODE SELECTOR正确显示了上述修改，所需的Pod副本数也变成了一个，符合预期。

Pod原来的3个副本减少到了1个，它只运行在我们配置选择的节点(k8s-node1)上。

删除DaemonSet和其他Pod控制器一样，在删除DaemonSet对象时，其管理的Pod也会被默认删除。操作如下所示:

[root @ k8s -master ~]# ku ectl delete daemonsets nginx -daemonsetdaemonset . apps " nginx -daemonset " deleted[root @ k8s -master ~]# ku ectl get pods在默认命名空间中没有找到资源。

其他使用场景

使用DaemonSet的容差容差将自动向此Pod添加另一个与计划相关的字段，称为容差。此字段表示此Pod将& ldquo宽容& rdquo(容忍)某些节点& ldquo污点& rdquo(污点).

用yaml配置容错，如下所示:

API: v1种类:pod元数据:名称:具有-容差规格:容差:-关键字:node.kubernetes.io/unschedulable运算符:存在效果:没有计划被标记为不可计划& ldquo在正常情况下。污点& rdquo节点，将不安排任何Pod(效果:NoSchedule)。

但是，DaemonSet会自动将这种特殊的容错添加到受管理的POD中，以便这些POD可以忽略这种限制，然后确保每个节点都将被调度到一个POD。

当然，如果此节点失败，Pod可能无法启动，DaemonSet将一直尝试，直到Pod成功启动。

主要功能:

有了这样的容忍度，调度程序将忽略& ldquo在当前节点上。污点& rdquo以便成功地安排一些组件在这台机器上启动。

这种机制是我们在部署Kubernetes集群时，可以先部署Kubernetes本身，再部署网络插件的根本原因:因为我们当时创建的Weave的YAML实际上是一个DaemonSet。

nodeAffinity的使用在正常情况下，DaemonSet Controller会在创建Pod时自动将这样的nodeAffinity定义添加到Pod的API对象中。

在这个Pod中，声明了一个spec.affinity字段，然后定义了一个nodeAffinity。其中spec.affinity字段是Pod中与排班相关的字段。

使用yaml配置NodeAffinity，如下所示:

API version:v1 kind:pod metadata:name:demo -node -affinity spec:affinity:node affinity:requiredduringschedulingignoredduringeexecution:node selectors:-匹配表达式:-key:metadata . name operator:in values:-demo -node上述关键参数的含义是:

所需的调度忽略执行这表示nodeAffinity，每次调度时都必须考虑它。同时也意味着在某些情况下可以设置忽略这个节点亲和度；此Pod只允许在& ldquo上运行在未来。metadata.name & rdquo是& ldquodemo -节点& rdquo在…的节点上。

综上所述，DaemonSet实际上是通过nodeAffinity和宽容来实现的。这是一个守护进程，不需要添加设计结构，直接使用标签就可以完成。这个结构非常符合Kubernetes的控制器模型，也就是说一切都是对象。

以上是对k8s控制器DaemonSet的详细了解。更多关于k8s控制器DaemonSet的信息，请关注主机频道zhujipindao中的其他相关文章。com！