GKE集群失败CronJob日志访问及配置疑问咨询

1. GKE UI中的日志来源 #

是的，你在GKE UI里看到的代码错误日志，来自GKE默认集成的Cloud Logging（原Stackdriver Logging）。GKE会自动将Pod的标准输出（stdout）、标准错误（stderr）以及容器终止消息等日志数据导出到Cloud Logging中，即便Pod被删除，这些日志依然会被持久化存储，所以你能在UI中找到已删除Pod的错误日志。

2. restartPolicy设为OnFailure时的Pod日志访问问题 #

当Job的restartPolicy设为OnFailure，达到退避限制后，Pod会被终止，并且随着Job的清理流程可能被删除。此时确实无法通过kubectl logs命令直接查看该Pod的日志，因为对应的Pod对象已经不存在于Kubernetes集群中。但如你所见，日志已经被提前采集到Cloud Logging，依然可以通过日志系统访问。

3. 除GKE UI外的日志访问方式 #

除了GKE UI，还有以下几种方式可以访问这些日志：

• gcloud命令行工具：通过过滤条件精准查询目标日志，例如：

  gcloud logging read "resource.type=k8s_pod AND resource.labels.cluster_name=<你的集群名称> AND resource.labels.namespace_name=<你的命名空间> AND labels.k8s-pod/job-name=<目标Job名称>" --format=text
  

  可以根据需求添加时间范围（如timestamp>="2024-05-01T00:00:00Z"）或错误关键词（如textPayload:"error"）来缩小查询范围。
• Cloud Logging API：如果需要自动化或程序化获取日志，可以使用Cloud Logging的REST API或官方客户端库（如Python、Go等）进行查询。
• 查看Job相关事件：虽然不是直接的代码日志，但通过kubectl describe job <目标Job名称>可以查看Job的状态变化事件，辅助确认退避触发的原因；kubectl get jobs -o wide也能查看Job的失败次数、运行状态等关键信息。

你的CronJob配置片段 #

spec:
  concurrencyPolicy: Allow
  failedJobsHistoryLimit: 3
  jobTemplate:
    metadata:
      creationTimestamp: null
    spec:
      template:
        metadata:
          creationTimestamp: null
        spec:
          containers:
          - command:
            - $cmd
            image: $img
            imagePullPolicy: Always
            name: $job_name
            resources: {}
            terminationMessagePath: /dev/termination-log
            terminationMessagePolicy: File
          dnsPolicy: ClusterFirst
          restartPolicy: OnFailure
          schedulerName: default-scheduler
          securityContext: {}
          terminationGracePeriodSeconds: 30
  schedule: 0 4 * * *
  successfulJobsHistoryLimit: 3
  suspend: false

内容的提问来源于stack exchange，提问作者Wilson.Wang