Kubernetes DaemonSet 详解：实现节点守护、日志收集与存储插件部署的操作指南

一、DaemonSet 核心概念与典型场景

DaemonSet 是 Kubernetes 中一种特殊的工作负载控制器，其核心设计目标是确保集群中的每一个（或指定的）Node 节点上都运行一个指定的 Pod 副本。它主要服务于那些需要在所有节点上提供基础支撑能力的“守护型”应用。

相较于专注于运行业务应用的 Deployment（长期伺服型）和 Job（批处理型），DaemonSet 的关注点在于节点本身。它的核心功能包括：

• 全节点覆盖：在 DaemonSet 定义匹配的每个 Node 上运行一个 Pod 副本。
• 自动扩展：当新的 Node 加入集群时，DaemonSet 会自动在该节点上创建一个 Pod。
• 节点级别守护：确保诸如网络、存储、日志、监控等基础服务在每个节点上都可用。

为了更好地理解其“一次部署，覆盖所有节点”的特性，我们可以参考下图：

DaemonSet 的典型应用场景

DaemonSet 是构建稳定、可观测的 Kubernetes 集群的基石，常用于部署以下类型的后台支撑服务：

• 运行集群存储 Daemon：例如在每个节点上部署 glusterd、ceph 客户端等，为 Pod 提供分布式存储能力。
• 运行日志收集 Daemon：例如部署 fluentd、logstash 或 Filebeat 等组件，收集每个节点及节点上容器的日志，并统一发送至后端日志平台。
• 运行监控 Daemon：例如部署 node-exporter 来采集节点的硬件和操作系统指标，是构建云原生监控体系的关键一环。
• 部署网络插件：大多数 Kubernetes 集群的 CNI（容器网络接口）插件，如 Calico、Flannel 的 Agent，都是以 DaemonSet 形式部署，为每个节点的 Pod 提供网络连通性。

下图清晰地列举了这些核心应用场景：

二、如何创建 DaemonSet 资源

DaemonSet 的创建与管理与其他 Kubernetes 资源类似，可以使用 kubectl 命令行工具。有两个关键点需要注意：

1. 无副本数概念：DaemonSet 的 Pod 数量由匹配的 Node 数量决定，因此其配置中不需要定义 replicas 字段。
2. 污点容忍：默认情况下，DaemonSet 的 Pod 不能容忍（Toleration）任何污点（Taint）。如果希望 Pod 能在带有污点的节点上运行，必须在 Pod 模板中显式配置容忍。

我们可以使用 kubectl create 命令快速生成一个 DaemonSet 的 YAML 配置模板：

# 通过命令生成 DaemonSet 的 YAML 定义文件
kubectl create ds <daemonset-name> --image=<image-name> -oyaml --dry-run=client > daemonset.yaml

• ds: 是 daemonset 的简写。
• --dry-run=client: 表示只生成 YAML 而不实际创建资源。
• > daemonset.yaml: 将生成的 YAML 输出到文件。

三、DaemonSet YAML 配置详解

下面是一个功能完整的 DaemonSet 示例，以部署 fluentd 日志收集器为例。我们通过注释来详细解释关键配置项。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system # 通常将集群基础组件放在 kube-system 命名空间
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch # 必须与 template.metadata.labels 匹配
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      # 容忍配置（Tolerations）：这是 DaemonSet 能在所有节点运行的关键
      tolerations:
        # 容忍 effect 为 NoSchedule 的污点
        - effect: NoSchedule
          operator: Exists # Exists 表示容忍具有该 effect 的任何污点键
        # 容忍 effect 为 PreferNoSchedule 的污点
        - effect: PreferNoSchedule
          operator: Exists
        # 容忍 effect 为 NoExecute 的污点
        - effect: NoExecute
          operator: Exists
      # 终止宽限期：Pod 被终止前，允许其优雅关闭的等待时间（秒）
      terminationGracePeriodSeconds: 30
      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 # 挂载宿主机日志目录
            - name: varlibdockercontainers
              mountPath: /var/lib/docker/containers
              readOnly: true # 以只读方式挂载容器目录
      volumes:
        - name: varlog
          hostPath: # 使用宿主机路径卷
            path: /var/log
        - name: varlibdockercontainers
          hostPath:
            path: /var/lib/docker/containers

配置核心解析：

• tolerations：此配置使得该 DaemonSet 的 Pod 能够容忍集群节点上常见的所有类型污点（如 node.kubernetes.io/not-ready， node.kubernetes.io/unreachable 等），确保即使在非完全健康的节点上，日志收集等基础服务也能运行。这是深入掌握 Kubernetes 调度与高级编排 的重要知识点。
• terminationGracePeriodSeconds：设置为30秒，当 Pod 需要被删除时，Kubernetes 会先发送 SIGTERM 信号，并等待30秒让进程优雅退出，超时后才会强制终止 (SIGKILL)。这对于有状态处理的守护进程（如正在转发日志的 fluentd）非常重要。
• hostPath 卷：通过将宿主机的 /var/log 和容器目录挂载到 Pod 内，使得 fluentd 能够直接读取节点上的所有日志文件。

通过以上详解，您可以系统地掌握 DaemonSet 从概念、使用场景到具体配置和操作的全部核心知识，并能够将其应用到实际的 Kubernetes 集群运维和建设中。