如何在GKE的Logs Explorer中查看容器日志

以下步骤按顺序操作，全部不需要重建集群：

1. 校验集群日志采集配置实际生效状态 #

控制台显示的采集范围可能和实际生效配置不一致，优先通过命令行校验：

• 执行gcloud container clusters describe <你的集群名> --zone <集群所在可用区> --project <所属项目ID>，检查返回结果中loggingConfig.componentConfig.enableComponents数组是否包含WORKLOADS项。如果缺失，直接执行更新命令：

  gcloud container clusters update <你的集群名> --zone <集群所在可用区> --logging=SYSTEM,WORKLOADS
  

• 检查kube-system命名空间下日志采集组件运行状态：执行kubectl get pods -n kube-system | grep -E 'fluent|logging'，正常状态下每个节点对应一个采集Pod（v1.21版本默认是fluentd-gke，部分打了补丁的版本是fluent-bit-gke），所有Pod状态必须为Running。如果存在CrashLoopBackOff、Pending状态的Pod，直接查看对应Pod的运行日志定位问题，常见诱因是老集群ConfigMap版本过旧、节点日志目录挂载权限配置错误。

2. 修复节点服务账号权限缺失问题 #

这是早期创建的v1.21及更低版本GKE集群最常见的故障原因：

• 执行kubectl get nodes -o jsonpath='{.items[0].spec.serviceAccount}'获取节点池使用的服务账号邮箱
• 确认该服务账号已绑定roles/logging.logWriter角色，未绑定的话直接为该账号添加角色绑定即可，权限生效等待1-2分钟，不需要重建节点。如果节点使用自定义服务账号，不要依赖Compute Engine默认服务账号的权限继承，必须显式为自定义SA绑定上述角色。

3. 修复老版本采集组件兼容故障 #

v1.21.10-gke.2000自带的fluentd采集组件存在已知的容器日志路径匹配bug，不需要升级集群版本，直接执行以下操作修复：

• 重启日志采集DaemonSet拉取匹配版本的最新稳定配置：如果是fluentd组件执行kubectl rollout restart daemonset fluentd-gke -n kube-system，如果是fluent-bit组件执行kubectl rollout restart daemonset fluent-bit-gke -n kube-system
• 如果重启后仍无日志，排查节点日志软链异常：老集群长期运行后/var/log/containers/目录下的部分日志软链会指向已被清理的docker日志文件，通过kubectl debug node/<异常节点名> -it --image=ubuntu进入节点调试环境，执行ls /var/log/containers/检查对应业务Pod的日志软链是否有效，存在断裂的话直接在节点上执行systemctl restart kubelet重建软链即可。

4. 修正Logs Explorer查询过滤条件 #

v1.21版本GKE上报的日志字段和v1.22+版本存在差异，工作负载页跳转的容器日志链接默认用适配新版本的过滤规则，会导致老集群日志匹配失败。手动在Logs Explorer输入以下查询语句验证：

resource.type="k8s_container"
resource.labels.cluster_name="<你的集群名>"
severity>=DEFAULT

如果手动查询能返回日志，说明是控制台跳转规则的兼容问题，直接保存自定义查询视图即可，不需要修改集群配置。

所有配置修改完成后，最长等待5分钟即可看到上报的容器日志，不需要重启业务Pod。

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