发布于 由admin

K8s DaemonSet 应用场景：日志收集与监控Agent 部署

各位观众老爷们，大家好！我是你们的老朋友，人称“代码诗人”的程序猿老王。今天咱们不聊风花雪月，也不谈人生理想，咱们就来聊聊 Kubernetes (简称 K8s) 这个云原生时代的当红炸子鸡，以及它内部一个看似不起眼，实则作用巨大的小能手—— DaemonSet。

开场白：K8s 的“影子部队”—— DaemonSet 的华丽登场

大家想象一下，在一个庞大的帝国里，皇帝需要随时了解全国各地的情况，比如哪里发生了天灾，哪里出现了刁民，哪里又出了新的美食。如果皇帝要亲自跑遍全国，那不得累死？所以，皇帝需要遍布全国的“影子部队”，他们无处不在，默默地收集情报，然后汇总给皇帝。

在 K8s 这个“云原生帝国”里，DaemonSet 就扮演着类似“影子部队”的角色。它确保集群中的每个（或某些特定）节点上都运行着一个 Pod 的副本。这个 Pod 可以是日志收集器，可以是监控 Agent，还可以是网络代理等等。总之，它的任务就是收集节点上的信息，然后汇报给“中央指挥部”，也就是我们的监控系统、日志分析平台等等。

第一幕：为什么我们需要 DaemonSet？

你可能会问，既然 K8s 可以通过 Deployment 来部署应用，为什么还需要 DaemonSet 这种东西呢？Deployment 不是也能保证应用的副本数量吗？

答案是：Deployment 关注的是应用的整体可用性，它会在集群中随机调度 Pod，保证应用的副本数达到预期值。而 DaemonSet 关注的是应用的节点覆盖率，它保证集群中的每个节点上都有一个特定 Pod 的副本。

举个例子，假设我们有一个集群，里面有 10 个节点。我们想要收集每个节点上的日志，如果使用 Deployment，它可能会在 3 个节点上运行 3 个 Pod，而在剩下的 7 个节点上则没有任何日志收集器。这样就无法保证我们收集到所有节点的日志信息。

而使用 DaemonSet，我们就可以保证每个节点上都有一个日志收集器运行，从而确保我们收集到所有节点的日志信息。

第二幕：DaemonSet 的应用场景——日志收集与监控 Agent 部署

好了，说了这么多，我们来看看 DaemonSet 在日志收集和监控 Agent 部署方面的具体应用。

1. 日志收集：让黑暗无处遁形

在云原生应用中，日志是宝贵的财富。它可以帮助我们了解应用的运行状态，诊断问题，优化性能，甚至预测风险。但是，由于容器的生命周期短暂，日志很容易丢失。因此，我们需要一个可靠的日志收集方案，将容器的日志收集起来，并集中存储到日志分析平台，比如 Elasticsearch, Kibana, Grafana (俗称 ELK stack)。

使用 DaemonSet 部署日志收集器，比如 Fluentd, Filebeat 等，可以确保每个节点上的容器日志都被收集起来，并转发到日志分析平台。

  • 优势：
    • 全覆盖： 确保所有节点的日志都被收集。
    • 自动伸缩： 当有新的节点加入集群时，DaemonSet 会自动在新的节点上部署日志收集器。
    • 高可用： 如果某个节点上的日志收集器发生故障，DaemonSet 会自动在其他节点上重新部署。
  • 配置示例（Fluentd）：
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
    version: v1
spec:
  selector:
    matchLabels:
      name: fluentd
  template:
    metadata:
      labels:
        name: fluentd
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: fluentd
        image: fluent/fluentd:v1.16-debian-1
        env:
          - name:  FLUENTD_CONF
            value: fluentd.conf
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
        - name: fluentd-config
          mountPath: /fluentd/etc
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers
      - name: fluentd-config
        configMap:
          name: fluentd-config

2. 监控 Agent 部署：掌控全局，防患于未然

监控是保障应用稳定运行的关键。我们需要监控应用的各项指标，比如 CPU 使用率，内存使用率，磁盘 I/O 等等。如果某个指标出现异常，我们需要及时发现并采取措施，防止问题扩大。

使用 DaemonSet 部署监控 Agent，比如 Prometheus Node Exporter, Datadog Agent 等，可以确保每个节点上的指标都被收集起来，并发送到监控系统。

  • 优势：
    • 全面监控： 监控集群中所有节点的状态。
    • 实时告警： 及时发现并告警异常情况。
    • 性能分析： 分析应用的性能瓶颈，优化应用性能。
  • 配置示例 (Prometheus Node Exporter):
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: monitoring
  labels:
    app.kubernetes.io/name: node-exporter
    app.kubernetes.io/component: exporter
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: node-exporter
      app.kubernetes.io/component: exporter
  template:
    metadata:
      labels:
        app.kubernetes.io/name: node-exporter
        app.kubernetes.io/component: exporter
    spec:
      hostNetwork: true
      hostPID: true
      containers:
      - name: node-exporter
        image: prom/node-exporter:v1.6.1
        ports:
        - containerPort: 9100
          hostPort: 9100
          name: metrics
        args:
        - --path.procfs=/host/proc
        - --path.sysfs=/host/sys
        - --collector.filesystem.ignored-mount-points=^/(sys|proc|dev|host)($|/)
        volumeMounts:
        - name: proc
          mountPath: /host/proc
          readOnly: true
        - name: sys
          mountPath: /host/sys
          readOnly: true
        - name: rootfs
          mountPath: /rootfs
          readOnly: true
      volumes:
      - name: proc
        hostPath:
          path: /proc
      - name: sys
        hostPath:
          path: /sys
      - name: rootfs
        hostPath:
          path: /

第三幕：DaemonSet 的进阶玩法——节点选择器 (Node Selector) 和污点容忍 (Tolerations)

DaemonSet 默认会在集群中的所有节点上部署 Pod。但是，在某些情况下，我们可能只想在特定的节点上部署 Pod。比如，我们只想在拥有 GPU 的节点上部署监控 GPU 的 Agent，或者只想在运行特定操作系统的节点上部署日志收集器。

这时，我们就可以使用节点选择器 (Node Selector) 和污点容忍 (Tolerations) 来控制 DaemonSet 的部署范围。

1. 节点选择器 (Node Selector)：精准定位目标节点

节点选择器允许我们根据节点的标签来选择节点。比如，我们可以给拥有 GPU 的节点打上标签 gpu=true，然后在 DaemonSet 的配置中使用节点选择器来指定只在拥有 gpu=true 标签的节点上部署 Pod。

  • 配置示例：
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: gpu-monitor
spec:
  selector:
    matchLabels:
      app: gpu-monitor
  template:
    metadata:
      labels:
        app: gpu-monitor
    spec:
      nodeSelector:
        gpu: "true"  # 只在拥有 gpu=true 标签的节点上部署 Pod
      containers:
      - name: gpu-monitor
        image: your-gpu-monitor-image

2. 污点容忍 (Tolerations)：打破“洁癖”的束缚

污点 (Taint) 是一种节点属性，可以用来排斥某些 Pod 在节点上运行。比如，我们可以给 Master 节点打上污点 node-role.kubernetes.io/master:NoSchedule，这样除了容忍该污点的 Pod 之外，其他 Pod 都不会被调度到 Master 节点上。

DaemonSet 默认不会容忍任何污点。如果想要让 DaemonSet 在拥有污点的节点上运行，我们需要在 DaemonSet 的配置中添加污点容忍 (Tolerations)。

  • 配置示例：
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: my-daemonset
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule  # 容忍 node-role.kubernetes.io/master:NoSchedule 污点
      containers:
      - name: my-container
        image: your-image

第四幕：DaemonSet 的最佳实践——资源限制 (Resource Limits) 和健康检查 (Health Checks)

DaemonSet 虽然方便，但是如果使用不当，也可能导致问题。比如，如果 DaemonSet 占用了过多的资源，可能会影响其他应用的运行。如果 DaemonSet 发生故障，可能会导致日志收集或监控中断。

因此，我们需要遵循一些最佳实践，来确保 DaemonSet 的稳定运行。

1. 资源限制 (Resource Limits)：勒紧腰带，避免资源浪费

我们需要为 DaemonSet 设置资源限制，比如 CPU 和内存的限制。这样可以防止 DaemonSet 占用过多的资源，影响其他应用的运行。

  • 配置示例：
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: my-daemonset
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: your-image
        resources:
          limits:
            cpu: 100m
            memory: 256Mi
          requests:
            cpu: 50m
            memory: 128Mi

2. 健康检查 (Health Checks)：时刻关注，及时发现问题

我们需要为 DaemonSet 配置健康检查，比如 livenessProbe 和 readinessProbe。这样可以确保 DaemonSet 能够正常运行，并在发生故障时及时重启。

  • 配置示例：
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: my-daemonset
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: your-image
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /readyz
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10

第五幕：总结与展望——DaemonSet 的未来之路

总而言之，DaemonSet 是 K8s 中一个非常重要的资源对象。它可以确保集群中的每个节点上都运行着一个特定 Pod 的副本，非常适合用于部署日志收集器、监控 Agent 等需要节点覆盖的应用。

随着云原生技术的不断发展，DaemonSet 的应用场景也会越来越广泛。比如，在边缘计算场景中，我们可以使用 DaemonSet 来部署边缘节点上的应用，实现边缘计算的自动化管理。

结尾彩蛋：一些幽默的小技巧

  • 巧用表情： 在文章中适当插入表情，可以增加文章的趣味性，让读者更容易理解。比如，在介绍 DaemonSet 的优势时，可以使用 👍 或 🎉 表情。在介绍 DaemonSet 的缺点时，可以使用 😥 或 🤦 表情。
  • 使用拟人化： 将 K8s 的组件拟人化，可以更容易让读者理解。比如，可以将 DaemonSet 比喻成“影子部队”，将节点比喻成“士兵”。
  • 制造悬念： 在文章中适当制造悬念，可以吸引读者继续阅读。比如，在介绍 DaemonSet 的进阶玩法时，可以先卖个关子，让读者猜一猜。
  • 自我调侃： 偶尔自我调侃一下，可以拉近与读者的距离。比如，可以说自己是个“代码诗人”，或者说自己是个“程序猿老王”。

希望这篇文章能够帮助大家更好地理解 DaemonSet 的应用场景和最佳实践。如果大家有任何问题，欢迎在评论区留言，我们一起讨论学习！ 谢谢大家！ 😊

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注