【K8S系列】深入解析DaemonSet
序言
时间永远是旁观者，所有的过程和结果，都需要我们自己去承担。
文章标记颜色说明：
- 黄色：重要标题
- 红色：用来标记结论
- 绿色：用来标记一级论点
- 蓝色：用来标记二级论点
Kubernetes (k8s) 是一个容器编排平台，允许在容器中运行应用程序和服务。今天学习一下DaemonSet-守护进程。
希望这篇文章能让你不仅有一定的收获，而且可以愉快的学习，如果有什么建议，都可以留言和我交流
专栏介绍
这是这篇文章所在的专栏，欢迎订阅：【深入解析k8s】专栏
简单介绍一下这个专栏要做的事：
主要是深入解析每个知识点，帮助大家完全掌握k8s,以下是已更新的章节
| 序号 | 文章 |
| 第一讲 | 深入解析 k8s：入门指南(一) |
| 第二讲 | 深入解析 k8s：入门指南(二) |
| 第三讲 | 深入解析Pod对象(一) |
| 第四讲 | 深入解析Pod对象(二) |
| 第五讲 | 深入解析无状态服务 |
| 第六讲 | 深入解析有状态服务 |
| 第七讲 | 深入解析控制器 |
|
第八讲 |
深入解析 ReplicaSet |
| 第九讲 | 深入解析滚动升级 |
| 第十讲 | 深入解析StatefulSet(一) |
| 第十一讲 | 深入解析StatefulSet(二) |
1 基础介绍
1.1 概念介绍
Kubernetes是一个容器编排平台，其中DaemonSet是Kubernetes中的一个重要概念。DaemonSet是一种控制器，用于在集群内运行一组Pod，并确保每个节点上都有一个Pod副本在运行。
1.2 常用特性
下面是一些DaemonSet的常用特性：
只在特定的节点上运行Pod：可以使用NodeSelector或者NodeAffinity来限制DaemonSet的Pod只在特定的节点上运行。
根据节点的标签更新Pod：如果在集群中添加或删除了节点，Kubernetes会通过DaemonSet自动添加或删除Pod。同时，也可以通过添加或移除节点标签来更新DaemonSet中的Pod。
确保每个节点只运行一个Pod：可以使用PodAntiAffinity来确保每个节点上只有一个Pod在运行。
限制DaemonSet的Pod数量：可以使用MaxUnavailable和MaxSurge字段来限制DaemonSet的Pod的最大数量和最小数量。
1.3 简单总结
总之，DaemonSet是一种非常有用的控制器，可以确保集群中每个节点上都有一个Pod副本在运行。
它可以自动地根据节点的状态添加或删除Pod，并且可以通过各种方式来控制Pod的位置和数量。
2 工作原理
DaemonSet的工作原理是监听节点的变化，通过监听节点的变化，当新的节点加入集群时，DaemonSet会自动在该节点上创建一个Pod副本。而当节点从集群中删除时，DaemonSet会自动删除该节点上的Pod副本。
这样，DaemonSet保证了集群中每个节点都会运行指定的Pod。有且只有一个pod
2.1 原理介绍
DaemonSet的工作原理如下：
控制器监视节点的状态：DaemonSet控制器会监视集群中的节点状态，一旦有新的节点加入集群，或者节点状态发生变化（例如节点重新启动），控制器就会触发一些操作。
创建Pod：当控制器检测到新节点时，它会创建一个新的Pod，并将其调度到该节点上。控制器还会确保每个节点上只运行一个Pod实例。
更新Pod：如果DaemonSet的配置发生变化，例如更新了镜像版本或者修改了Pod的配置文件，控制器会自动更新每个节点上的Pod实例。
删除Pod：如果节点发生故障或者被删除，控制器会自动删除节点上的Pod实例。
扩容和缩容：DaemonSet还支持扩容和缩容，可以根据需要增加或减少Pod的数量。扩容和缩容的过程与其他控制器类似，控制器会根据指定的副本数和当前的实际Pod数量来调整Pod的数量。
3 使用场景
3.1 场景介绍
DaemonSet用于在集群中运行一组Pod，确保每个节点都有一个Pod在运行。它通常用于运行一些系统级别的服务或者监控应用程序，例如：
日志收集器：DaemonSet可以在每个节点上运行日志收集器，例如Fluentd或者Filebeat，从而收集所有节点的日志数据，并将其发送到中心日志服务器进行存储和分析。
监控代理：DaemonSet可以在每个节点上运行监控代理，例如Prometheus Node Exporter或者cAdvisor，从而收集所有节点的运行状态数据，并将其发送到中心监控服务器进行分析和展示。
网络代理：DaemonSet可以在每个节点上运行网络代理，例如kube-proxy或者Istio Sidecar，从而负责节点之间的网络通信和流量管理。
安全代理：DaemonSet可以在每个节点上运行安全代理，例如Sysdig Falco或者Aqua Security，从而检测所有节点的安全事件，并及时报警或者进行防御。
总之，DaemonSet适用于需要在每个节点上运行一组Pod的场景，可以使集群中的服务更加健壮和可靠。
4 案例讲解
4.1 日志收集
日志收集器是Kubernetes集群中一个重要的组件，它负责在每个节点上运行日志收集器的容器，收集节点和容器的日志数据，并将这些数据发送到集中式的日志系统中。
日志收集方案
- 原生方式：使用
kubectl logs直接在查看本地保留的日志，或者通过docker engine的log driver把日志重定向到文件、syslog、fluentd等系统中。- Sidecar方式：一个POD中运行一个sidecar的日志agent容器，用于采集该POD主容器产生的日志。
- DaemonSet方式：在K8S的每个node上部署日志agent，由agent采集所有容器的日志到服务端。
在Kubernetes集群中使用日志收集器，DaemonSet方式：会使用DaemonSet来确保每个节点上都有一个日志收集器在运行。
下面是一个使用日志收集器的DaemonSet的示例代码：
apiVersion: v1
kind: ConfigMap #资源类型
metadata:
name: fluentd-config
namespace: kube-system
data:
fluent.conf: |
<source>
@type tail
path /var/log/containers/*.log
pos_file /var/log/fluentd-containers.log.pos
time_format %Y-%m-%dT%H:%M:%S.%NZ
tag kubernetes.*
read_from_head true
<parse>
@type json
time_key time
time_format %Y-%m-%dT%H:%M:%S.%NZ
keep_time_key true
</parse>
</source>
<match kubernetes.**>
@type elasticsearch
host elasticsearch.default.svc.cluster.local
port 9200
index_name fluentd
type_name fluentd
logstash_format true
logstash_prefix kubernetes
include_tag_key true
tag_key kubernetes.tag
flush_interval 10s
max_retry_wait 30
disable_retry_limit
</match>
---
apiVersion: apps/v1
kind: DaemonSet #资源类型
metadata:
name: fluentd
namespace: kube-system
labels:
k8s-app: fluentd-logging
spec:
selector:
matchLabels:
k8s-app: fluentd-logging
template:
metadata:
labels:
k8s-app: fluentd-logging
spec:
tolerations:
- key: node-role.kubernetes.io/master
effect: NoSchedule
containers:
- name: fluentd
image: fluent/fluentd-kubernetes-daemonset:v1.6-debian-elasticsearch7-1.1
env:
- name: FLUENT_UID
value: "0"
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
- name: fluentdconfig
mountPath: /fluentd/etc/
resources:
limits:
memory: 512Mi
securityContext:
privileged: true
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
- name: fluentdconfig
configMap:
name: fluentd-config
上面的示例代码中，首先定义了一个名为fluentd-config的ConfigMap，用于存储Fluentd的配置文件。
配置文件中定义了一个名为tail的输入源，它会读取每个容器的日志文件，并使用JSON格式解析日志数据。
配置文件中还定义了一个名为elasticsearch的输出目标，它会将日志数据发送到Elasticsearch中。
接着定义了一个名为fluentd的DaemonSet，它会在每个节点上运行一个fluentd容器。在fluentd容器中，使用了ConfigMap中定义的配置文件，并挂载了/var/log和/var/lib/docker/containers目录，这些目录包含了节点和容器的日志数据。
同时，由于使用了DaemonSet，确保每个节点上都有一个日志收集器在运行，从而提高了集群的可靠性和稳定性。
通过这个示例代码，可以在Kubernetes集群中使用Fluentd作为日志收集器，收集节点和容器的日志数据，并将这些数据发送到集中式的日志系统中。
同时，由于使用了DaemonSet，确保每个节点上都有一个日志收集器在运行，从而提高了集群的可靠性和稳定性。
4.2 监控代理
监控代理是Kubernetes集群中另一个重要的组件，它负责在每个节点上运行监控代理的容器，收集节点和容器的监控数据，并将这些数据发送到集中式的监控系统中。
在Kubernetes集群中使用监控代理，使用DaemonSet来确保每个节点上都有一个监控代理在运行。
下面是一个使用监控代理的DaemonSet的示例代码：
apiVersion: v1
kind: ServiceAccount
metadata:
name: node-exporter
namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: node-exporter
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: node-exporter
subjects:
- kind: ServiceAccount
name: node-exporter
namespace: kube-system
---
apiVersion: apps/v1
kind: DaemonSet #资源类型
metadata:
name: node-exporter
namespace: kube-system
labels:
k8s-app: node-exporter
spec:
selector:
matchLabels:
k8s-app: node-exporter
template:
metadata:
labels:
k8s-app: node-exporter
spec:
serviceAccountName: node-exporter
hostNetwork: true
containers:
- name: node-exporter
image: prom/node-exporter:v1.2.2
args:
- --path.procfs=/host/proc
- --path.sysfs=/host/sys
- --collector.textfile.directory=/var/lib/node-exporter/textfile_collector
ports:
- name: metrics
containerPort: 9100
hostPort: 9100
volumeMounts:
- name: proc-mount
mountPath: /host/proc
readOnly: true
- name: sys-mount
mountPath: /host/sys
readOnly: true
- name: textfile-collector
mountPath: /var/lib/node-exporter/textfile_collector
volumes:
- name: proc-mount
hostPath:
path: /proc
- name: sys-mount
hostPath:
path: /sys
- name: textfile-collector
configMap:
name: node-exporter-textfile-collector
上面的示例代码中，首先定义了一个名为node-exporter的ServiceAccount和一个名为node-exporter的ClusterRoleBinding，用于授权node-exporter在集群中进行操作。
接着定义了一个名为node-exporter的DaemonSet，它会在每个节点上运行一个node-exporter容器。
在node-exporter容器中，使用了--path.procfs和--path.sysfs选项来指定了/proc和/sys目录的路径，这些目录包含了节点和容器的监控数据。
同时，使用了--collector.textfile.directory选项来指定了一个目录，用于存储可以通过文本文件方式收集的监控数据。
node-exporter容器还需要挂载/proc和/sys目录以及用于存储文本文件的目录。
通过这个示例代码，在Kubernetes集群中使用node-exporter作为监控代理，收集节点和容器的监控数据，并将这些数据发送到集中式的监控系统中。
同时，由于使用了DaemonSet，确保每个节点上都有一个监控代理在运行，从而提高了集群的可靠性和稳定性。
4.3 网络代理
网络代理是Kubernetes集群中的重要组件之一，它负责实现节点之间的网络通信和流量管理。
Kubernetes中内置了一个网络代理组件kube-proxy，它使用iptables或者IPVS来实现节点之间的流量转发和负载均衡。
在Kubernetes集群中使用kube-proxy，通常会使用DaemonSet来确保每个节点上都有一个网络代理在运行。
下面是一个使用kube-proxy的DaemonSet的示例代码：
apiVersion: v1
kind: ServiceAccount
metadata:
name: kube-proxy
namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: kube-proxy
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system:node-proxier
subjects:
- kind: ServiceAccount
name: kube-proxy
namespace: kube-system
---
apiVersion: apps/v1
kind: DaemonSet #资源类型
metadata:
name: kube-proxy
namespace: kube-system
labels:
k8s-app: kube-proxy
spec:
selector:
matchLabels:
k8s-app: kube-proxy
template:
metadata:
labels:
k8s-app: kube-proxy
spec:
serviceAccountName: kube-proxy
hostNetwork: true
containers:
- name: kube-proxy
image: k8s.gcr.io/kube-proxy:v1.22.0
command:
- /usr/local/bin/kube-proxy
args:
- --config=/var/lib/kube-proxy/config.conf
securityContext:
privileged: true
volumeMounts:
- name: kube-proxy-config
mountPath: /var/lib/kube-proxy
readOnly: true
- name: xtables-lock
mountPath: /run/xtables.lock
readOnly: false
subPath: xtables.lock
volumes:
- name: kube-proxy-config
configMap:
name: kube-proxy-config
- name: xtables-lock
hostPath:
path: /run/xtables.lock
上面的示例代码中，首先定义了一个名为kube-proxy的ServiceAccount和一个名为kube-proxy的ClusterRoleBinding，用于授权kube-proxy在集群中进行操作。
接着定义了一个名为kube-proxy的DaemonSet，它会在每个节点上运行一个kube-proxy容器。
在kube-proxy容器中，使用了--config选项来指定了配置文件的路径，这个配置文件可以通过一个名为kube-proxy-config的ConfigMap来动态生成。
kube-proxy容器还需要挂载/run/xtables.lock文件来确保在使用iptables或者IPVS时不会发生竞争条件。
通过这个示例代码，在Kubernetes集群中使用kube-proxy作为网络代理，实现节点之间的流量转发和负载均衡。
同时，由于使用了DaemonSet，确保每个节点上都有一个网络代理在运行，从而提高了集群的可靠性和稳定性。
4.4 安全代理
安全代理是Kubernetes集群中另一个重要的组件，它负责在每个节点上运行安全代理的容器，保护节点和容器的网络流量安全，并确保集群中的网络流量只能访问授权的服务和资源。
在Kubernetes集群中使用安全代理，使用DaemonSet来确保每个节点上都有一个安全代理在运行。
下面是一个使用安全代理的DaemonSet的示例代码：
apiVersion: apps/v1
kind: DaemonSet #资源类型
metadata:
name: envoy
namespace: kube-system
labels:
k8s-app: envoy
spec:
selector:
matchLabels:
k8s-app: envoy
template:
metadata:
labels:
k8s-app: envoy
spec:
containers:
- name: envoy
image: envoyproxy/envoy:v1.19.1
ports:
- containerPort: 8080
name: http
- containerPort: 8443
name: https
volumeMounts:
- name: envoy-config
mountPath: /etc/envoy
- name: envoy-tls
mountPath: /etc/envoy-tls
readOnly: true
securityContext:
runAsUser: 10001
terminationGracePeriodSeconds: 30
volumes:
- name: envoy-config
configMap:
name: envoy-config
- name: envoy-tls
secret:
secretName: envoy-tls
上面的示例代码中，首先定义了一个名为envoy-config的ConfigMap，用于存储Envoy的配置文件。
接着定义了一个名为envoy-tls的Secret，用于存储Envoy的TLS证书和私钥。
然后定义了一个名为envoy的DaemonSet，它会在每个节点上运行一个envoy容器。
在envoy容器中，使用了ConfigMap中定义的配置文件，并挂载了/etc/envoy和/etc/envoy-tls目录，这些目录包含了Envoy的配置文件和TLS证书和私钥。
同时，由于使用了DaemonSet，确保每个节点上都有一个安全代理在运行，从而提高了集群的安全性和可靠性。
通过这个示例代码，可以在Kubernetes集群中使用Envoy作为安全代理，保护节点和容器的网络流量安全，并确保集群中的网络流量只能访问授权的服务和资源。
同时，由于使用了DaemonSet，确保每个节点上都有一个安全代理在运行，从而提高了集群的安全性和可靠性。
5 总结
DaemonSet 的主要作用，是让你在 Kubernetes 集群里，运行一个 Daemon Pod。
所以，这个 Pod 有如下三个特征：
这个 Pod 运行在 Kubernetes 集群里的每一个节点（Node）上；
每个节点上只有一个这样的 Pod 实例；
当有新的节点加入 Kubernetes 集群后，该 Pod 会自动地在新节点上被创建出来；而当旧节点被删除后，它上面的该 Pod 也相应地会被回收掉。
Daemon Pod机制听起来很简单，但的意义确实是非常重要的。列举几个例子：
各种网络插件的 Agent 组件，都必须运行在每一个节点上，用来处理这个节点上的容器网络；
各种存储插件的 Agent 组件，也必须运行在每一个节点上，用来在这个节点上挂载远程存储目录，操作容器的 Volume 目录；
各种监控组件和日志组件，也必须运行在每一个节点上，负责这个节点上的监控信息和日志搜集。
总结一下：
DaemonSet 其实是一个非常简单的控制器。在它的控制循环中，只需要遍历所有节点，然后根据节点上是否有被管理 Pod 的情况，来决定是否要创建或者删除一个 Pod。
相比于 Deployment，DaemonSet 只管理 Pod 对象，然后通过 nodeAffinity 和 Toleration 这两个调度器的小功能，保证了每个节点上有且只有一个 Pod。
与此同时，DaemonSet 使用 ControllerRevision，来保存和管理自己对应的“版本”。
这种“面向 API 对象”的设计思路，大大简化了控制器本身的逻辑，也正是 Kubernetes 项目“声明式 API”的优势所在。