上一篇【第75篇】PrometheusGrafana——K8s监控体系搭建完全指南让集群“看得见“下一篇【第77篇】Istio——服务网格的入门与实践摘要上篇讲了监控看指标。但排障时指标告诉你出问题了日志告诉你为什么。kubectl logs只能看单个Pod而且Pod一删、节点一飘日志就没了——生产环境必须集中收集。日志收集有两大主流方案EFKFilebeat→Elasticsearch→Kibana老牌强者功能全但吃内存和PLGPromtail→Loki→Grafana后起之秀轻量省钱按标签索引。这篇文章讲清日志收集的三种部署模式对比两套方案帮你选型。一、为什么不能只靠kubectl logs1.1 痛点【kubectl logs 的局限】 • 只能看当前还在跑的Pod的日志 • Pod被删/重建 → 旧日志没了 • 跨多个Pod查日志? 得一个个logs(累死) • 节点漂移 → 日志跟着Pod走追不上 • 不能全文检索、不能聚合分析 → 生产需要: 集中存储 全文检索 长期保留要点日志和指标上篇并称可观测性双璧——指标看趋势和告警日志看细节和根因。集中日志系统的价值所有Pod的日志汇聚一处、可全文搜索、跨Pod关联、长期留存Pod没了日志还在。二、日志收集的部署模式2.1 三种模式【K8s 日志收集三种模式】 模式1: DaemonSet (最常用) ┌─────────────────────────────────┐ │ Node1: [日志Agent Pod] │ ← 每个Node一个Agent │ 读取 /var/log/containers/*.log │ 读节点上所有容器日志 │ Node2: [日志Agent Pod] │ └─────────────────────────────────┘ 优点: 资源省(每节点1个)、无侵入 缺点: 只能读标准输出(落盘的读不到) 模式2: Sidecar (每个Pod带日志容器) ┌─────────────────────────────────┐ │ Pod: [app] [log-agent-sidecar] │ ← 每个Pod一个 └─────────────────────────────────┘ 优点: 能读任意日志文件(包括落盘) 缺点: 资源翻倍(每个Pod多一个容器) 模式3: 直写 (应用直接发到远端) ┌─────────────────────────────────┐ │ App 代码里直接调日志API发ES/Loki │ └─────────────────────────────────┘ 优点: 最灵活 缺点: 侵入应用代码、耦合模式资源侵入能读落盘日志推荐DaemonSet低无❌ 仅stdout✅ 首选Sidecar高有✅特殊需求直写中强耦合✅不推荐三、EFK方案3.1 架构【EFK: Filebeat → Elasticsearch → Kibana】 容器标准输出 │ (DaemonSet的Filebeat读取) ▼ ┌──────────────────────────────────┐ │ Elasticsearch │ │ • 全文检索引擎(倒排索引) │ │ • 存所有日志(索引按时间分片) │ │ • 功能极强但吃内存(堆内存大户) │ └──────────────────────────────────┘ │ 查询 ▼ ┌──────────────────────────────────┐ │ Kibana │ │ • 日志搜索/可视化界面 │ │ • 强大的聚合分析、仪表盘 │ └──────────────────────────────────┘ Filebeat: 轻量采集器(现在多用Fluent Bit替代Filebeat)# Fluent Bit 配置(DaemonSet模式, 读容器日志)input:-name:tailpath:/var/log/containers/*.logparser:dockeroutput:-name:eshost:elasticsearch:9200index:k8s-logs四、PLG方案4.1 架构【PLG: Promtail → Loki → Grafana】 容器标准输出 │ (Promtail DaemonSet读取) ▼ ┌──────────────────────────────────┐ │ Loki │ │ • 只索引标签(namespace/pod名) │ │ • 日志原文压缩存储(不建全文索引) │ │ • 超省资源! 比ES便宜一个量级 │ └──────────────────────────────────┘ │ 查询(用和Prometheus一样的Label语法) ▼ ┌──────────────────────────────────┐ │ Grafana │ │ • 和Prometheus共用一套界面 │ │ • 指标日志一个面板看(关联强) │ └──────────────────────────────────┘要点PLG/Loki的核心创新是**“只索引标签、不索引全文”**。Elasticsearch对每个日志字段建倒排索引强大但巨费资源Loki只给日志打标签namespace/pod/container原文压缩存对象存储。查的时候先用标签缩小范围再在结果里grep。这让它成本极低常说Loki是Elasticsearch的1/10成本而且和Prometheus/Grafana天然一体——指标和日志在同一面板关联排障体验极佳。五、EFK vs PLG 对比5.1 怎么选维度EFK (Elasticsearch)PLG (Loki)索引方式全文倒排索引仅标签索引资源消耗高(堆内存大户)低(压缩存储)全文搜索✅ 极强⚠️ 标签内grep成本高低(约1/10)查询语言KQL/DSLLogQL(类PromQL)与监控集成弱(独立Kibana)强(同Grafana)适合需要复杂日志分析/审计大多数K8s日志场景【选型口诀】 已经在用Elasticsearch生态 / 需要复杂日志分析审计? → EFK 要省钱 / 已经在用PrometheusGrafana / 日志主要用来排障? → PLG (Loki) ← 大多数K8s场景的推荐5.2 一条LogQL示例# 查prod命名空间里error日志{namespaceprod}|error# 查nginx pod里5xx响应{namespaceprod,containernginx}| 500 # 统计某接口QPSsum(count_over_time({appmy-app}|GET /api[1m]))本篇小结日志是排障的显微镜集中收集才能跨Pod关联、长期留存。三种部署模式DaemonSet每节点一个Agent无侵入首选、Sidecar能读落盘但资源翻倍、直写强耦合应用不推荐。EFKFilebeat/Fluent Bit→Elasticsearch→Kibana功能强、全文搜索无敌但Elasticsearch是内存大户、成本高。PLGPromtail→Loki→Grafana只索引标签不索引全文成本约ES的1/10且和Prometheus共用Grafana指标日志关联强——适合绝大多数K8s场景。选型要复杂分析用EFK要省钱省心用PLG。下篇讲服务网格——Istio。上一篇【第75篇】PrometheusGrafana——K8s监控体系搭建完全指南让集群“看得见“下一篇【第77篇】Istio——服务网格的入门与实践