一、应用场景：Kubernetes为什么需要专业日志方案？

在微服务架构下，一个Kubernetes集群可能同时运行数百个Pod。这些Pod的日志分散在多个节点上，传统查看方式需要执行kubectl logs命令逐个查询，效率极低。假设遇到线上故障，开发者要排查请求链路经过的各个服务（如网关→鉴权→订单服务），手动收集日志需要数小时。

ELK Stack（Elasticsearch+Logstash+Kibana+Beats）能实现：

  1. 集中存储：所有容器日志自动汇聚到Elasticsearch
  2. 动态查询：通过Kibana直接搜索关键词（如error_code=500）
  3. 可视化分析：生成请求耗时、错误率统计的仪表盘

二、技术选型：Filebeat为何成为采集核心？

2.1 技术栈组成

本文采用Kubernetes+Filebeat+ELK技术栈，Filebeat负责日志采集，Logstash用于日志格式化，Elasticsearch存储数据，Kibana提供可视化界面。

2.2 Filebeat对比Fluentd
- Filebeat容器内存占用：约30MB
- Fluentd容器内存占用：约150MB 
# 在资源敏感的集群中，Filebeat更适合作为DaemonSet部署

三、实战部署：四步构建完整日志链路

3.1 部署Elasticsearch集群
# helm安装elasticsearch（版本7.17.1）
helm install elasticsearch elastic/elasticsearch \
  --set replicas=3 \
  --set persistence.enabled=true \
  --set resources.requests.memory=4Gi
# 默认生成名为elasticsearch-master的Service
3.2 配置Filebeat DaemonSet
# filebeat-daemonset.yaml核心配置
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: filebeat
spec:
  template:
    spec:
      containers:
      - name: filebeat
        image: elastic/filebeat:7.17.1
        volumeMounts:
        - name: logs
          mountPath: /var/log/containers  # 挂载宿主机容器日志目录
        - name: config
          mountPath: /usr/share/filebeat/filebeat.yml
      volumes:
      - name: logs
        hostPath:
          path: /var/log/containers
      - name: config
        configMap:
          name: filebeat-config

# Filebeat配置(filebeat-config.yml)
filebeat.inputs:
- type: container
  paths: 
    - /var/log/containers/*.log
  processors:
    - add_kubernetes_metadata:  # 自动添加Pod元数据
        host: ${NODE_NAME}
output.logstash:
  hosts: ["logstash-service:5044"]  # 指向Logstash服务
3.3 Logstash管道配置
# logstash.conf 过滤规则示例
input {
  beats { port => 5044 }
}

filter {
  grok {
    match => { "message" => "(?<timestamp>%{TIMESTAMP_ISO8601}) %{LOGLEVEL:level} %{DATA:message}" }
  }
  date {
    match => [ "timestamp", "ISO8601" ]
    target => "@timestamp"
  }
}

output {
  elasticsearch { 
    hosts => ["elasticsearch-master:9200"]
    index => "k8s-logs-%{+YYYY.MM.dd}"  # 按天自动分索引
  }
}
3.4 Kibana可视化仪表板
  1. 进入Management → Index Patterns创建k8s-logs-*模板
  2. 在Discover页面输入查询语句：
kubernetes.namespace:"production" AND level:"ERROR"
  1. 创建折线图展示每小时错误数变化

四、技术细节：躲开这五个踩坑点

4.1 日志多行合并

Java异常堆栈会被拆分为多行，需要特殊处理：

# Filebeat多行配置
processors:
- multiline:
    pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
    match: after
    negate: true
4.2 磁盘空间管理

Elasticsearch默认不会删除旧数据，需设置ILM策略：

PUT _ilm/policy/logs_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_size": "50GB"
          }
        }
      },
      "delete": {
        "min_age": "30d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

五、性能对比：ELK方案的优缺点

5.1 优势
  • 资源开销低：相比Fluentd+EFK组合，CPU占用下降40%
  • 扩展性强：Elasticsearch分片机制支持PB级日志
  • 开发友好：Kibana提供完整的REST API调用链追踪
5.2 劣势
  • 冷数据检索慢：未结合HDFS时查询超过半年的日志延迟明显
  • 配置复杂度高：需要同时维护Filebeat、Logstash、ES三个组件

六、替代方案：什么情况下选择Loki？

如果集群规模较小（节点数<50），可考虑Loki+Grafana组合：

# Loki部署命令（更轻量）
helm install loki grafana/loki --set persistence.enabled=true

优势：部署简单，适合只关注实时日志的场景
劣势：不支持复杂的聚合分析

七、总结

通过本文示例可快速搭建Kubernetes日志中心。ELK Stack虽有一定学习门槛，但其高扩展性和丰富的分析功能在大规模系统中不可替代。建议在测试环境验证日志切割策略后，再逐步推广到生产集群。