如何通过EFK栈将GCE上Docker容器日志推送至GKE服务

完全存在成熟可落地的技术实现路径，整套链路基于EFK原生能力+GCP基础网络适配即可完成，不需要依赖额外第三方商用工具，具体落地方式如下：

核心流转链路 #

整套日志传输路径为：GCE节点上Docker容器产出的原始日志 -> GCE侧部署的采集端 -> EFK栈做清洗、转发、可选存储 -> GKE侧部署的接收端 -> 目标GKE业务服务

分环节落地配置 #

1. GCE侧采集端部署 #

• 不推荐给每个Docker容器挂Sidecar采集代理，直接在GCE虚拟机宿主机上部署Fluentd（资源敏感场景可以替换为更轻量的Fluent Bit，完全兼容Fluentd插件生态）即可。Docker默认以json-file格式存储容器日志，路径为/var/lib/docker/containers/<容器ID>/<容器ID>-json.log，给采集程序开放该目录的读权限即可完成日志拉取，不需要修改Docker默认日志驱动，没有额外性能损耗。
• 采集阶段提前配置过滤规则：剔除无意义的系统冗余日志，给每条日志追加固定标识字段，比如source: gce-docker、gce_instance_id、app_name，方便后续GKE侧做日志分流路由。
• 提前打通GCE与目标GKE集群的网络：优先将GCE实例划入GKE所在VPC，或配置VPC对等连接，放通对应端口的内网防火墙规则，不要走公网传输日志，延迟高且存在数据泄露风险。

2. EFK栈转发规则配置 #

根据业务规模二选一即可：

• 小规模/无日志留存需求场景：不需要独立部署Elasticsearch做中转，直接在GCE侧Fluentd配置forward输出插件，将日志直推GKE内部署的Fluentd聚合节点。GKE侧的Fluentd聚合服务建议暴露为Internal LoadBalancer类型，仅对内开放访问，GCE侧Fluentd配置片段参考：

<match **>
  @type forward
  send_timeout 60s
  recover_wait 10s
  hard_timeout 60s
  <server>
    name gke-fluentd-aggregator
    host <GKE侧Fluentd内网ILB地址>
    port 24224
  </server>
</match>

• 大规模/需要日志留存检索场景：在中间层部署独立Elasticsearch集群（可直接部署在GCE节点或使用GCP托管ES服务），GCE侧Fluentd先将日志写入ES完成清洗、索引构建，再由GKE侧部署的Fluentd按需拉取对应索引的日志，推送至目标业务服务。如果需要可视化排查日志，直接在EFK栈中部署Kibana对接ES即可，不需要额外搭建运维工具。

3. GKE侧接收配置 #

• 若GKE集群本身已经部署了EFK栈做集群内日志采集，不需要重复部署组件，只需要给现有Fluentd聚合节点新增forward协议的监听端口即可，GCE过来的日志可以和集群内日志做统一处理。
• 接收端必须配置鉴权：要么设置forward共享密钥，要么开启TLS证书加密传输，避免日志明文传输，同时拦截非法写入请求。
• 日志路由规则根据之前追加的标签配置即可：如果需要推送给GKE上的指定业务服务，直接在Fluentd中配置http输出插件调用业务服务的日志接收接口；如果业务服务可用性没有保障，建议先输出到GKE内部部署的Kafka做缓冲，避免服务不可用导致日志丢失。

常见踩坑点 #

• 不要随意修改Docker默认的json-file日志驱动，比如切换为gcplogs驱动，会直接绕开宿主机上部署的Fluentd采集端，导致日志漏采。
• GCE侧的Fluentd必须配置本地文件缓冲，当GKE侧接收端故障不可达时，日志暂存在本地磁盘，链路恢复后自动补发；默认的内存缓冲模式在采集进程重启、节点宕机时会出现日志丢失。
• 防火墙规则仅需要放通Fluentd forward默认监听的24224端口（开启TLS时同步放通对应加密端口），绝对不要把Fluentd接收端口直接暴露到公网。

内容的提问来源于stack exchange，提问作者John Doe