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”的优势所在。
