K8s生产级日志收集实战手册：从基础到高阶架构

Kubernetes生产级日志收集实战手册：从基础到高阶架构

本文基于50+生产集群日志管理经验，为你解析从基础搭建到企业级优化的全链路方案。以下是经过大规模验证的日志架构设计指南。

---

一、日志收集核心架构选型

1.1 典型方案对比

方案	适用场景	吞吐量	成本	维护复杂度
EFK Stack	全文检索场景	高	高	中
Loki Stack	大规模日志检索	极高	低	低
ELK Stack	复杂数据处理	中	高	高
Splunk	企业级分析	极高	极高	低

选型建议：

• 中小集群选择EFK
• 日日志量超TB级用Loki
• 有安全审计需求考虑Splunk

---

二、EFK生产级部署方案

2.1 Elasticsearch高可用集群

# es-cluster.yaml
apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: prod-logging
spec:
  version: 8.13.0
  nodeSets:
  - name: hot
    count: 3
    config:
      node.roles: ["data_hot", "ingest"]
    volumeClaimTemplates:
    - metadata:
        name: elasticsearch-data
      spec:
        storageClassName: ceph-rbd
        resources:
          requests:
            storage: 1Ti
  - name: warm
    count: 2
    config:
      node.roles: ["data_warm"]

关键配置：

• 分hot/warm/cold三层存储
• 每个节点分配独立存储卷
• 设置最少3个主节点

2.2 Fluentd优化配置

# fluentd-configmap.yaml
<source>
  @type tail
  path /var/log/containers/*.log
  pos_file /var/log/fluentd-containers.log.pos
  tag k8s.*
  <parse>
    @type json
    time_key time
    time_format %Y-%m-%dT%H:%M:%S.%NZ
  </parse>
</source>

<filter k8s.**>
  @type record_transformer
  enable_ruby true
  <record>
    hostname "#{Socket.gethostname}"
    pod_name ${record.dig("kubernetes", "pod_name")}
    namespace ${record.dig("kubernetes", "namespace_name")}
  </record>
</filter>

<match k8s.**>
  @type elasticsearch
  host elasticsearch-prod
  port 9200
  scheme https
  ssl_verify false
  logstash_format true
  buffer_chunk_limit 32MB
  buffer_queue_limit 4096
  flush_interval 10s
  retry_max_times 5
  <secondary>
    @type file
    path /var/log/fluentd-fallback
  </secondary>
</match>

调优参数：

• 增大缓冲区防止日志丢失
• 添加备用存储应对ES故障
• 提取关键字段加速检索

---

三、Loki超大规模方案

3.1 分布式部署架构

# 使用Helm部署
helm upgrade --install loki grafana/loki-stack \
  --set loki.persistence.enabled=true \
  --set loki.persistence.storageClassName=ceph-rbd \
  --set loki.persistence.size=5Ti \
  --set promtail.enabled=true \
  --set grafana.enabled=true

3.2 日志标签规范

# promtail-config.yaml
scrape_configs:
- job_name: kubernetes-pods
  kubernetes_sd_configs:
  - role: pod
  relabel_configs:
  - source_labels: [__meta_kubernetes_namespace]
    target_label: namespace
  - source_labels: [__meta_kubernetes_pod_name]
    target_label: pod
  - source_labels: [__meta_kubernetes_pod_container_name]
    target_label: container
  - action: replace
    replacement: $1
    separator: /
    source_labels:
    - __meta_kubernetes_pod_uid
    - __meta_kubernetes_pod_container_name
    target_label: __path__

标签规则：

• 必选标签：namespace/pod/container
• 业务标签：app/env/team
• 避免使用高频变化字段作为标签

---

四、生产环境特别注意事项

4.1 日志生命周期管理

# Elasticsearch ILM策略
PUT _ilm/policy/logs-policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {"rollover": {"max_size": "50gb"}}
      },
      "warm": {
        "min_age": "1d",
        "actions": {"allocate": {"include": {"data_tier": "warm"}}}
      },
      "delete": {
        "min_age": "7d",
        "actions": {"delete": {}}
      }
    }
  }
}

4.2 安全防护配置

# Elasticsearch安全配置
xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.authc:
  anonymous:
    roles: monitoring_user
    authz_exception: false

4.3 监控告警体系

# Prometheus监控规则
- alert: LogBackpressure
  expr: rate(fluentd_output_status_retry_count[5m]) > 10
  for: 10m
  labels:
    severity: critical
  annotations:
    summary: "日志队列积压 ({{ $labels.pod }})"
    description: "Fluentd 输出重试次数持续升高"

# Grafana看板指标
- 日志摄入速率
- 存储使用率
- 查询响应时间
- 错误日志占比

---

五、高级运维技巧

5.1 日志采样策略

<filter k8s.**>
  @type sample
  rate 0.1
  invert true
  key_match ^(WARN|ERROR)
</filter>

5.2 敏感信息过滤

<filter k8s.**>
  @type grep
  <exclude>
    key message
    pattern /password|token|secret/
  </exclude>
</filter>

5.3 多集群日志聚合

# Fluentd跨集群配置
<match **>
  @type forward
  <server>
    name central-logging
    host 10.10.10.100
    port 24224
  </server>
  <secondary>
    @type file
    path /var/log/fluentd/backup
  </secondary>
</match>

---

六、灾难恢复预案

1. 日志断点续传：

# 手动重置采集位置
find /var/log/fluentd -name "*.pos" -exec truncate -s 0 {} \;

2. ES数据快照：

PUT _snapshot/logs_backup
{
  "type": "s3",
  "settings": {
    "bucket": "es-backup",
    "region": "us-east-1"
  }
}

POST _snapshot/logs_backup/snapshot_1?wait_for_completion=true

3. 紧急日志导出：

# 从S3直接下载原始日志
aws s3 sync s3://logs-bucket/2024-05 /tmp/emergency_logs

---

通过这套方案，我们成功实现了：

• 日均20TB日志的稳定处理
• 日志查询响应时间<2秒（P99）
• 存储成本降低65%

建议每季度进行一次日志系统健康检查，重点验证备份完整性、安全策略有效性、存储容量规划三个核心项。当遇到日志堆积时，优先检查输出插件状态、网络带宽、存储IOPS三个关键瓶颈点。