Почему состояние нескольких контейнеров завершено, даже если один из контейнеров завершает работу с ошибкой? - PullRequest
Новая
       19

Почему состояние нескольких контейнеров завершено, даже если один из контейнеров завершает работу с ошибкой?

0 голосов
/ 01 октября 2019

У меня есть модуль с несколькими контейнерами, и один из них (containerA) выходит с ошибкой: 

Containers:
  containerA:
    ......
    State:          Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Fri, 27 Sep 2019 16:21:53 -0700
      Finished:     Fri, 27 Sep 2019 16:21:53 -0700
    Ready:          False
    Restart Count:  0

  containerB:
    ......
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Fri, 27 Sep 2019 16:21:54 -0700
      Finished:     Fri, 27 Sep 2019 16:21:59 -0700
    Ready:          False
    Restart Count:  0

  containerC:
    ......
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Fri, 27 Sep 2019 16:21:54 -0700
      Finished:     Fri, 27 Sep 2019 16:21:58 -0700
    Ready:          False
    Restart Count:  0

Этот модуль имеет restartPolicy: Never. И это контролировалось Иовом с backoffLimit: 9. При всех попытках состояние модуля отображается следующим образом: 

NAME                   READY   STATUS       RESTARTS   AGE
my-pod-2scsn           0/4     Completed    0          3d18h
my-pod-8z7qq           0/4     Completed    0          3d18h
my-pod-9cjnc           0/4     Completed    0          3d18h
my-pod-f6hxr           0/4     Completed    0          3d18h
my-pod-fz7hk           0/4     Completed    0          3d18h
.....

Это Completed сбивает с толку (один из контейнеров завершается с ошибкой). Почему здесь статус стручка Completed? 1011 *

1 Ответ

0 голосов
/ 02 октября 2019

В соответствии с официальной документацией Kubernetes , Задание обрабатывает Pod, потерпевший неудачу, когда один из целых контейнеров завершает работу с ненулевым кодом выхода или для некоторых обнаруженных превышений ресурсов. Из-за этого факта Pod phase на самом деле является основным индикатором с точки зрения общего жизненного цикла Pod, сообщая начальному Job о последнем статусе Pod.

Однако, как я заметил, kubectl get pod output STATUS столбец не отображает состояние фазы модуля, вместо этого он извлекает значение для конкретного контейнера внутри модуля и использует поле .status.containerStatuses.state.terminated.reason для отображения STATUS данных столбца.

Фактически, выможет даже получить более информативный вывод, предоставляя пользовательские столбцы стандартному инструменту командной строки kubectl: 

$ kubectl get po -o=custom-columns=NAME:.metadata.name,PHASE:.status.phase,CONTAINERS:.spec.containers[*].name,STATUS:.status.containerStatuses[*].state.terminated.reason

Поскольку задание достигает значения backoffLimit: 9, оно заканчивается с BackoffLimitExceeded предупреждающим сообщением:

Предупреждение BackoffLimitExceeded 54m Job-controller Задание достигло указанного предела отката

...