上一篇【第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——服務網格的入門與實踐