Kubernetes中JSON日志兼顾ES存储与kubectl可读的最佳实践咨询

方案可行性评估 #

你当前的双容器Sidecar方案功能上可以满足需求，但不属于生产环境的最佳实践，存在几个明显的弊端：

• 额外的资源开销：每个Pod多运行一个Sidecar容器，大规模部署场景下会浪费大量集群CPU、内存资源
• 本地磁盘开销：日志先写入emptyDir再被Sidecar读取，增加了节点IO消耗，同时emptyDir占用节点本地存储，容量受限且有日志丢失风险
• 运维复杂度提升：查看日志需要指定-c tail-logs参数，不符合常规使用习惯，新成员上手成本高

更简单的实现方案 #

推荐采用行业主流的「JSON输出+客户端解析」方案，完全不需要修改集群采集组件，也不需要加Sidecar：

1. 应用直接将标准JSON格式日志输出到stdout/stderr，不需要写本地日志文件
2. 集群采集组件（不管是Fluentd还是Fluent Bit）直接采集stdout的JSON内容，解析后展开字段写入Elasticsearch，不会嵌套到msg字段
3. 本地执行kubectl logs时，通过管道传给jq工具做格式化即可得到可读文本：

   kubectl logs -f <pod-name> | jq
   

如果团队希望省略jq步骤，也可以在应用中增加日志格式切换开关，开发环境默认输出文本格式，生产环境输出JSON格式即可。

Fluentd原生支持方案 #

不需要更换为Fluent Bit，仅需要修改集群Fluentd的采集配置即可满足需求，无需改动应用侧部署逻辑：

1. 在Fluentd的配置中新增JSON解析Filter，匹配带有自定义Annotation（比如log-format: json）的Pod日志：

   <filter kubernetes.**>
     @type parser
     key_name log
     reserve_data true
     remove_key_name_field true
     <parse>
       @type json
     </parse>
     <annotation>
       @type kubernetes
       key log-format
       value json
     </annotation>
   </filter>
   

2. 你的应用Deployment只需要加对应Annotation即可触发JSON解析：

   template:
     metadata:
       annotations:
         kubernetes.io/log-format: json
   

这个方案完全不需要修改应用逻辑，也不需要加Sidecar，同时满足两个核心需求。

内容的提问来源于stack exchange，提问作者Itai Spiegel