3、日志采集基础：如何通过 Sidecar 或 DaemonSet 采集 CoreDNS 日志到 ELK/Loki

CoreDNS 作为 Kubernetes 集群的 DNS 核心组件，其日志是排查服务发现异常、域名解析超时、缓存污染等问题的第一手数据。在生产环境中，CoreDNS 通常以 Deployment 形式运行，日志采集方案需兼顾资源开销、采集可靠性与运维复杂度。本章聚焦两种主流采集模式：Sidecar（每个 Pod 内伴生采集器）与 DaemonSet（节点级采集代理），并分别给出输出到 ELK（Elasticsearch + Logstash + Kibana）与 Loki 的完整链路。

3.1 采集架构总览

下图展示了两种采集模式在 Kubernetes 集群中的部署位置与数据流向。Sidecar 模式将采集器注入 CoreDNS Pod 内，与容器共享日志文件；DaemonSet 模式则在每个节点上运行采集代理，通过挂载宿主机路径或 CRI 接口获取日志。

3.2 Sidecar 模式：精准采集，隔离性强

Sidecar 模式在 CoreDNS 的 Deployment 定义中额外添加一个日志采集容器（如 Filebeat、Fluent Bit），两个容器共享一个 emptyDir 卷。CoreDNS 容器将日志写入共享卷，采集容器读取并转发。此模式适用于对日志格式有定制需求、或需要避免节点级采集器干扰的场景。

3.2.1 部署示例：CoreDNS + Filebeat Sidecar

以下 YAML 片段展示了在 CoreDNS Deployment 中注入 Filebeat Sidecar 的核心配置：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: coredns
  namespace: kube-system
spec:
  template:
    spec:
      containers:
      - name: coredns
        image: coredns/coredns:1.11.1
        args: [ "-conf", "/etc/coredns/Corefile" ]
        volumeMounts:
        - name: log-volume
          mountPath: /var/log/coredns
      - name: filebeat
        image: docker.elastic.co/beats/filebeat:8.12.0
        args: [ "-c", "/etc/filebeat.yml", "-e" ]
        volumeMounts:
        - name: log-volume
          mountPath: /var/log/coredns
          readOnly: true
        - name: filebeat-config
          mountPath: /etc/filebeat.yml
          subPath: filebeat.yml
      volumes:
      - name: log-volume
        emptyDir: {}
      - name: filebeat-config
        configMap:
          name: filebeat-config

3.2.2 Filebeat 配置要点

Filebeat 的配置文件需指定输入源为共享卷中的日志文件，并设置多行合并规则以处理 CoreDNS 的堆栈日志：

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/coredns/*.log
  multiline.pattern: '^\d{4}-\d{2}-\d{2}'
  multiline.negate: true
  multiline.match: after

output.elasticsearch:
  hosts: ["http://elasticsearch:9200"]
  index: "coredns-%{+yyyy.MM.dd}"

# 若输出到 Loki，则使用 output.logstash 或 elasticsearch 的 Loki 插件

3.3 DaemonSet 模式：零侵入，运维简单

DaemonSet 模式在每个节点上部署一个日志采集代理（如 Fluentd、Logstash），通过挂载宿主机 /var/log/pods 或 /var/log/containers 路径读取所有 Pod 的日志。CoreDNS 的日志文件位于 /var/log/pods/kube-system_coredns-* 下，采集器通过路径匹配或 Kubernetes 元数据过滤获取。

3.3.1 部署示例：Fluentd DaemonSet

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: fluentd
  template:
    metadata:
      labels:
        name: fluentd
    spec:
      containers:
      - name: fluentd
        image: fluent/fluentd-kubernetes-daemonset:v1.16-debian-elasticsearch
        env:
        - name: FLUENT_ELASTICSEARCH_HOST
          value: "elasticsearch"
        - name: FLUENT_ELASTICSEARCH_PORT
          value: "9200"
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: dockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: dockercontainers
        hostPath:
          path: /var/lib/docker/containers

3.3.2 Fluentd 配置：过滤 CoreDNS 日志

在 Fluentd 的配置中，使用 @label 和 kubernetes_metadata 插件过滤出 CoreDNS 的日志流：

<source>
  @type tail
  path /var/log/containers/coredns-*.log
  pos_file /var/log/fluentd-coredns.pos
  tag kubernetes.coredns.*
  format json
  read_from_head true
</source>

<filter kubernetes.coredns.*>
  @type kubernetes_metadata
</filter>

<match kubernetes.coredns.*>
  @type elasticsearch
  host "#{ENV['FLUENT_ELASTICSEARCH_HOST']}"
  port "#{ENV['FLUENT_ELASTICSEARCH_PORT']}"
  index_name coredns
  <buffer>
    flush_interval 5s
  </buffer>
</match>

3.4 两种模式对比与选型

3.5 输出到 ELK 与 Loki 的差异

无论采用哪种采集模式，最终日志都会发送到后端存储。ELK 与 Loki 在日志存储、查询方式上存在本质区别，直接影响采集器的输出配置：

3.6 输出到 Loki 的采集配置示例（Promtail）

若选择 Loki 作为日志后端，推荐使用 Promtail 作为采集器。以下为 Promtail 的 Sidecar 配置片段，直接输出到 Loki：

# promtail-config.yaml
scrape_configs:
- job_name: coredns
  static_configs:
  - targets: [localhost]
    labels:
      job: coredns
      namespace: kube-system
      __path__: /var/log/coredns/*.log
  pipeline_stages:
  - regex:
      expression: '^(?P<time>\S+)\s+(?P<level>\S+)\s+(?P<msg>.*)'
  - labels:
      level:
  - timestamp:
      source: time
      format: RFC3339

clients:
- url: http://loki:3100/loki/api/v1/push

3.7 日志采集的可靠性保障

无论采用 Sidecar 还是 DaemonSet，都需要考虑以下可靠性措施：

• 日志轮转兼容：CoreDNS 默认不轮转日志，建议在 Corefile 中配置 log 插件的 rotate 参数，或依赖容器运行时（如 containerd）的日志轮转策略。采集器需支持 copytruncate 或 inode 跟踪。
• 断点续传：Filebeat 和 Fluentd 均支持 registry / position 文件，记录已读取的偏移量。确保这些文件存储在持久卷或 hostPath 上，避免 Pod 重启后重复采集。
• 背压与缓冲：当后端（Elasticsearch / Loki）不可用时，采集器应具备本地缓冲能力。Filebeat 使用 queue.mem，Fluentd 使用 buffer 插件，Promtail 使用 client 的 buffer 配置。
• 监控采集器自身：为采集器暴露 Prometheus 指标（如 filebeat_input_events、fluentd_output_status_buffer_queue_length），纳入可观测性体系。

3.8 本章小结