1.daemonset概述

    DaemonSet是Kubernetes中的一种资源对象，它用于确保集群中的每个节点都运行着一个相同
的Pod副本。与Deployment或ReplicaSet不同，它们会尽量确保在每个节点上运行指定数量的Pod
副本。
   每当有新节点加入集群或者已有节点发生变化（如节点故障或节点扩容），DaemonSet会自动在新
节点上创建一个Pod副本，以确保集群的每个节点都具有所需的Pod实例。
   DaemonSet通常用于在集群的每个节点上运行一些特殊的系统级别任务，例如日志收集、监控代理
或网络插件。它们还可用于确保集群中的每个节点都具有相同的配置或运行特定的系统服务。


   

2.DaemonSet工作原理：如何管理Pod？

1、创建：当你创建一个DaemonSet对象时，Kubernetes控制器会检查集群中的每个节点，并在
每个节点上创建一个Pod副本。
2、调度：Pod的调度是由Kubernetes调度器处理的。调度器会根据节点的资源可用性和调度策
略，将Pod分配给适合的节点。通常情况下，每个节点只能运行一个DaemonSet Pod副本。
3、监控和自适应：一旦DaemonSet的Pod副本在节点上启动，Kubernetes控制器会监视节点
的状态。如果节点发生变化，比如节点故障、节点添加或移除，控制器将采取相应的措施来维持
DaemonSet的副本数量。例如，如果新节点加入集群，控制器将在新节点上创建一个Pod副本。
4、节点更新：当集群中的节点需要进行系统更新或升级时，DaemonSet可以与节点的更新流程进
行集成。您可以设置DaemonSet的更新策略，以确保在节点更新时，Pod副本能够平滑地迁移到其他
节点上，以保持集群的高可用性。
5、删除：如果您删除了一个DaemonSet对象，Kubernetes控制器将停止在所有节点上运行的
Pod副本，并将它们从集群中删除。

Daemonset典型的应用场景

1、日志收集：您可以使用DaemonSet在每个节点上运行日志收集代理，例如Fluentd或
Filebeat。这样可以确保每个节点的日志都被收集并发送到集中式日志存储或分析系统中。
2、监控和指标收集：DaemonSet可用于在每个节点上运行监控代理，例如Prometheus Node
Exporter，以收集节点级别的指标数据，如CPU、内存、磁盘和网络使用情况。这有助于进行集群性能
监控和故障排查。
3、网络插件和代理：DaemonSet可用于在每个节点上部署网络插件，例如Calico、Flannel或
Weave，以提供集群内部和集群外部的网络功能，如网络隔离、负载均衡和服务发现。
4、安全和授权代理：您可以使用DaemonSet在每个节点上运行安全代理，例如Sidecar容器或网
络代理，用于处理入站和出站的流量，实施网络策略、访问控制和身份验证。
5、资源调度和优化：DaemonSet可用于在每个节点上运行资源调度和优化的代理，例如Kubelet
或Node problem detector。这些代理可以监测节点的资源利用率、负载状况和健康状况，并采取相应
的措施来调整和优化资源分配。
6、数据存储和持久化：在每个节点上运行DaemonSet可以实现本地数据存储和持久化，例如使用
Local Persistent Volumes。这对于需要高性能的本地存储或特定节点级别的数据处理任务非常有用。

DaemonSet与Deployment的区别
1、Pod副本的数量：在Deployment中，您可以定义所需的Pod副本数量，Kubernetes将确保
在集群中运行指定数量的Pod副本。而在DaemonSet中，每个节点上只能运行一个Pod副本，
DaemonSet会自动在每个节点上创建Pod。
2、调度策略：Deployment的Pod可以在集群中的任何节点上进行调度，调度器会根据节点的可
用性和资源情况来选择合适的节点。而DaemonSet的Pod只能在每个节点上运行一个副本，无法在同
一节点上运行多个相同的Pod副本。
3、滚动更新：Deployment支持滚动更新策略，可以控制Pod的版本升级过程，确保无中断地进
行应用程序的更新。而DaemonSet通常用于运行系统级别的任务，不涉及滚动更新。
5、故障恢复和节点变化：Deployment在节点故障或节点扩容时，会自动将Pod副本重新调度到
其他可用节点上，以确保高可用性。而DaemonSet会在新节点加入集群或节点发生变化时，在新节点
上创建一个Pod副本，以保持在每个节点上都运行一个Pod副本。

#查看DaemonSet的spec字段如何定义？
[root@xuegod63 ~]# kubectl explain ds.spec
KIND:DaemonSet
VERSION:apps/v1
RESOURCE: spec
DESCRIPTION:
The desired behavior of this daemon set. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-
conventions.md#spec-and-status
DaemonSetSpec is the specification of a daemon set.
FIELDS:
1.minReadySeconds：指定新的Pod启动后，在几秒钟之后才会终止旧的Pod。这个字段是
一个整数值，用于控制滚动更新过程中的最小就绪时间。在启动新的Pod之后，如果
minReadySeconds时间内旧的Pod仍然处于运行状态，Kubernetes将保留旧的Pod，
确保新的Pod正确启动并运行后再终止旧的Pod。
2.revisionHistoryLimit：指定保留的历史版本数量。这个字段是一个整数值，用于控制保留的
DaemonSet历史版本的数量。Kubernetes将保留历史版本的副本集，以便可以回滚到之前
的版本，避免意外的升级问题。
3.selector：用于匹配Pod的标签选择器。这个字段是一个对象，其中可以包含以下字段：
•matchLabels：用于选择将Pod分配给DaemonSet的节点的标签。Pod必须具
有与matchLabels字段匹配的标签才能被分配到DaemonSet。
•matchExpressions：可以使用表达式来定义更复杂的选择规则，例如根据标签的键、
值和操作符进行选择。
4.template：定义了要在每个节点上运行的Pod模板。这个字段是一个对象，其中包含了定义
Pod配置的详细信息，例如容器的规格、镜像、环境变量、挂载卷等。所有基于这个模板定义
的Pod都具有相同的配置和规格。
5.updateStrategy：定义了DaemonSet的升级策略。这个字段是一个对象，其中可以包含以
下字段：
•type：指定升级策略的类型，可以是"RollingUpdate"或"OnDelete"。
•rollingUpdate：如果升级策略类型为"RollingUpdate"，则可以配置以下字段：
•maxUnavailable：指定在进行滚动更新时，最大允许的不可用Pod的数
量。
•maxSurge：指定在进行滚动更新时，最大允许的超出期望Pod
数量的数量。

备注：当同时设置了minReadySeconds和就绪探测时，它们是相互独立的，而不会互相影响。下
面是对它们的进一步解释：
1、minReadySeconds字段定义了在新的Pod启动后，在指定的秒数内，旧的Pod保持运行状
态，即使新的Pod已经就绪。这个字段的作用是确保在进行滚动更新时，新的Pod有足够的时间来完
成启动和初始化过程，然后才会终止旧的Pod。换句话说，即使新的Pod标记为就绪，旧的Pod也
会在滚动更新过程中保持运行一段时间，以确保没有中断或丢失的请求。minReadySeconds适用于整
体的DaemonSet升级过程。
2、就绪探测（readiness probe）是一个用于检查容器是否已经准备好接收流量的机制。通过定义
就绪探测，Kubernetes可以检测到Pod是否已经准备好接收流量，并将其标记为就绪状态，如果
pod前面有svc代理，pod就会被svc关联到

实战DaemonSet使用案例-日志收集组件fluentd

#把fluentd-2-5-1.tar.gz上传到xuegod63和xuegod62和xuegod64上，解压
[root@xuegod62]#ctr-n=k8s.io images importfluentd-2-5-1.tar.gz
[root@xuegod64]#ctr-n=k8s.io images importfluentd-2-5-1.tar.gz
[root@xuegod63]#ctr-n=k8s.io images importfluentd-2-5-1.tar.gz

root@ubuntu0:~/k8s/daemonset# cat daemonset.yaml 
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: logging
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-logging
  template:
    metadata:
      labels:
        name: fluentd-logging
    spec:
      tolerations:  #容忍控制节点的污点
      - key: node-role.kubernetes.io/control-plane
        effect: NoSchedule
      nodeSelector:
         kubernetes.io/os: linux  #节点标签选择器
      containers:
      - name: fluentd
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2 
        imagePullPolicy: IfNotPresent


运行
root@ubuntu0:~/k8s/daemonset# kubectl apply -f daemonset.yaml 
daemonset.apps/logging created
root@ubuntu0:~/k8s/daemonset# kubectl get pod -o wide -n kube-system
NAME                              READY   STATUS             RESTARTS           AGE   IP              NODE      NOMINATED NODE   READINESS GATES
coredns-5d7556cdcf-zsqfl          0/1     CrashLoopBackOff   4252 (4m57s ago)   28d   10.100.2.187    ubuntu1   <none>           <none>
etcd-ubuntu0                      1/1     Running            2556 (28d ago)     47d   192.168.23.99   ubuntu0   <none>           <none>
kube-apiserver-ubuntu0            1/1     Running            2532 (28d ago)     47d   192.168.23.99   ubuntu0   <none>           <none>
kube-controller-manager-ubuntu0   1/1     Running            24                 47d   192.168.23.99   ubuntu0   <none>           <none>
kube-proxy-7kqtj                  1/1     Running            0                  28d   192.168.23.97   ubuntu2   <none>           <none>
kube-proxy-d7rst                  1/1     Running            0                  28d   192.168.23.98   ubuntu1   <none>           <none>
kube-proxy-k66mm                  1/1     Running            0                  28d   192.168.23.99   ubuntu0   <none>           <none>
kube-scheduler-ubuntu0            1/1     Running            29 (24d ago)       47d   192.168.23.99   ubuntu0   <none>           <none>
logging-8hhms                     1/1     Running            0                  14s   10.100.0.186    ubuntu2   <none>           <none>
logging-d4xpm                     1/1     Running            0                  14s   10.100.1.3      ubuntu0   <none>           <none>
logging-vbhjq                     1/1     Running            0                  14s   10.100.2.197    ubuntu1   <none>           <none>
root@ubuntu0:~/k8s/daemonset# kubectl get ds -o wide -n kube-system
NAME         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE   CONTAINERS   IMAGES                                                        SELECTOR
kube-proxy   3         3         3       3            3           kubernetes.io/os=linux   28d   kube-proxy   registry.aliyuncs.com/google_containers/kube-proxy:v1.23.17   k8s-app=kube-proxy
logging      3         3         3       3            3           kubernetes.io/os=linux   60s   fluentd      quay.io/fluentd_elasticsearch/fluentd:v2.5.2                  name=fluentd-logging
root@ubuntu0:~/k8s/daemonset# 

root@ubuntu0:~/k8s/daemonset# kubectl get pod -n kube-system -l name=fluentd-logging
NAME            READY   STATUS    RESTARTS   AGE
logging-8hhms   1/1     Running   0          9m30s
logging-d4xpm   1/1     Running   0          9m30s
logging-vbhjq   1/1     Running   0          9m30s




解释
spec：定义了Pod模板的规范。
•tolerations：定义了Pod对节点的容忍配置。
•key:node-role.kubernetes.io/master：指定容忍的键
为"node-role.kubernetes.io/master"，用于容忍
Master节点。
•effect:NoSchedule：设置容忍效果为NoSchedule，即
允许DaemonSet在Master节点上运行。

实战：Daemonset管理pod-滚动更新

#查看daemonset的滚动更新策略
[root@xuegod63 ~]# kubectl explain ds.spec.updateStrategy
KIND:DaemonSet
VERSION:apps/v1
RESOURCE: updateStrategy <Object>
DESCRIPTION:
An update strategy to replace existing DaemonSet pods with new pods.
DaemonSetUpdateStrategy is a struct used to control the update strategy for
a DaemonSet.
FIELDS:
rollingUpdate<Object>
Rolling update config params. Present only if type = "RollingUpdate".
type<string>
Type of daemon set update. Can be "RollingUpdate" or "OnDelete".Default is
RollingUpdate.
#查看rollingUpdate字段
[root@xuegod63 ~]# kubectl explain ds.spec.updateStrategy.rollingUpdate
KIND:DaemonSet
VERSION:apps/v1
RESOURCE: rollingUpdate <Object>
DESCRIPTION:
Rolling update config params. Present only if type = "RollingUpdate".
Spec to control the desired behavior of daemon set rolling update.
FIELDS:
maxUnavailable<string>
maxSugre
由于DaemonSet在每个节点上只运行一个副本，因此maxUnavailable字段在这种情况下
的作用较小。在滚动更新期间，它指定了可以同时不可用的最大Pod副本数。然而，由于每个节点只有
一个副本，所以无论设置为什么值，都只会同时不可用一个副本。
maxSurge字段对于DaemonSet更有意义，它定义了可以同时创建的超过所需副本数的最
大Pod副本数。在滚动更新期间，当新节点加入集群时，通过增加临时的额外副本，可以让集群中同时
存在多个Pod副本。这些额外副本会在滚动更新完成后被逐步删除，以保持每个节点上只有一个副本。

Job和CronJob控制器：概念、原理解读

在Kubernetes中，Job是一种用于执行短暂任务的资源对象。它用于在集群中创建一个或多个
Pod来完成任务，确保任务成功完成后自动终止。

Job控制器：资源清单编写技巧

[root@xuegod63 ~]# kubectl explain Job
KIND:Job
VERSION:batch/v1
DESCRIPTION:
Job represents the configuration of a single job.
FIELDS:
apiVersion<string>#当前Job的api版本
kind<string>#指定当前的资源类型
metadata<Object>#元数据，定义资源的名字和所在名称空间
spec<Object>
#查看Job下的spec字段
[root@xuegod63 ~]# kubectl explain Job.spec
KIND:Job
VERSION:batch/v1
RESOURCE: spec <Object>
DESCRIPTION:
Specification of the desired behavior of a job. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-
conventions.md#spec-and-status
JobSpec describes how the job execution will look like.
FIELDS:
activeDeadlineSeconds<integer> #通过指定job存活时间，来结束一个job。当job运
行时间达到activeDeadlineSeconds指定的时间后，job会停止由它启动的所有任务（如：pod），并
设置job的状态为failed
backoffLimit<integer> #job建议指定pod的重启策略为never，
如：.spec.template.spec.restartPolicy = "Never"，然后通过job的backoffLimit来指定失败重试
次数，在达到backoffLimit指定的次数后，job状态设置为failed（默认为6次）
completions<integer> #指定job启动的任务（如：pod）成功运行completions次，
job才算成功结束
manualSelector<boolean>
parallelism<integer>#指定job同时运行的任务（如：pod）个数，Parallelism默认为1，
如果设置为0，则job会暂定
selector<Object>
template<Object>-required-
ttlSecondsAfterFinished<integer> #默认情况下，job异常或者成功结束后，包括job启
动的任务（pod），都不会被清理掉，因为你可以依据保存的job和pod，查看状态、日志，以及调试
等。这些用户可以手动删除，用户手动删除job，job controller会级联删除对应的pod，除了手动删
除，通过指定参数ttlSecondsAfterFinished也可以实现自动删除job，以及级联的资源，如：pod。
如果设置为0，job会被立即删除。如果不指定，job则不会被删除

CronJob使用案例-创建周期性的定时任务

CronJob所描述的，正是定时任务。
1、在给定时间点只运行一次
2、在给定时间点周期性地运行
一个CronJob对象类似于crontab（cron table）文件中的一行。它根据指定的预定计划周期
性地运行一个Job。在这里简单的说一下cron，是指unix中cron表达式。比如："*/1 * * * *"，这个
Cron表达式里*/1中*表示从0开始，/表示"每"，1表示偏移量，所以它的意思是：从0开始，每1
个时间单位执行一次。Cron表达式中五个部分分别代表：分钟，小时，日，月，星期。所以上述这句
Cron表达式的意思是：从当前开始，每分钟执行一次。那么我们可以利用这个机制来指定创建mysql
备份任务的对象:
apiVersion: batch/v1
kind: CronJob
metadata:
  name: mysqldump# CronJob的名称
spec:
  schedule: "50 15 * * *"#定时任务的调度时间，表示每天的15:50执行
  jobTemplate:#定义Job的模板
spec:
completions: 1#完成任务的副本数
template:
spec:
restartPolicy: Never# Job完成后不重启
volumes:#定义需要挂载的卷
-name: mysql-master-script
hostPath:
path: /root/app/mysql/shell#挂载到容器内的路径
-name: mysql-master-backup
hostPath:
path: /root/app/db/backup#挂载到容器内的路径
-name: local-time
hostPath:
path: /etc/localtime#挂载到容器内的路径
containers:#容器定义
-name: mysqldump-container#容器的名称
image: nacos/nacos-mysql-master:latest#容器所使用的镜像
volumeMounts:#定义容器内挂载的卷
-name: mysql-master-script
mountPath: /var/db/script#挂载到容器内的路径
-name: local-time
mountPath: /etc/localtime#挂载到容器内的路径
-name: mysql-master-backup
mountPath: /var/db/backup#挂载到容器内的路径
command:#定义容器执行的命令
-"sh"
-"/var/db/script/mysqldump.sh"#执行的脚本路径



备份数据库的脚本：
mysqldump.sh脚本如下:
#!/bin/bash
#定义备份文件的数量
number=3
#备份保存路径
backup_dir=/var/db/backup
#当前日期
dd=`date +%Y%m%d`
#备份工具路径
tool=/usr/bin/mysqldump
#数据库用户名
username=root
#数据库密码
password=root
#要备份的数据库名称
database_name=test
#使用mysqldump命令备份指定的数据库到指定路径下的文件
$tool-u $username-p$password-h mysql-master-P3306--databases
$database_name > $backup_dir/$database_name-$dd.sql
#记录备份操作到日志文件
echo "create $backup_dir/$database_name-$dd.sql" >> $backup_dir/log.txt
#查找需要删除的备份文件
delfile=`ls-l-crt$backup_dir/*.sql | awk '{print $9 }' | head-1`
#判断当前备份文件的数量是否超过限制
count=`ls-l-crt$backup_dir/*.sql | awk '{print $9 }' | wc-l`
if [ $count-gt $number ]
then
rm $delfile#删除最早生成的备份文件，只保留指定数量的备份
#记录删除文件操作到日志文件
echo "delete $delfile" >> $backup_dir/log.txt
fi