Как в Kubernetes контейнер, созданный из CronJob, узнать, когда он был запланирован?

У нас есть ресурс Kubernetes CronJob, который запускает задание каждую минуту. Мне нужен контейнер, полученный в результате задания, чтобы знать, когда он должен быть запущен. Это возможно?

Справочная информация на всякий случай, если это будет полезно

Иерархия ресурсов Kubernetes такова: CronJob -> Job -> Pod -> initContainer -> Container -> PHP CLI command.

Я заметил, что контейнер запускается между 20 секундами и 10 минутами после той минуты, которую мы хотели запустить. Есть 2 причины значительного времени запуска:

1. В init-container делает довольно много вещей, в том числе извлекает образы докеров, а также выполняет cp исходного кода приложения размером более 300 МБ в том.
2. В container ограничения ресурсов довольно высоки, например, 2 ГБ памяти, что означает, что иногда в кластере не хватает емкости, поэтому кластер-автоматическое масштабирование должен подготовить новый узел для запуска модуля заданий, а процесс начальной загрузки может занять некоторое время, прежде чем новый узел присоединяется к кластеру.

Эта задержка запуска может иметь интересные эффекты, такие как Задание, запланированное позже, может превзойти Задание, запланированное для выполнения ранее, потому что у него есть емкость, необходимая для запуска, тогда как предыдущая не имела, поэтому ожидает запуска нового узла.

Некоторые вещи, на которые я смотрел до сих пор, чтобы решить свою проблему

1. Я посмотрел на DownWards API так что капсула может заглянуть в /etc/labels чтобы знать, какие у него ярлыки, но, к сожалению, он не предоставляет время запуска модуля, а только имя модуля.
2. Я рассмотрел использование динамического значения в метке Pod, то есть текущей метки времени. Но насколько я знаю, это невозможно?

Версии

Kubernetes v1.10, работающий в AWS EKS. Job - это команда интерфейса командной строки PHP 7.2.

Действия по воспроизведению

1. Настройте кластер Kubernetes с установленным и включенным автоматическим масштабированием кластера.
2. Создать CronJob. Поместите следующий yaml в файл с именем cron_test.yaml

    apiVersion: batch/v1beta1
    kind: CronJob
    metadata:
      name: tomtest
      labels:
        app: test
        tier: test
        tester: tom

    spec:
     schedule: "* * * * *"
     jobTemplate:
       metadata:
         name: tomtest-crons

       spec:
         template:
           metadata:
             labels:
                app: test
                tier: test
                tester: tom
                build_id: tom3

           spec:

             containers:
             - name: cron
               image: giantswarm/tiny-tools
               imagePullPolicy: IfNotPresent
               env:
               - name: TOMTEST
                 value: "3"
               args:
               - /bin/sh
               - -c
               - date;echo hi;sleep 600;echo bye;date
             restartPolicy: Never
             resources:
               requests:
                 cpu: "1"
                 memory: "2G"
               limits:
                 cpu: "1"
                 memory: "2G"

1. Запустите CronJob в своем кластере: kubectl create -f cron_test.yaml
2. Это будет запускать контейнер каждую минуту, который ничего не делает, кроме сна в течение 10 минут.
3. Подождите несколько минут, контейнеры начнут складываться в стек, и, поскольку у них высокие ограничения ресурсов, вероятно, включится автоматическое масштабирование кластера и добавит новый узел или 2. Если нет, увеличьте ограничения ресурсов дальше.
4. Делать kubectl get pods чтобы найти модули, которые кажутся запаздывающими, т. е. время запуска которых отличается от предыдущего.
5. Осмотрите информацию о модуле: kubectl get pod tomtest-123-456 -o=yaml - обратите внимание, что есть creationTimestamp поле и startTime но это не то время, когда стручок был запланирован.
6. Когда закончите, уберите: kubectl delete CronJob tomtest (Это также удаляет все задания и контейнеры)