Kubernetes находит журналы неудачной работы cronjob

Означает ли это, что если для параметра restartPolicy моего задания установлено значение OnFailure, соответствующий модуль будет удален в случае сбоя, и не будет возможности проверить журналы модуля?

Как правило, все журналы, связанные с модулем, будут потеряны после удаления модуля. Причина проста: по умолчанию все журналы сохраняются в томе модуля, и эти тома удаляются после удаления модуля, как указано в официальной документации kubernetes.

Файлы на диске в модуле являются эфемерными, что создает некоторые проблемы для нетривиальные приложения при работе в подах. Одна проблема - потеря файлов при сбое модуля. kubelet перезапускает контейнер, но с чистым состоянием.

Я нашел журналы в GKE, потому что у него есть собственная система ведения журналов, или есть другие действия, которые я могу предпринять, чтобы получить доступ к этим журналам?

Облачные провайдеры, такие как Google Cloud Platform (GCP), по умолчанию включают такие функции, как ведение журнала и мониторинг, чтобы облегчить работу, и благодаря этой функции по умолчанию вы можете видеть свои журналы в пользовательском интерфейсе.

Если вы хотите получить доступ к этим журналам другим способом, вы можете настроить сервер журналов для своего кластера kubernetes, а также хранить эти журналы в постоянных томах, поскольку PV доступны даже после удаления ваших модулей.

CronJob имеет значение истории:

.spec.successfulJobsHistoryLimit и .spec.failedJobsHistoryLimit

Установите их на количество успешных/неудачных заданий, которые вы хотите сохранить, и Kubernetes сохранит столько же неудачных или успешных модулей. Обычно я оставляю 3 неудачных, 1 успешную, но если отладка, я оставлю больше (6 неудачных, 3 успешных)

Отредактированная версия вашего yaml

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  concurrencyPolicy: Allow
  failedJobsHistoryLimit: 3
  jobTemplate:
    metadata:
      creationTimestamp: null
    spec:
      template:
        metadata:
          creationTimestamp: null
        spec:
          containers:
            - image: busybox
              # command:
              # - $cmd
              command:
                - "sh"
                - "-c"
                - "exit 1"
              imagePullPolicy: Always
              name: crontest
              resources: {}
              terminationMessagePath: /dev/termination-log
              terminationMessagePolicy: File
          dnsPolicy: ClusterFirst
          restartPolicy: OnFailure
          schedulerName: default-scheduler
          securityContext: {}
          terminationGracePeriodSeconds: 30
  schedule: 0 4 * * *
  successfulJobsHistoryLimit: 3
  suspend: false

Я смог воспроизвести вашу проблему с этим. Я видел это сообщение в журналах:

Events:                                                                                                                                                                                    │
│   Type     Reason                Age    From            Message                                                                                                                            │
│   ----     ------                ----   ----            -------                                                                                                                            │
│   Normal   SuccessfulCreate      9m26s  job-controller  Created pod: my-app-manual-xnj-fpvzq                                                                                               │
│   Normal   SuccessfulDelete      3m18s  job-controller  Deleted pod: my-app-manual-xnj-fpvzq                                                                                               │
│   Warning  BackoffLimitExceeded  3m18s  job-controller  Job has reached the specified backoff limit                                                                                        │
│ 

Измените свой yaml, чтобы изменить restartPolicy:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  concurrencyPolicy: Allow
  failedJobsHistoryLimit: 3
  jobTemplate:
    metadata:
      creationTimestamp: null
    spec:
      template:
        metadata:
          creationTimestamp: null
        spec:
          containers:
            - image: busybox
              # command:
              # - $cmd
              command:
                - "sh"
                - "-c"
                - "exit 1"
              imagePullPolicy: Always
              name: crontest
              resources: {}
              terminationMessagePath: /dev/termination-log
              terminationMessagePolicy: File
          dnsPolicy: ClusterFirst
          restartPolicy: Never ### <--- this is changed
          schedulerName: default-scheduler
          securityContext: {}
          terminationGracePeriodSeconds: 30
  schedule: 0 4 * * *
  successfulJobsHistoryLimit: 3
  suspend: false

Затем производит это:

$ kubectl get pods
NAME                      READY   STATUS   RESTARTS   AGE
my-app-manual-29l-27x8v   0/1     Error    0          2m9s
my-app-manual-29l-64th2   0/1     Error    0          110s
my-app-manual-29l-shfk7   0/1     Error    0          2m4s
my-app-manual-29l-tj9k7   0/1     Error    0          84s
my-app-manual-29l-tzlwd   0/1     Error    0          40s

Короче говоря, да, restartPolicy — это причина, по которой вы не видите неисправные модули.