GCP GKE: просмотр журналов прерванных заданий / модулей - PullRequest
Новая
       9

GCP GKE: просмотр журналов прерванных заданий / модулей

0 голосов
/ 04 июля 2019

У меня есть несколько заданий cron в GKE.

Один из модулей завершил работу, и теперь я пытаюсь получить доступ к журналам. 

➣ $ kubectl get events
LAST SEEN   TYPE      REASON             KIND      MESSAGE
23m         Normal    SuccessfulCreate   Job       Created pod: virulent-angelfish-cronjob-netsuite-proservices-15622200008gc42
22m         Normal    SuccessfulDelete   Job       Deleted pod: virulent-angelfish-cronjob-netsuite-proservices-15622200008gc42
22m         Warning   DeadlineExceeded   Job       Job was active longer than specified deadline
23m         Normal    Scheduled          Pod       Successfully assigned default/virulent-angelfish-cronjob-netsuite-proservices-15622200008gc42 to staging-cluster-default-pool-4b4827bf-rpnl
23m         Normal    Pulling            Pod       pulling image "gcr.io/my-repo/myimage:v8"
23m         Normal    Pulled             Pod       Successfully pulled image "gcr.io/my-repo/my-image:v8"
23m         Normal    Created            Pod       Created container
23m         Normal    Started            Pod       Started container
22m         Normal    Killing            Pod       Killing container with id docker://virulent-angelfish-cronjob:Need to kill Pod
23m         Normal    SuccessfulCreate   CronJob   Created job virulent-angelfish-cronjob-netsuite-proservices-1562220000
22m         Normal    SawCompletedJob    CronJob   Saw completed job: virulent-angelfish-cronjob-netsuite-proservices-1562220000

Итак, хотя бы один CJ запустился.

Я бы хотел посмотреть логи модуля, но там ничего нет 

➣ $ kubectl get pods
No resources found.

Учитывая, что в моем определении cj у меня есть: 

failedJobsHistoryLimit: 1
successfulJobsHistoryLimit: 3

mustn 't по крайней мере есть ли мне один модуль для судебно-медицинской экспертизы?

Ответы [ 2 ]

0 голосов
/ 04 июля 2019

Ваш модуль аварийно завершает работу или неработоспособен

Сначала просмотрите журналы текущего контейнера: 

kubectl logs ${POD_NAME} ${CONTAINER_NAME}

Если ваш контейнер ранее разбилсяВы можете получить доступ к журналу аварий предыдущего контейнера с помощью: 

kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}

В качестве альтернативы, вы можете запускать команды внутри этого контейнера с помощью exec: 

kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}

Примечание: -c ${CONTAINER_NAME} необязательно.Вы можете опустить его для модулей, которые содержат только один контейнер.

Например, чтобы просмотреть журналы работающего модуля Cassandra, вы можете запустить: 

kubectl exec cassandra -- cat /var/log/cassandra/system.log

Если ни один изэти подходы работают, вы можете найти хост-машину, на которой запущен модуль, и SSH на этом хосте.

В заключение проверьте Logging в Google StackDriver.

Отладка модулей

Первый шаг в отладке модуля - посмотреть на него.Проверьте текущее состояние модуля и последние события с помощью следующей команды: 

kubectl describe pods ${POD_NAME}

Посмотрите на состояние контейнеров в модуле.Они все бегут?Были ли недавние перезапуски?

Продолжить отладку в зависимости от состояния модулей.

Отладка ReplicationControllers

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

Вы также можете использовать kubectl describe rc ${CONTROLLER_NAME} для проверки событий, связанных с контроллером репликации.

Надеюсь, что это такпоможет вам найти именно проблему.

0 голосов
/ 04 июля 2019

Вы можете использовать флаг --previous, чтобы получить журналы для предыдущего модуля.

Итак, вы можете использовать:

kubectl logs --previous virulent-angelfish-cronjob-netsuite-proservices-15622200008gc42

чтобы получить журналы для стручка, который был там до этого.

...