【K8s运维】第十一章 日志方案1：分布式日志架构与Loki/EFK对比
1. 课程衔接：上一节内容回顾
上一小节完成了Harbor镜像仓库的部署，基于NFS存储类实现了持久化存储供给，同时提及了内部数据泄露漏洞的相关风险：需扫描内部出现的漏洞，根据漏洞等级判断是否修复，无需过度担忧但也不可忽视安全风险。在与国企配合的项目中漏洞修复要求更严格，普通企业可根据漏洞对安全性的实际影响判断是否处理。
2. 为什么需要分布式日志系统？
原生kubectl logs仅能查询单个Pod的日志，存在明显痛点：
- 面对上百个Pod的业务场景时，逐个执行查询命令效率极低
- Pod是动态调度的弹性状态，就算集群有100个节点，Pod数量也不会固定，可能不断销毁重建，查询首批Pod时首批Pod可能已销毁，日志丢失需要重复查询
- 自定义脚本循环采集日志的代价过高，且不具备日志筛选、检索能力
因此需要分布式日志系统，核心架构逻辑为：
- 每个Node节点部署日志采集Agent，采集节点上所有容器的日志
- 日志统一存储到共享存储或专用存储中
- 通过前端UI提供统一查询、检索、筛选能力，避免逐个Pod查询的麻烦
同时日志系统需要支持多业务、多Pod类型的日志分类存储，否则日志文件杂乱无法检索。
3. 传统日志方案：ELK/EFK架构
3.1 方案定义
- EFK：Fluentd/Fluent Bit（日志采集） + Elasticsearch（存储） + Kibana（前端UI）
- ELK：Logstash（日志采集） + Elasticsearch（存储） + Kibana（前端UI）
3.2 优势
- 功能完善：行业沉淀时间长，早期由开源社区维护，现已被阿里巴巴收购，部分高级功能收费
- 案例丰富：尤其在高并发CDN场景中应用广泛，比如全国/全球IDC机房的缓存服务器（Squid、Varnish等）日志分散，可通过Logstash采集到Elasticsearch，最终通过Kibana实现统一查询、日志统计，淘宝、京东等高并发业务背后均有CDN+日志系统的支持
- 可视化工具Kibana功能成熟，索引结构完善
3.3 劣势（重点：以下劣势为K8s云原生场景下的劣势，传统IDC场景下可忽略）
- 资源消耗大：所有核心组件均由Java编写，存在JVM overhead，内存消耗高。对比测试显示：EFK/ELK内存消耗普遍在几百MB到1GB以上，而Loki内存消耗普遍在两位数MB级，差一个数量级。在K8s场景下，每个Node都需要部署采集组件，资源消耗被放大，比如100个Node需要部署100个采集组件，会占用大量Node资源，影响业务Pod运行
- 灵活性差：组件定型程度高，除了Fluentd有插件扩展外，其他组件二次开发难度大，难以适配K8s的CRD、自定义调度器等云原生特性
- 学习曲线陡：Elasticsearch有复杂的分片、索引概念，需要投入较长时间学习掌握
- 传统IDC场景下劣势不存在：单个IDC机房部署1-2套EFK即可覆盖所有服务器日志采集，资源消耗相对于整个机房的服务器资源来说可忽略，属于无足轻重的问题。
4. 云原生日志方案：Loki（洛基）
4.1 方案定位
Loki是Grafana Labs开发的云原生日志收集工具，专门为Kubernetes场景设计，完全适配云原生特性，是目前K8s场景下最受认可的日志方案，属于第一梯队。ELK/EFK推出时间早于Kubernetes，不属于云原生方案。
4.2 核心架构（与传统日志方案逻辑一致，组件对应）
- 采集端：Promtail，对应EFK的Fluentd/Logstash，负责采集Node节点上所有容器的日志，推送给Loki存储
- 存储端：Loki，对应Elasticsearch，基于内存数据结构存储日志，无需预先建立索引，同时支持日志的存储、检索
- 前端UI：直接复用同团队的Grafana，原生适配Loki，无需额外开发
4.3 优势
- 资源消耗低：比EFK/ELK低一个数量级，大规模K8s集群下优势更明显，不会过度占用Node资源
- 灵活性强：原生支持K8s的CRD、自定义调度器等云原生特性，可适配K8s的各种业务场景
- 搜索速度快：基于内存数据结构，无索引开销，查询效率高
- 学习曲线平缓：没有Elasticsearch复杂的索引、分片概念，上手快
4.4 劣势
- 行业案例相对较少：推出时间较EFK短，目前还没有成为行业默认方案，但已经在大量测试和落地
- 扩展性相对EFK弱：针对非K8s的多数据源场景支持不如EFK丰富，但完全满足K8s日志收集的需求
5. Loki与EFK/ELK详细对比
| 对比维度 | Loki | EFK/ELK |
|---|---|---|
| 存储方式 | 基于列式表的内存数据结构，无需索引，查询速度快 | 基于Elasticsearch建立索引，查询相对较慢，有索引开销 |
| 日志采集处理 | 采用Promtail，专为Loki设计，性能与Fluentd/Logstash相当，对接Loki后整体性能更优 | 采用Fluentd/Fluent Bit/Logstash，需要对接Elasticsearch，存在额外的索引、序列化开销 |
| 扩展性 | 扩展性相对较弱，但完全满足K8s日志收集场景 | 扩展性强，支持多种数据源，插件丰富 |
| 可视化工具 | 采用Grafana，成熟稳定，与Loki原生适配 | 采用Kibana，功能丰富，索引结构完善 |
| 学习成本 | 学习曲线平缓，概念简单，易上手 | 学习曲线陡，需要掌握Elasticsearch的分片、索引等复杂概念 |
| 资源消耗 | 低，内存消耗普遍在两位数MB级 | 高，内存消耗普遍在几百MB到1GB以上 |
AI 总结
本节课围绕Kubernetes集群的日志方案展开，首先分析了原生kubectl logs命令在多Pod、动态调度场景下的痛点，引出分布式日志系统的需求；随后详细介绍了传统日志方案ELK/EFK的架构、优劣势，重点指出其在K8s场景下资源消耗高、灵活性差的不足；最后重点讲解了云原生日志方案Loki的架构、核心优势以及与EFK的详细对比，明确Loki是当前K8s场景下日志方案的第一梯队选择，适合云原生环境的日志收集、检索需求。